Yes I’m recommending WCAG2 now

I had a client ring me yesterday, wanting to know if they should be trying to comply with WCAG1 or WCAG2. They had read my article: Why I’m sticking with WCAG1… for now, and wanted to check if my opinion still held. I wrote that post a little over a year ago, and although much has stayed the same (there are still few free accessibility testing tools that test against WCAG2 for example), much has changed. For example, the Australian Government Information Management Office (AGIMO) has released the Web Accessibility National Transition Strategy, the Australian Human Rights Commission (AHRC) have updated their Web Advisory Notes and most states in Australia now have formalised compliance to WCAG2 or are following the federal strategy.

Areas needing improvement

There is still a lot of confusion regarding WCAG2. It is still a very complex series of documents that require specialist interpretation. Free accessibility testing tools, like WAVE by WebAIM and Cynthia Says by HiSoftware need to be updated to test against WCAG2. Instructional guides like the eGovernment Accessibility Toolkit and the Office for Disability Factsheets need to be updated to WCAG2. AGIMO needs to clarify some policy-related issues re WCAG2, such as the use of JavaScript, Flash and Word documents. It would also be useful to post relevant and regular updates to their Accessibility Blog.

Is a WCAG2 Level A site still compliant to WCAG1 Level A?

I was recently asked this question by a client. There are four WCAG1 Level A checkpoints that are not represented in WCAG2, Level A:

• Checkpoint 4.1: Clearly identify changes in the natural language of a document’s text and any text equivalents (e.g., captions).
• Checkpoint 6.1: Organize documents so they may be read without style sheets. For example, when an HTML document is rendered without associated style sheets, it must still be possible to read the document.
• Checkpoint 6.3: Ensure that pages are usable when scripts, applets, or other programmatic objects are turned off or not supported. If this is not possible, provide equivalent information on an alternative accessible page.
• Checkpoint 14.1: Use the clearest and simplest language appropriate for a site’s content.

For more information on the WCAG1 checkpoints and their mapping to WCAG2, see the W3C Comparison of WCAG1 checkpoints to WCAG2.

Checkpoint 4.1

Clearly identify changes in the natural language of a document’s text and any text equivalents (e.g., captions).

Identifying changes in the natural language of a document can be achieved using the LANG element. Screen readers recognise this element and modify their speech output to match the relevant language. I believe this is still a useful technique and it is unfortunate that it has now been relegated to WCAG2, Level AAA.

Checkpoint 6.1

Organize documents so they may be read without style sheets. For example, when an HTML document is rendered without associated style sheets, it must still be possible to read the document.

It is unclear whether this is a requirement of WCAG2 or not. This is a decision to be made by the AHRC, or even AGIMO. It requires a definition of accessibility supported uses of technologies, and whether style sheets are an accessibility supported technology or not. There is some overlap between this checkpoint and Success Criteria 1.3.2 (Meaningful Sequence): “When the sequence in which content is presented affects its meaning, a correct reading sequence can be programmatically determined”. Personally, I still test this checkpoint when I am testing against WCAG2, as it is one of the easiest ways to determine if a screen reader will interpret the page in the correct order.

Checkpoint 6.3

Ensure that pages are usable when scripts, applets, or other programmatic objects are turned off or not supported. If this is not possible, provide equivalent information on an alternative accessible page.

As with Checkpoint 6.1, whether this is a requirement of WCAG2 is a decision that policy-makers such as AHRC and AGIMO need to make. I also test this checkpoint when testing against WCAG2 because although these technologies often have accessibility features, it has yet to be documented how supported these features are by most assistive technologies.

Checkpoint 14.1

Use the clearest and simplest language appropriate for a site’s content.

Anyone who is aware of my work with the W3C WCAG Working Group knows that I fought long and hard to keep this checkpoint at Level A in WCAG2. Unfortunately, in this, I failed. Clear and simple language is extremely important for people with cognitive disabilities – and it should be remembered that there are more people with cognitive disabilities than people with sensory disabilities (vision, hearing, physical) combined. There are many excellent accessibility requirements that address the needs of people with cognitive disabilities at WCAG2, Level AAA, and I am hoping that policy-makers such as the AHRC or AGIMO identify some of these success criteria and make them mandatory for Australian web sites. In the meantime though, there are products such as BrowseAloud that are specifically aimed at assisting people with cognitive disabilities (and address many WCAG2 Level AAA success criteria), which can be implemented by site owners concerned about the accessibility of their site to people with cognitive disabilities.