Information and Communication Technology

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

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:

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 Information and Communication Technology Standards and Guidelines (36 CFR § 1194)

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:

Transition to the Revised 508 Standards

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.

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 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.

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 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 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 Developer Tools lists 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. 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.

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.