Technical review

This page contains comments on the following issues within the WCAG Samurai Errata.

Some of the following comments pertain to the removal of the Level AAA checkpoints in the errata. Although many Level AAA checkpoints are now obsolete (such as placeholding characters, ascii characters and tabindex) there are several which still perform valid functions and should be incorporated into the errata. Please note that the WCAG Samurai have included a special note on cognitive disabilities and many of the Level AAA comments relate to access by this group.

Accessible technologies

The WCAG Samurai Errata assume that PDFs, scripting technology and Flash can be directly accessible and have rewritten the guidelines accordingly (PDF files published by the normal means… are not non-text information and do not need text equivalents). It is my opinion that although these technologies do contain some accessibility features they do not currently contain the type and variety of accessibility features inherent in HTML. I strongly believe that with the correct impetus the corporations responsible for these technologies will develop accessibility features that far surpass those available in HTML, but until that time I believe that these technologies must be considered non-text content and treated accordingly.

Testability

One of my biggest concerns with WCAG2 is the inclusion of the testability clause. Testability requires that the success criterion is testable via a machine or that 8 out of 10 human testers would agree on an outcome. The testability requirement outlaws many valid accessibility techniques such as the clear and simple content requirement. One of the problems with validity is that it removes decisions from the developers. The WCAG Samurai Errata contain a number of instances where the extent to which a checkpoint is fulfilled is left up to the developer. I commend the stand that the WCAG Samurai have taken on this issue. I believe the WCAG Samurai Errata is a much superior document because of it.

Cognitive disabilities

It is unfortunate that WCAG Samurai have not taken the opportunity to address the needs of people with cognitive disabilities. Increasingly this group are the largest group of people with disabilities accessing the web and their ability to do so is compromised by the lack of guidelines addressing their needs. This is an issue that WCAG2 also does not address sufficiently. I would like to see WCAG Samurai develop a set of cognitive disability guidelines to add to these errata. In addition to this there are some Level AAA checkpoints which I believe should be included in the errata:

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

The errata states: There is no practical way to comply with this guideline given that it implicitly requires authors to provide translations (not an accessibility issue) or different “content types” (eg. duplicating an entire web page in SVG, also not an accessibility issue). Ignore.
People with cognitive disabilities can vary in their preference for colour contrast, text size and font. Providing alternative displays of a page for this group is a valid accessibility technique. Providing aural style sheets is also a valid technique in assisting screen reader users however I have yet to see it implemented.

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

The errata states: Not all sites or pages require navbars. Ignore.
Navigation bars are of great importance to people with cognitive disabilities as they provide a consistent means of navigating within a particular site. Seeing as the errata allow for checkpoints that do not apply to all content (unlike WCAG2), adding this checkpoint to the errata with a proviso that it applies to sites of a particular size is not infeasible.

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

The errata states: You don’t have to provide multiple kinds of search (not an accessibility issue). Ignore.
Although it is true that this checkpoint specifically requires different types of searches for different skill levels and preferences and that this has no relevance to accessibility, the provision of targeted searches and contextual filters can greatly assist people with cognitive disabilities.

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

The errata states: 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.
Providing graphic or auditory versions of information is the equivalent of providing text of graphic and auditory information. Just as graphics are inaccessible to the blind, text can be inaccessible to people with cognitive disabilities.

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

The errata states: You may use any accessible “style” you wish, including styles that are not “consistent”.
People with particular types of cognitive disabilities find learning new systems difficult and thus consistency is important to them. Although there may be some cases where consistency is impractical, consistency should be the norm.

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. For instance, some people with dyslexia browse web sites with a screen reader which can reinforce the text that they can see. It is imperative to this user group that the reading order presented aloud via the screen reader matches the reading order they see on the page. This is also of importance to visual keyboard users who rely on tabbing through a page to navigate.

Validity

I commend WCAG Samurai on including this important technique in their errata. Validity is intrinsic to the rendering of web sites by user agents and the enforcement of validity will allow the development of better assistive technologies.

