This whitepaper covers the basic approach SSB recommends for conforming to the Section 508 §1194.41 Information, documentation and support requirements. As it currently stands we don’t, by default, test for those requirements as part of our High Level or Formal Audits. As these are part of the regulatory requirements for Section 508 compliance this begs the question why, if we have to conform to these standards, would we not want to audit for compliance with them.
The short version is that the actual legal requirements – a source of misunderstanding for many organizations – can easily be conformed to reactively rather than proactively. To be specific, under §1194.41 you have three relevant paragraphs:
- (a) Product support documentation provided to end-users shall be made available in alternate formats upon request, at no additional charge.
- (b) End-users shall have access to a description of the accessibility and compatibility features of products in alternate formats or alternate methods upon request, at no additional charge.
- (c) Support services for products shall accommodate the communication needs of end-users with disabilities.
If you read through the first two paragraphs you will note that documentation requirement is actually that you provide alternate formats free of charge for both the core product documentation and for the accessibility features of the product. This is contrary to what most people assume which is that the product documentation itself has to be directly accessible. As defined by the Section 508 standards, “Alternate formats usable by people with disabilities may include, but are not limited to, Braille, ASCII text, large print, recorded audio, and electronic formats that comply with this part’, all of which SSB or any competent accessibility consulting firm can easily make up for you on demand from your core documentation. As a general rule of thumb all these specialized forms can be made from a plain text base which tends to be something that is easily extracted from most documentation systems so the production process is fairly straightforward.
The third paragraph requires that you provide support for the communication needs of people with disabilities. A good way to think about this is that you are ensuring support synchronous communication across all the disability types outlined in the functional requirements for Section 508 – §1194.31. For people that are visually impaired or blind phone support works perfectly well and most organizations already have phone support in place. For people that are hard of hearing or deaf you can provide synchronous communication via TTY / TDD or – as is more often the case these days – via online chat. Most organizations we work with already have phone and online chat support services in place so they can generally claim to support this with no infrastructure changes.
If you don’t have online chat then you would want to include TTY / TDD as an option for communicating with your support team. That can be setup by simply contracting with a TTY / TDD relay service to provide support for you on an as needed basis. The relay essentially has an operator translating between TTY / TDD on one end and voice on the other. Since you are unlikely to have any material privacy concerns with user validation for your support system or services this is probably a good approach for you. The costs here are on the order of tens to a few hundred dollars a month in heavy support so no material support infrastructure need be developed to support the claim.
On VPATs we generally recommend clients make a claim of Supports for §1194.41 and make it very clear in the application and core documentation how to get alternative format copy of documentation free of charge. We generally put this, and information on our accessible support options, into a broader Accessibility Statement that we ship in the product documentation, link to from the product footer if applicable and provide in any web based documentation. This document covers what we have done for accessibility, how to get VPATs, any special product configurations, how to request alternate document formats and different channels for accessing support. We recommend all those requests go through a general firstname.lastname@example.org mail address which distributes to a list. Then as long as that inbox is monitored you simply need to respond to requests for alternate documentation formats as they arise. For your class of product those requests are likely to be few and far between so the potential cost here is low. If the ability to respond is coupled with support for accessible channels of communication you will conform to §1194.41 requirements.