Kansas Department of Administration
This image/email designed to try to catch spammers. Home | Facilities | Financial Management | Personnel Services | Printing |
Procurement & Contracts | Repealer | Surplus Property | Systems Management |

Kansas Partnership for Accessible Technology

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.

Best Practices

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.

In choice of web technology, favor should be given to the most basic and widely-adopted standards appropriate for the content and its functionality. (X)HTML — typically along with CSS, common graphics formats, and perhaps some DOM scripting with JavaScript — is the fundamental technology standard for the web. While other, more “exotic” technologies such as PDF, Flash, and Silverlight may also be accessibility supported, they should be used judiciously, generally only when the content or application requires functionality they offer that HTML, etc., cannot provide. No matter the technology used, the implementation must conform to the accessibility requirements, which may require special effort.

Separate concerns.

Many practical techniques for conformant implementations stem from coding practices that maintain clear separation among content, structure, presentation, and behavior. The standard example is clean use of (X)HTML for structure, CSS for presentation, and JavaScript for behavior. Doing so rigorously allows each aspect to be fully and independently defined, providing robustness by minimizing or eliminating dependencies on the others, and thereby maximizing compatibility with the broadest variety of user agents, including assistive technologies. For example, well-structured (X)HTML can be read even in an environment where CSS is not supported.

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.

A similar concept is that of progressive enhancement, which turns graceful degradation around to the developer’s perspective and into an important guiding principle. Progressive enhancement is the practice of building content up from first being fully functional and robust in the simplest (e.g., HTML-only) environment, then adding on, in layers, the more advanced enhancements (e.g., CSS presentation, JavaScript behaviors). This methodology ensures that the underlying, core components function properly, without reliance on the other layers.

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.

Test thoroughly.

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.

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.

Getting Help

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.