WCAG 2 and Accessibility Support

WCAG 2.0 states that conformance cannot be claimed if the methods and technologies used are not accessibility supported. In other words, the result must be some level of actual accessibility, not merely technical conformance. This is a wonderful requirement for accessibility, but as currently applied to WCAG documentation and process, this causes issues.

Definitions

WCAG 2.0 itself is a normative document. You must meet the requirements of the normative success criteria in order to claim conformance. The normative guidelines are not updated regularly (WCAG 2.0 itself is unchanged since 2008).

WCAG also has many hundreds of pages of supporting documentation, including Techniques for WCAG 2.0. Supporting documentation and techniques are informative (not normative), meaning that they inform conformance and can change. There are three types of techniques (definitions are my own, not the W3C’s):

Sufficient techniques

If you do this, you have probably met the requirements of a particular success criterion.

Advisory techniques

It’s a good idea to do this because it will probably improve accessibility, but this technique is not fully testable, not fully supported by some technologies, or doesn’t necessarily mean you’ve met a success criterion.

Technique failures

If you do this, you’ve probably NOT met a success criterion. Note that WCAG simply calls these “failures”, but I’ll refer to them as “technique failures” to avoid confusion with WCAG conformance failures.

Techniques and Conformance

As stated in the WCAG FAQ, authors do not have to follow the published informative techniques. You could meet the normative success criteria through other, undocumented techniques and still be conformant. Similarly, you could match a technique failure, yet still be conformant.

Some on the WCAG working group repeatedly indicate that a technique failure always results in a conformance failure, though this opinion does not align with the published documents or the spirit of normative vs. non-normative.

Accessibility Support

Overarching all of the techniques is the concept of accessibility support – it actually needs to work in real-world technologies that the user actually has or can readily get. Accessibility support is defined in the normative guidelines, and further explained in supporting, non-normative documentation.

Of primary note:

“The WCAG Working group and the W3C do not specify which or how many assistive technologies must support a Web technology in order for it to be classified as accessibility supported.”

Accessibility Support and Techniques Conundrum

When WCAG 2.0 was released in 2008, techniques were provided to inform and support accessibility. There were published techniques for things that had very little support at the time, such as longdesc. The techniques documentation provided warnings about the level of accessibility support, cautions for use, better alternatives, etc.

In recent years, however, new techniques are only provided in WCAG documentation after they are deemed by the working group to meet a sufficient (yet undefined) level of accessibility support. Even new Advisory Techniques seemingly necessitate a sufficient level of support, even though they are defined as being for yet-to-be-supported technologies. In other words, a technique is not published to inform conformance and best practice until that technique is in use and generally supported by modern technologies. This delay is compounded by the fact that it takes months or years for new techniques to be published.

Providing WCAG techniques only after some nebulous level of accessibility support has been met seemingly contradicts the declaration that the W3C does not dictate which or how many assistive technologies are necessary for accessibility support to have been met.

This is particularly of concern with ARIA and HTML5. These both provide innovative ways for authors to provide accessibility and conformance with the normative guidelines. However, WCAG techniques aren’t being published for ARIA and HTML5 until they are viewed as well-supported. This results in harmonization between WCAG and other W3C specifications not occurring when those specifications are authored, but only after they are in broad use. Conversations regarding how ARIA labeling and HTML5 <figure>, for example, affect conformance are just now occurring, years after these had been introduced in other W3C languages.

Is Failure the Only Option?

This leaves authors in a precarious position. They can fully meet the normative success criteria in innovative ways (and this is all that really matters for conformance), yet they are left with no guidance or techniques to inform those methods or aid in determining present or future conformance.

Even more problematic is that they may match technique failures that have not yet been updated to reflect modern accessibility because those technologies have not yet met the working group’s threshold for accessibility support – something that can only be accomplished through implementation. In other words, authors must implement and assistive technologies must support techniques that are contrary to or fail WCAG documentation at a sufficient enough level that the WCAG documentation is then modified to allow those techniques.

In short, you must fail or ignore a WCAG technique significantly in order for that WCAG technique to then be updated or a new one added.

Possible Solutions

This is a complex situation. WCAG cannot simply dismiss accessibility support. But as the very first line of the guidelines state, WCAG 2.0 “covers a wide range of recommendations for making Web content more accessible.” As WCAG has advanced it seems that techniques have become more focused on measuring strict conformance than in recommending true and optimal accessibility. I believe it best, as WCAG originally intended, to allow authors to determine whether accessibility support is sufficient rather than tacitly defining accessibility support via the presence or absence of WCAG techniques.

Increased accessibility could be achieved through a broader and updated set of well-documented techniques that inform present and future accessibility, support innovation, document limitations, and encourage future technology support (assistive technology vendors and browsers are more likely to support techniques for which there is WCAG documentation), rather than a restrictive set of techniques that only quantifies strict or narrowly interpreted conformance for the current (or more accurately, the near-past) state of technology. Making these changes will require only a modification in current W3C practice, not a change to WCAG 2.0 itself.