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.

dakota territory federal routing code

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.

2 thoughts on “Yes I’m recommending WCAG2 now

  1. Whilst there are no specific success criteria in WCAG 2.0 requiring sites to work with JavaScript and CSS disabled, I believe that conformance requirements 4 and 5 cover both situations. When any technology that is not relied upon is turned off or not supported in a user agent, the site still needs to be accessible. That is the argument I use.

  2. AlastairC says:

    Hi Gian,

    Interesting points, it has been a while since I’ve thought back to WCAG 1.

    Isn’t WCAG1 4.1 covered by ‘language of the parts’ (3.1.2), which is level AA in WCAG2. It also resolved the weirdness where changing a language was single-A, but setting it in the first place was triple-A!

    I take the WCAG2 1.3 section to cover WCAG1’s 6.1, where the stylesheet aspect is technology specific, and the newer guidelines are generalised. Testing 1.3.2 as a keyboard user (that can see the screen) often brings out those sorts of issues.

    I agree the scripting aspect is difficult, how progressive you can be with it probably depends on the site and audience.
    However, I’d rather developers created what they want to *and* apply things like WAI-ARIA, than ignore accessibility altogether.

    14.1 is difficult, but whenever I do accessibility related training or presentations I describe plain-language as the way to “help more people than any single checkpoint”. It is essentially a usability thing that affects some people with disabilities more than the general population.

Leave a Reply

Your email address will not be published.