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.
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.
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.
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”?
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”.
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.
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 (
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.)
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?
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.
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.