Captioning, audio descriptions and transcripts

The requirement to caption and audio describe is more stringent than the minimum requirement of WCAG1 (although captioning and audio description are Level A the fall-back checkpoint, 11.4, allows for a text transcript instead). This requirement is likely to remain controversial. Captioning and audio describing can be resource-intensive but not significantly more so than the development of a video. People with auditory disabilities often comment that a text transcript (even one that contains all the text and action of a particular video) is not accessible to them. In this case captions and audio descriptions are a necessary part of these errata.

Please note that I have previously argued against including captioning and audio descriptions in the minimum set of WCAG2. After discussions with people with disabilities I have reversed my position on this particular issue.

Tables

The outlawing of tables for markup is a welcome addition to the errata. I would like to see the errata include details of recent research into the rendering of table markup by assistive technologies.

Forms

There is little information in the errata about forms. The removal of requirements such as keyboard shortcuts, tabindex and placeholding characters brings these errata up-to-date with current technology ability. However, clarification should be included on the need for visual, descriptive field labels for all fields (currently defined as an “until user agent” clause in Checkpoint 10.1). In addition to this, certain techniques that assist people with disabilities could be included such as the inclusion of introductory information, alternative methods of contact and contextual help.

Distinguishing information

Checkpoint 13.8: Place distinguishing information at the beginning of headings, paragraphs, lists, etc.

The errata states: Headings are “distinguishing information,” and we know of no language that requires each paragraph to begin with “distinguishing information.” Ignore.
Some types of distinguishing information can be very useful to people with disabilities. These types of distinguishing information include hidden structural labels prior to menus or navigation, a summary page of a particular web site or a summary paragraph at the top of the page. Although I don’t believe there is a need to provide distinguishing information at the beginning of headings or paragraphs, distinguishing information in the form of hidden labels, headings and summary text is useful.

Skip links

Checkpoint 13.6: Group related links, identify the group (for user agents), and, until user agents do so, provide a way to bypass the group.

The errata states: Not all sites or pages have “related links” and the only HTML elements with relevant semantics work solely in forms (eg. optgroup)

Although often implemented as a workaround solution, this checkpoint has often been used as the reasoning behind including skip links. Skip links are important to a variety of groups of people with disabilities; such as those using screen readers and magnifiers. I would recommend including this checkpoint within the errata.

