Spider Trax

WCAG Samurai Peer Review: Part 2

Further to my previous post, I’m continuing to read through Gian Sampson-Wild’s technical review of the WCAG Samurai Errata. This time, I thought I’d look at the issues facing users with cognitive disabilities.

Like Gian, I’m also a little disappointed that WCAG Samurai didn’t seize this opportunity to correct some of the oustanding problems with WCAG 1.0 as it relates (or doesn’t) to users with cognitive disabilities. That said, I acknowledge that a bit of short-term tinkering is woefully inadequate if we want to address the needs of these, largely overlooked, users properly. But I think we can make a start now if we then follow it up with a full scale investigation later on. One potential benefit would be raising the profile of these users sooner rather than later. If we can get designers to start thinking about users’ needs, so much the better.

Checkpoint 11.3: Provide information so that users may receive documents according to their preferences (e.g., language, content type, etc.)

Remove the references to “language, content type, etc.” and replace with “colour, text size, font etc”.

“Language” was always a non-starter and I’m not convinced that “content type” is really an accessibility or a usability issue. Colour, text size and font choice, however, are well known factors that can significantly affect overall readability for many users with cognitive disabilities or learning difficulties. So let’s start promoting these changes.

Checkpoint 13.5: Provide navigation bars to highlight and give access to the navigation mechanism.

I agree with Gian that consistent navigation menus are often important for people with cognitive disabilities. But I also recognise that some pages really don’t need a full blown site menu. A clearly readable link back to a page that does contain navigation bars may be sufficient in some cases. Such as a Home link …

I’d consider amending the Errata to read:

Guideline 13.5: Not all sites or pages require navbars. In such cases, provide a single link so that users can navigate to pages that do offer the site’s standard navbar.

Checkpoint 14.2: Supplement text with graphic or auditory presentations where they will facilitate comprehension of the page.

Use the content you wish to use. You are not required to illustrate documents (nor, if you are a blind person, could you do so), which then would require text equivalents.

WCAG Samurai Errata

Gian doesn’t agree and argues that providing graphic or auditory versions of information is the equivalent of providing text of graphic and auditory information.

Whilst I see her point, we do have a difficult problem here. Even if supplementary presentations are used, we cannot know whether they will substantially support comprehension because that, in turn, also depends upon the ability of the individual user. Much as we might like it to be so, it’s a sad but realistic fact that the web cannot be all things to all people of all abilities. There has to come a point where the only really effective way of ensuring that a user fully understands web content is if a trained human being supports them.

I’m not suggesting that we allow designers, or site owners, to avoid their responsibilities here. What I am saying is that we do have to be practical and that the individual designer is probably best placed to make that judgement call. One of WCAG 1.0’s problems was that it sometimes placed too much emphasis on theory and abstract ideaology instead of looking at the Real World. That is something we should avoid replicating at all costs.

As such, I support the Samurai’s stand on this point.

Checkpoint 14.3: Create a style of presentation that is consistent across pages.

Like Gian, I believe it is important that consistency is the norm. I’d suggest that the Errata Introduction be amended as follows:

Guideline 14.3: You may use any accessible “style” you wish, including styles that are not “consistent”, if such inconsistencies will not create user confusion or disorientation.

Preserving reading order

I’m very much in two minds about this issue. I agree with Gian that a visual design that alters the natural reading order of a page could create serious problems for some users. Dyslexics who use screen readers for support, for example. It’s one reason why I’ve never been very comfortable with designs that position form labels offscreen using CSS. The end result, in theory, may be a visual page that doesn’t “match” the audio rendering.

However, if we are recommending that visual designs follow a document’s natural reading order, we are going to be severely restricting what is possible via CSS. You won’ be able to turn that horizontal site menu at the top of the page into a series of links at the bottom of the page through pure CSS any more. That sort of implied design restriction bothers me. If we make life too difficult for designers — for no good reason –then we risk having yet another set of guidelines that they will simply ignore.

Personally, I don’t know enough about the various screen readers and, especially, how they are used by dyslexics, to feel confident enough to offer a suggestion either way. Ideally, I think I need a lot more, very specific, user feedback on this issue before I can decide which way I should be moving.

Top