Comments on other reviews

Thanks to Joe’s shenanigans, neither I nor Gian Sampson-Wild knew of each other’s reviews. You might have noticed that I didn’t write quite as much as Gian, that is partly because I agreed with more of it.

Whilst Joe is keeping quiet on holiday and collating comments, I would like to discuss a few of the points of contention that Gian (rightly) brought up. Please read her technical review first if you haven’t already.

I think most of the differences are due to either differing opinions on the user-agent / developer responsibility split, or whether something should be mandated across all sites and pages.

Accessible technologies

The WCAG Samurai Errata assume that PDFs, scripting technology and Flash can be directly accessible and have rewritten the guidelines accordingly.

Perhaps this was written before noting the later part that specifies the only times a PDF is acceptable as primary content?

In any case, I question that there is much difference in practice between a well marked up page and a well tagged PDF. Using the usual (Adobe) acrobat reader program, you can adjust the colour scheme, linearise (re-flow) the document and even auto-scroll.

What are the accessibility features inherent in HTML that PDF does not have? There are certainly aspects that are not ‘web-friendly’, but I’m curious as to the aspects that affect people with disabilities.

There is some truth to the comments for Flash, where it does not have structural elements such as headings and lists that could aid internal navigation. However, the nature of Flash sites often means they are ‘experience rich’, rather than content rich. Does that need to be codified into the errata somehow? A kind of ‘horses for courses’ check.

Testability

I generally agree with the statements here. I have a nagging feeling that without being directed to good examples they could be taken the wrong way though.

Cognitive disabilities

Whilst I also agree with the sentiment that more should be done to investigate and write guidelines, I could not agree that this will help:

I would like to see WCAG Samurai develop a set of cognitive disability guidelines to add to these errata.

It would put back the release of the errata to well after WCAG 2, and be a whole project in itself, going well beyond the scope of WCAG 1.

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

I think there is some confusion here, from my reading of WCAG 1 this checkpoint was not about providing alternative displays. It isn’t particularly clear from the guideline itself, and the examples are generally not accessibility oriented.

However, even if it was about alternative displays of the same content, I don’t think this should be mandated by the guidelines. This is a user-agent issue, the developer’s responsibility is to separate content and style, allowing the user to adapt the display to their preference.

To be clear, I don’t think people should be prevented from providing alternative colour schemes and layouts, but it should not be required either.

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

Perversely, I can agree with both the errata:

Not all sites or pages require navbars. Ignore.

and the review comment:

Navigation bars are of great importance to people with cognitive disabilities as they provide a consistent means of navigating within a particular site.

However, I think the errata should stand, as that aspect can be dealt with by checkpoint 13.4: Use navigation mechanisms in a consistent manner.

For sites which have a navigation bar, they should use it consistently. For sites which don’t, they are not arbitrarily forced to add one.

Checkpoint 13.7:If search functions are provided, enable different types of searches for different skill levels and preferences.

the provision of targeted searches and contextual filters can greatly assist people with cognitive disabilities.

Although I agree that those features can help certain people, I cannot see it being a requirement for every site, which the WCAG+Samurai should be.

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

Again, although I agree, I don’t think these can be mandated for every site.

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

I’m slightly torn on this one, although there are instances where ignoring this guideline would not cause issues, I have found instances where it does.

For example, a large image on the homepage of a site that changed on each page load caused issues for both screen magnifier users, and people with cognitive impairments essentially not know if they had returned to the actual homepage.

In general, I think it is more of a usability issue, therefore I hadn’t raised it.

Preserving reading order

Preserving the reading order of a page (ie. matching the reading order of the page with style sheets enabled to the page with style sheets disabled) is an important accessibility technique for people with cognitive disabilities.

But it can also be at odds with providing a good reading order for linear devices (e.g. screen readers), and it is also antithetical to good separation of content and styling to some extend. I have long put the content first, with a skip link to the main navigation.

The ideal is that the user-agent would make very clear where you are when tabbing through the page, and the site is consistent in it’s page structure. Given that consistent templates are the easiest thing to implement, I don’t see this as something that needs mandating.

Given the conflicting requirements, is this something that could be put in terms like: “Check that the reading order is understandable both for the linear document and visually tabbing through the links”?

