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.
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.
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.
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.
Yes, this can all be very tricky. There *IS* work underway to update the Techniques documents, and some discussion about revisiting WCAG, but it does take time, for lots of reasons (some reasons are good, others not so much).
One thing we need (and a group of us are working on this) is information about ARIA support. After years of work, ARIA *should* be an official W3C Recommendation in time for CSUN, and that will be a Good Thing (we will need to collectively toast that milestone that week). But what kind of support can we expect for ARIA today? Does using ARIA today meet sufficient accessibility support?
As anyone who has attempted to do this type of testing knows, the 3-Dimensional array of data that is needed is extremely complex: you need to factor in operating system(s), user-agents(browsers) PLUS which version of each browser, and then factor in assistive technology choices (PLUS version number again). Assembling a lab that size and that diverse is unwieldy at best, and logistically complex to say the least. But if we could crowds source that requirement…
While details and specifics are still being worked out, on Saturday March 22nd a few of us are organizing a “hackathon” coming out of CSUN, that will look to do just that. The over-arching idea is that to assemble a lab of that diverse a collection of OS/browser/AT configurations requires numbers – and if ever there was a gathering of that kind of diversity in tool-sets, CSUN is likely the place. If you haven’t already made your travel plans, consider hanging out an extra day and join us in person as we kick this off. Or check with us (once we are set) and volunteer to remotely send us test data feedback. Our community needs this data, so our community should gather this data 🙂
This is not an “official” CSUN activity per se, however the conference organizers (thanks Sandy) are supporting this effort, and more details will be communicated via the CSUN newsletter (coming soon). Hope to see you all at CSUN!
I think we have to unravel a couple of concepts here. It is not necessary to only use techniques published by the WCAG WG in order to meet WCAG. An author can use any technique he likes, which is supported by inexpensive AT & a browser. WCAG has never had any obligation to publish techniques. They are just provided as non-normative helpful guidance. I think we are glad that many others are publishing techniques. The only suggestion is that if an author comes up with a good solution to let us know so we can test it include it.