The Refresh will broadly maintain the current structure of the requirements with a separation between technical and functional standards. Technical standards will be organized around product functions: e.g. web based systems, two-way voice systems, video conferencing systems and other related product functions. In the current standards the technical requirements – subpart B – have an implied break out by product type versus product function. The implication to many readers of the current structure is that only one product type needs to be followed. So in the argot of the current Section 508 standards if you have a IT system that conforms to 1194.21 Software applications and operating systems it would seemingly not need to conform to 1194.22 Web-based intranet and internet information and applications. (In practice we almost always see the case with web apps where developers assume 1194.22 applies but 1194.21 doesn’t.) This, however, is decidedly not the correct interpretation and, generally, all the relevant portions of the 508 technical standards that would apply do apply. The Refresh addresses this by shifting the focuses to features of products and clarifying that all relevant technical standards will continue to apply.
Functional performance requirements will remain a separate requirement, but will increase from six to nine user modalities. This is in line with the overall trend we see on a global level towards an increase in the number of user modalities covered under relevant accessibility requirements.
As with the current standards, in the Refresh, both technical and functional performance criteria will be required and enforced. This is a change from the current state of practice and from the 2010 Advanced Notice of Proposed Rulemaking Draft (ANPRM), in which the application of the functional performance criteria is often considered as an alternate to conformance with the technical requirements. Thankfully, the current draft of the standards closes this loophole and makes it clear that IT systems must technically conform and, functionally, be usable to individuals with disabilities.
Finally, as it is of material interest to many of our customers, it is worth noting that requirements have been expanded to cover web sites, web applications and electronic document content. There are some limits on the type and scope of electronic document content covered that I will address in a future post. For sites, applications and content the target standards for developers will be the Web Content Accessibility Guidelines (WCAG) Levels A and AA requirements. This is in line with the global trends harmonizing around these as the de facto standards for web and electronic content accessibility. Hardware and applications that are not web-based will be based on proprietary standards.