Guidance for Web Developers
Helpful information for conforming to Kansas Information Technology Policy 1210, Revision 2
World Wide Web Consortium Web Content Accessibility Guidelines 2.0
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:
- How to Meet WCAG 2.0: A customizable quick reference to WCAG 2.0 requirements (success criteria) and techniques
- Understanding WCAG 2.0: Additional guidance on learning and implementing WCAG 2.0 for people who want to understand the guidelines and success criteria more thoroughly.
- Techniques for WCAG 2.0: Specific details on how to develop accessible web content, such as HTML code examples.
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.
Transition to 2.0
Transitioning from Revision 1 to Revision 2 of IT Policy 1210 means moving from version 1.0 to version 2.0 of WCAG. Three documents are available to help you with this shift:
Most websites that conform to WCAG 1.0 will not require significant changes in order to conform to WCAG 2.0, and some may not need any changes.
Federal Section 508 Electronic and Information Technology Accessibility Standards, Web-based intranet and internet information and applications (36 CFR § 1194.22)
Section 7.1.2 of IT Policy 1210 requires conformance to the Federal Section 508 Electronic and Information Technology Accessibility Standards, Web-based intranet and internet information and applications (36 CFR § 1194.22). These Standards have a very useful guide as supporting material.
Besides adhering to the provisions specified in section 7.1 of IT Policy 1210, best practices for web developers include the following.
Plan and implement accessibility throughout the development lifecycle.
Accessibility requirements conformance and evaluation should be central considerations throughout the design, implementation, and maintenance phases of web development.
Use appropriate accessibility supported technologies.
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 tagged 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.
Produce valid code.
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 Quality Assurance Tools and WebAIM Markup and Robustness Evaluation Tools list 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 SSB BART Group's 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.