Distinguishing information

I agree that some types of distinguishing information (essentially keywords first) can be useful, but the checkpoint does need tightening up somewhat.

I’d suggest adding something like this: “Do not use repeated words or characters at the beginning of headings and links unless it disrupts understanding of the material not to do so.”

I don’t think the errata (or guidelines) prevent using hidden structural elements to aid within page navigation, although perhaps they could be explicitly allowed?

Also, I don’t think sitemaps and tables of contents should be disallowed, so would change “Do not” to “There is no requirement to use”.

Skip links

Again, I agree that skip links are useful, but the guideline needs revision to recommend (or even allow for) the modern usage.

I would suggest including the Guideline 13, and adding: “Adding a link to every set of related links is superfluous (checkpoint 13.6), therefore there is no requirement for this. Adding a very small number of links to assist linear navigation of a document is a useful extra when implemented consistently across a site and made visible to keyboard users.”

Again, it is something that user-agents can and should enable, but since they don’t do this properly yet I’m included to explicitly allow it.

In response to the comments on the technical review, I can recommend a good article on the visible-on-tab method of doing skip links.

Natural language

Upon re-reading the errata, I noticed that this doesn’t match what we currently do:

If a page is bilingual or multilingual, do not specify a primary language.

This implies that even if the page has a primary language, if it has another languages you shouldn’t set it at the root (html element).

I would have thought that this could over-complicate matters, and if that sentence is removed the rest of the checkpoint still makes good sense. Perhaps it’s worth confirming this with Richard Ishida? (My colleague did ask Richard about this, and he thought pages should always have a root language, but it might be worth confirming as the conference didn’t give time for all the context.)

Steve Green’s comments

Whilst I was writing this, Steve Green’s comments popped up on the Web Standards Group list, so it seems like a good point to discuss these to.

Incorporation of Errata into WCAG 1.0

I agree that they should be incorporated, but you will have to note that it cannot be done (legally) without the W3C’s consent, the copyright prevents ‘integration of errata’. Unless someone tries a re-run of the codec fiasco at Digg?

User Agents

If we are interested in positive actual outcomes rather than theoretical levels of accessibility then we need to take account of the user agents that are actually available to users rather than those we wish were available.

I’ve been thinking about this quite a bit recently, and actually think that a relatively hard-line approach would be best. There are two main assumptions for this:

• Until people (end users) ask for certain features (e.g. text-resizing), or switch browsers because theirs lacks a features, user-agent makers will not change.
• There will be a time between the errata being published and sites being re-designed and published.

For example, it’s been seven or eight years since Mac IE introduced text re-sizing, WCAG 1 technically expects it (pixel is a relative unit), and I haven’t noted a unit requirement in WCAG 2. And still IE 7 doesn’t resize pixel sized text.

It is similar on the screen reader front, until Freedom Scientific get complaints from users, they will not change to support standards. (And even when they do get complaints, they tend to avoid the standards based methods.)

The only way things are going to change is if the makers of user-agents know it’s going to be required. If you’ll forgive the metaphor, it would be like kicking out the crutches and making the user agents stand up. There might be some short term pain (although if you look around the internet, not that much more), but it would be better in the long term.

Things aren’t going to move on whilst the crutches are there.

Applets and scripts

The errata state they “must be made intrinsically accessible…” without defining what this really means.

Guideline 8 (checkpoint 8.1) covers this fairly well, although perhaps it is worth making it explicit that ‘other’ technologies should follow their own accessibility guidelines? (E.g. Flash, PDF, Java)

With regards to user not knowing what to do when they get to an (accessible) interface, I’m not sure what you could mandate for that, apart from a wooly ‘provide information for users to orient themselves’, which would be impossible in some cases without providing user-agent specific advice.

Graphical representations of text

I partially agree with this (as suggested in my review), and changing the colour of low contrast graphics isn’t a reality yet. However, it only really causes issues for small text, larger text is quite readable when zoomed.

Colour contrast of text

Since the Errata state that all Priority 3 checkpoints should be ignored, they should also state explicitly that adequate colour contrast for text is now a requirement. The existing reference is not sufficient.