8 Responses to Technical review

  1. Már says:

    Preserving reading order
    Preserving the reading order of a page […] is an important accessibility technique for people with cognitive disabilities.

    Technically, any use of float and position:absolute; disrupts the correlation between visual- and reading-order. Where does one draw the line between acceptable and unacceptable use of CSS layout techniques?

    Placing the most important content at the beginning of the document has direct influence on search-engine indexing and the readability/accessibility of the site on various small-screen and/or extremely low-bandwidth devices.

    It seems that, in order to cater to both of these view-points, one would have to outlaw popular graphic-design patterns such as, placing multi-level navigation menus, login- and search-forms in the header section of the page. Technically, classic left-to-right reading order would also make left-columns implicitly suboptimal.

    I think this issue deserves further discussion.

  2. samuraireview says:

    @Mar, reading order is one aspect of accessibility that often conflicts with other business requirements for the reasons you give above – small screen, low bandwidth, searchability etc. However it is an important accessibility requirement, and not just for people with cognitive disabilities.

    Users with physical impairments that cannot use a mouse often navigate a page using the keyboard (most often the TAB key). In a site that reverses the position of elements through CSS, this ability to navigate is lost. As I mentioned above this reversal of reading order is also a problem for people with cognitive disabilities as some groups navigate the page while listening to the contents via a screen reader – matching the HTML order and CSS order is imperative to this group also.

    I don’t believe that preserving reading order does outlaw left hand or top level navigation, search forms or header sections. These elements can remain at the beginning of the page as long as a visual skip link is provided to users (such as screen reader and magnifier users) that wish to jump over this content.

    Gian

  3. Már says:

    Skip links make web pages with loads of “cruft” content at the top, easier to cope with but it doesn’t exactly make them efficient or search-engine friendly.

    Users with physical impairments that cannot use a mouse often navigate a page using the keyboard (most often the TAB key). In a site that reverses the position of elements through CSS, this ability to navigate is lost.

    I appreciate the problems floated and/or “absolutely positioned” content can cause for sighted screen reader users with cognitive disabilities.

    However, as fairly frequent user of the TAB key as means of navigation within web pages (I’m eccentric, I like to use the keyboard), I have personally never experienced any problems using/navigating pages with “absolutely positioned” content – especially if there are (visible) skip-to-navigation links in place. I actually rather like it when the keyboard focus traverses down the page much in line with my locus of interest in the content – skipping cruft items near the top and on the sidelines.

    There seem to be conflicting sets of interests here, and something tells me the Samurai made the right decision to remove this requirement from the guidelines.

  4. samuraireview says:

    @Mar, I do agree that there are conflicting sets of interests here, however the only group that I am interested in is those with disabilities.

    However, as fairly frequent user of the TAB key as means of navigation within web pages … I have personally never experienced any problems using/navigating pages with “absolutely positioned” content

    Your preferred method of navigation may be via a keyboard but that is not the same as if your only method of navigation was via a keyboard. I don’t think you can compare how you browse a site to how someone with a physical impairment reliant only on a keyboard does.

    …never experienced any problems using/navigating pages with “absolutely positioned” content – especially if there are (visible) skip-to-navigation links in place.

    Yet skip links are currently not included in the WCAG Samurai Errata. In WCAG2 skip links are required, but they are not required to be visible.

    There are many compromises when it comes to accessibility. But, at the end of the day, I am an accessibility specialist – my interests lie in assisting people with disabilities and not increasing the search engine ranking of a site. Where a client believes search engine ranking superior to accessibility then I would consider alternatives – but only after trying to convince them otherwise.

  5. Már says:

    @Samuraireview, in your earlier comment you stated that the ability to navigate [with TAB] is lost when a site’s visual design has absolutely positioned content. I simply disagree with that statement.

    I like skip links – used in moderation. I consider the deletion of Checkpoint 13.6 (as it stands in WACG1) to be a good thing, because read literally it calls for stupid skip links just about everywhere.

    However, after thinking about it some more, I think the Samurai should not have deleted it outright, but changed it’s wording to encourage more practical/sensible use of skip links. Essentially something like “provide a way to bypass large chunks of related content” – or “provide links to help people with linear means of reading/navigating the document to traverse it efficiently”. …or something like that.

    One form of visible skip links I’ve experimented with recently, is to hide the link (i.e. position it off-screen) by default, but turn it visible when it receives focus. The down-side is that mouse users never get to see/use the skip link, but the positive aspect is that the client and graphic designer are always happy. This method looks like the essential weapon of the guerrilla accessibility developer. :-)

  6. samuraireview says:

    One form of visible skip links I’ve experimented with recently, is to hide the link (i.e. position it off-screen) by default, but turn it visible when it receives focus… This method looks like the essential weapon of the guerrilla accessibility developer.

    @Mar, that solution sounds pretty good – I will have to remember that!

  7. Lars Gunther says:

    “This is the one and only draft version…”

    I wonder if anyone else has noticed that these errata really read like a draft. E.g. Guideline 11, bulletpoint 3, Point 4: “I really mean that…”

    Who is this “I”? Joe Clark?

    Even if I agree on most things said, I believe that a formal document should have a reasonably formal tone, and not contain any attacks on other parties. (W3 chairs acted like bullies… maybe true – I don’t know – but it’s the wrong place to write it.)

  8. Joe Clark says:

    Yes, we billed the draft version as a draft. Fancy that. It will contain mistakes, such as copying and pasting from my article for ALA on PDFs, then paper-editing out the mistakes, then managing not to change the actual file.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Follow

Get every new post delivered to your Inbox.

%d bloggers like this: