Section 7.1.1 of IT Policy 1210 requires Level AA conformance to the World Wide Web Consortium (W3C) Web Content Accessibility Guidelines (WCAG) 2.0. These Guidelines are accompanied by a suite of supporting materials which web developers may find helpful. The WCAG 2.0 document itself is a technical standards document, and as such is very concise and lacks much explanation. This explanation is instead provided in the supporting materials, and it is expected that most people will use the supporting materials when developing web content, more so than the actual technical standards document.
The WCAG 2.0 supporting materials include:
While developers looking for explanation in WCAG 2.0 itself may be left wanting, some see the opposite problem with the supporting materials, as it is easy to be initially overwhelmed by the volume of information in the full suite of documents. They are organized very logically, though, and once one orients oneself to the role of each and how they are related, they become quite manageable. With this in mind, the WCAG Overview is the recommended place to start for anyone new to WCAG 2.0, and WCAG 2.0 Documents specifically outlines how the documents are related and linked.
Usability of the documents is also aided by extensive linking among them for easy reference. (I.e., items in WCAG 2.0 are accompanied by links to corresponding entries in How to Meet WCAG 2.0 and Understanding WCAG 2.0, and these documents in turn link to Techniques for WCAG 2.0, etc.)
In general, How to Meet WCAG 2.0 is typically the most useful reference. Understanding WCAG 2.0 provides detailed explanations. Techniques for WCAG 2.0 provides examples and specifics for conformance in particular technologies.
IT Policy 1210 was last revised in 2009. Transitioning from Revision 1 to the current Revision 2 of IT Policy 1210 meant moving from version 1.0 to version 2.0 of WCAG. Three documents are available to help you with this shift:
Section 7.1.2 of IT Policy 1210 requires conformance to the Federal Section 508 Information and Communication Technology Standards and Guidelines (36 CFR § 1194).
Supporting materials for these standards include:
On January 18, 2017, a final rule was issued that updated accessibility requirements covered by Section 508. The final rule went into effect on January 18, 2018. Documents available to help you with this transition include:
Because the refresh harmonized the requirements with WCAG 2.0, websites conforming to the current Revision 2 of IT Policy 1210 prior to the revision should generally require little to no changes to comply with the Revised 508 Standards.
Besides adhering to the provisions specified in section 7.1 of IT Policy 1210, best practices for web developers include the following.
Accessibility requirements conformance and evaluation should be central considerations throughout the design, implementation, and maintenance phases of web development.
WCAG 2.0 requires the use of accessibility supported technologies, a term which is defined in the WCAG 2.0 glossary and explained in more detail in Understanding WCAG 2.0. Examples of accessibility supported technologies are HTML, XHTML, CSS, DOM scripting, and PDF/UA-compliant PDF.
Even when a technology does provide accessibility support, it is generally not automatic: the web developer must take care to employ those features of the technology so as to use it in accessibility supported ways, as required for conformance.
This property of properly-separated information — to continue to function, rather than fail completely, in environments (such as assistive technologies) where not all features are supported — is known as graceful degradation, and is an important part of many accessibility conformance techniques.
The article Graceful Degradation & Progressive Enhancement provides a good explanation of these approaches.
Valid and robust code is important to accessible web content. Not only should the web developer make every effort to produce code that validates to the published specifications for the technologies used, but testing validity with automated validators is also recommended. The W3C, the chief web standards development organization, provides an (X)HTML validator and a CSS validator. Other validators are also available; W3C Developer Tools lists some of them.
Developers should extensively test the code they produce to ensure that it functions as intended, that it conforms to the accessibility requirements, and that accessibility is actually achieved. Testing can include developer and user testing; testing in a variety of browsers, versions, configurations, and operating environments; and testing with assistive technologies.
Manual testing can be augmented with automated evaluation tools, which parse code and compare it with accessibility standards. Many such tools are available; a list can be found in Web Accessibility Evaluation Tools: Overview. In particular, the state of Kansas has a license for Level Access' Accessibility Management Platform (AMP), the use of which is highly recommended.
Automated tools can significantly reduce the time and effort required to carry out evaluations. However, it is also important to understand that there are inherent limitations to automated evaluations, in that many accessibility checks require human judgment and must be evaluated manually using different techniques. It is therefore crucial that a thorough combination of automated and manual testing be employed.
Questions and requests for assistance may be directed to the Director of IT Accessibility; contact information can be found on the Kansas Partnership for Accessible Technology Contact page. Training, documentation, and other additional support resources will be made available in the future.