Simply selecting text applies a system colour scheme (in IE), or a contrasting colour scheme in other browsers, so I’m not sure this should be a requirement. That’s before you get to people being able to apply their own colour schemes to text.

Confusable colours

I note that the two peer reviewers are split on this point, with Alastair saying “the guidelines on colour contrast are quite clear”, and Gian saying “Some clarification would be useful here”.

I guess I might have been influenced by previous work in the area, perhaps a link through to that (or similar explanation) would help?

Implicit form controls

I’m not sure that the errata need extension beyond:

>12.4 Associate labels explicitly with their controls. [Priority 2]
For example, in HTML use LABEL and its “for” attribute.

I’ve always taken that to mean you must use labels.

Non-W3C HTML versions

I think Steve has a point here, browsers/access technologies have enough to keep up with, defining other variations is unlikely to gain support, and therefore unlikely to be a viable alternative.

The other points have been covered previously.

WCAG Samurai Errata Review

Context of this review

A few weeks ago Joe Clark emailed me asking if I’d be interested in doing an independent review of the WCAG Samurai’s errata, i.e. corrections for, and extensions to, the Web Content Accessibility Guidelines 1.0. (WCAG1.)

I said yes, and last Friday they dropped into my inbox. Unfortunately I only picked up my work email on Monday, but a couple of late nights later here we are. That’s enough about me, on with the review.

Please note that for this to make any sense, you’ll need to know about the WCAG guidelines and the errata. Also, I will probably say thing like ‘we usually’ a few times, in which case I’m referring to the team at Nomensa, where we regularly debate accessibility minutia to review our practices.

Summary

Overall, there is much more to agree with than disagree with, and much of it is well over due. The ‘until user agent’ checkpoints are gone or settled, and there is an explicit requirement to actually learn HTML properly.

Using the errata in conjunction with the guidelines makes it much clearer how you would ‘comply’, using language like ‘ban’ and ‘require’. How people deal with non-HTML content like Multimedia and PDFs is also very clear, with explicit advice and exceptions for both.

There is only one point I definitely disagree with (relative units), but there are a few revisions that could cause issues for people in the short term. For example, skips links are gone. Although the function that skip links enable can be done on the user-agent side, currently few people using only a keyboard (but without a screen reader) know how.

I don’t think it is wrong to revise the guidelines in this way, assuming that there is some pressure on people producing user-agents to make appropriate updates.

The main limitations are really based on the source material.

The errata have not tried to cover all online formats, there is the underlying assumption (from WCAG 1) that you are building a site with HTML/CSS/JavaScript, with perhaps some Flash or PDFs.

There is bound to be some controversy comparing WCAG1+Samurai to WCAG2, however, the accepted technology focused of the errata gives it an immediate advantage for those creating standard web sites. For those using other technologies, WCAG2 is probably easier. They are not mutually exclusive.

The second limitation is that fact that these are errata, rather than a ‘WCAG 1.5′. Unless a complete set of revised guidelines is published, I doubt people new to accessibility will learn WCAG 1.0, then apply themselves to learning how the errata fit in. For those of us who have been dealing with WCAG 1 for years, you can read and understand the errata immediately. But for those new to the field, I have a strong suspicion that unless there is one, updated, document to put in front of them, it’s success will be limited to those familiar with the original. Whether that is really a criticism is entirely down to your point of view.

I suspect this would be a very difficult thing to achieve, hinted at in the overview where it states:

these errata are published as review and criticism of
WCAG 1.0 under the fair-dealing provisions of Canadian copyright law.
They are not a derivative work and they are not an “integration of
errata.

An extension of being limited by the original document is that the advice laid out in the errata is as unintelligible to the new comer as the original guidelines. I’m entirely guilty of this myself, but this review is squarely aimed at those familiar with both WCAG and the errata.

Agreements - the easily accepted

The points at which I clapped my hand with joy were:

Multimedia (Guideline 1)

Crystal clear advice such as:

Videos may not play without user activation. Your page or site may
not automatically play videos upon loading the page.

As part of developing best practice advice for clients over the years, this is just the sort of thing we would like to say, but didn’t have the backing to be so forthright.

Another aspect that I think works well is the requirements for transcription, where:

Large sites with significant budgets and resources must
publish transcripts to coincide with release of the podcast.

There is no such requirement for small sites with small
budgets (including personal blogs), but there cannot be an
unreasonable delay. (We do not define large or small or what
is or is not reasonable.)

You might well wonder what significant budget is defined as. I think the beauty of this approach is that it is left up to the organsation. If there is a dispute, the courts are much better placed to make that decision than accessibility experts. (Obvious caveat: I am not a lawyer.) This has to be far better than a blanket proclamation either way.

Removing Priority 3 checkpoints

With a couple of exceptions noted below, this is a good thing. In audits and consultancy where we help clients meet the guidelines, Priority 2 checkpoints were always the hard ones to meet (often because their CMSs was crap). The Priority 3 checks were either redundant, trivial to do (e.g. skip links), or untestable.

Relying on colour (Guideline 2)

WCAG confused an (old) testing method (using a black and white screen) with the actual guideline. The errata comment on that is Web accessibility is about people with disabilities, not their equipment.The guidelines for developers on colour contrast are quite clear, as I would expect from having read Joe’s book.

Explicit inclusion of semantics

Although it doesn’t mention specific elements, it includes a clear call to learn HTML. Properly.

The only issue I can see with this is the lack of examples, or a clear “you must use these for accessibility”. It is a tricky one to enforce. Some things are obvious, such as headings, lists and quotes (which were in WCAG 1). Mentioned elsewhere in the errata is hreflang, which is one of the most underused HTML elements ever, but deemed useful here.

Most developers think they know HTML, but few have used the cite or hreflang attributes. Some people may be surprised by what we could bring up in audits based on these checkpoints. However, wrapping all the ‘use HTML properly’ checkpoints into one section makes it much clearer and easier to deal with.

Scripting (Guideline 6)

The errata don’t have lots to say on scripting, this is the main aspect:

Do not provide alternative presentations or alternate pages (Checkpoint 6.5). Make the original; page accessible.

This leaves the checkpoint stating that pages should work without scripts in place, but removes the option to create an alternative (which conflicts with the other checkpoints anyway).

Controversial clarifications

Some things have either been long running debates, or swept under the carpet.

Valid HTML

Making valid HTML a requirement for accessibility makes my life as an accessibility and web standards guy much easier. Yes, you can have valid and inaccessible pages, but getting people to use and test (themselves) for validity has helped massively in gaining traction. Especially when combined with moving people onto CSS based methods, a must for practically implementing accessible sites.

One question though. If you require a valid page when actually rendered to the reader of the page, do IE’s conditional comments bypass that? For practical reasons I would hope so.

Adverts are your problem

Site owners will often dawdle without action over adverts that they include. If site owners are definitely responsible, they might actually require the advertisers to clean up their act.

Don’t use tabindex or accesskeys

At last. They can be put to bed (in their current form).

Disagreements, or just short term pain?

Relative units (Guideline 3)

This was the one I do really disagree with, although I would certainly accept that WCAG 1 needs updating.

You may use any defined units for text sizing, layout, or other purposes. The difference between relative and absolute units is immaterial to these errata. (px, by specification, was and is a relative unit.) Use of px as a unit to size text is explicitly permitted.

So many sites could become inaccessible to people with visual impairments if you let pixel specified layouts and fonts reign. There are two main strands:

1. Lack of effective zooming in user-agents.
2. If developers are not made to think about implementing relative units, many sites will become unusable when font sizes or layouts are manipulated by the user.

On the first point you could say that Opera has a decent zoom, if people need one they should use Opera. However, there are a lot of people on government and corporate networks trapped on Internet Explorer (5.5), who have no option of using another browser. If the argument then is that the employers are in the wrong here, that is probably correct, but it would still cause end users problems.

The second point is more important long term: If developers don’t allow for flexibility (e.g. using the bulletproofing concepts coined by Dan Cederholm) people who do use browser controls will find a lot of sites that are unreadable and/or unusable. I come across fixed width/height elements causing issues regularly.

The whole issue of resizing is complicated now, and is only going to get more complex as higher resolutions screens become more popular. The errata is right to point out that the pixel is a relative unit, but since browsers currently treat it as fixed (by the user’s resolution) it can and does cause people problems when either they can’t increase the text size, or when they do.

Dare I mention that the WCAG 2 process actually took my comments on board? (Well, partially.) I have a feeling that the best approach is really a testing process rather than a guideline, as there are too many variables.

Titles on links are enough to identify pop-ups (Guideline 10)

Do not cause pop-ups or other windows to appear and do not change the current window without informing the user. (Plain text is the preferred method of informing the user. The title attribute on a hyperlink a element can suffice.)

I could be biased, as I’ve been saying for 5 years that title isn’t enough. However, the main reason I’ve been saying that is if you must inform the user (and you do, I’ve seen the confusion ensue when you don’t), then the method must work for all.

People who don’t use a mouse are the main audience, I don’t know how to get at a title attribute via the keyboard. If you use a screen reader, you theoretically can, but it tends to be at the expense of the actual link text due to mis-use of title by CMSs.

The text is ideally made part of the link, although if you use a lists of links it would be sufficient to mention about new windows in text above the list.

Images for text

The guideline preventing the use of text in images is repealed:

There is no prohibition against using pictures of text (”images to represent text”) if correct text equivalents are provided.

Traditionally our advice has been not to use images for text, although above a certain size (we settled on a fairly arbitrary figure of 16px) it would be ok, because anyone needing more magnification than that should have a full screen magnifier.

Even with the best screen magnifier, small text within images can cause issue for people with moderate visual impairments.

Deprecating the q element

You do not have to use the q element; you do have to indicate inline quotations, as by the use of quotation marks or figure dashes.

This may be more of a content issue that specifically an accessibility one, but I quite like the ability to add a cite attribute and use it to link through to the source. I’m also slightly surprised that the internationalisation aspects don’t appeal either.

Keywords first

The WCAG guideline is to Place distinguishing information at the beginning of headings, paragraphs, lists, etc., which the errata removes.

I have seen this issue in testing: A page had many links starting “Chapter X: keywords”. Each screen reader user gave up by the 3rd item, skipping elsewhere in the page, even though that was the correct place to be looking. It also caused issues for those with cognitive issues (specifically dyslexia that I’ve noted), who would skim over the text and move on.

Another common example is including the whole URL in a link (for misguided accessibility reasons), so each link starts “http://www”, quite frustrating to skim.

Skip links

Skip links have gone with the rest of the Priority 3 checkpoints, and although replacements are on the way (WAI-ARIA), there is some time to go before they are recommended, let alone mainstream.

How organisations might react

You have to wonder how it will be received. It has to be said that it will muddy the waters somewhat. We already have enough trouble explaining that a national scheme such as See It Right are merely a re-badged version of WCAG 1.0, without having to explain the difference between WCAG 1.0, WCAG+Samurai and WCAG 2.0.

If you take WCAG 2 out of the equation, then adding these errata would be a no-brainer. Even with WCAG 2, previous versions of the draft stated that it did not supersede WCAG 1, and overall I suspect these sets of guidelines are not mutually exclusive. I suspect that once the HTML techniques come out, they will be fairly similar to the combined WCAG+Samurai.

Curiosities and clarifications

Since I’ve had no part of the process until this point, a few thing occurred to me when reading through that I’m curious about:

• Do some technologies actually make use of hreflang at the moment?
• Are previously entered values suitable as default characters for inputs?
• Surely it would be difficult or impossible to suitably tag some of the PDF examples given? (E.g. Maths equations.)
• Allowing custom DTDs, could put the thought into people’s heads of developing a deliberately inaccessible DTDs/schemas!

About me

Alastair Campbell, Director of User Experience at Nomensa.

I have been working with the WCAG 1 guidelines since 2001, building sites to be accessible, conducting audits on client sites, and comparing the results to actual usability testing with people with disabilities. Google alastc or alastairc for more, since the results for my name generally get swamped by some political guy.

To be clear, I don’t know more than anyone else at this stage. In fact, given the mystery surrounding the project I’ve considered that it could be Joe creating the errata alone, or 10 famous names that didn’t want to be seen as criticising the W3C. Either is possible as far as I know, I’ve only met Joe Clark once, at a UK government event last year.