Web Accessibility Training
Toronto, Montreal, Ottawa and worldwide via Webex More

What did WCAG 2.0 do for people with low vision and cognitive disabilities?

WCAG did as much as any standard could possibly do in 2008. There are many of the following WCAG SCs embedded in law and we provided plenty more guidance for web masters who want to do the right thing. We required the following:

  • all information be available in text opening up a clear pathway for assistive technology and parsing engines to manipulate that text for people with cognitive disabilities that would simplify language and manipulate it into symbols, and hundreds of other possibilities.  (SC 1.1.1)  
  • everything to have color contrast for low vision (1.4.3, 1.4.6)
  • images of text not be used because they pixelated under magnification(1.4.5)
  • all text be resized for low vision (1.4.4)
  • low or no background noise which minimizes audio distractions (1.4.7)
  • text colors be selected (low vision and cognitive) (1.4.8)
  • text not to be justified, (low vision and cognitive) (1.4.8)
  • adjustable line spacing, (low vision and cognitive) (1.4.8)
  • resizing with no horizontal scroll (1.4.8) (low vision and cognitive)
  • no images of text at all (1.4.9) (low vision)
  • timing to be adjustable at least 10x the default length. (Cognitive)
  • that distracting movements not be on the page unless they can be paused stopped or hidden ( 2.2.2) (cognitive)
  • no timing at all be used without exceptions (2.2.3) (cognitive)
  • distracting interruptions can be postponed or suppressed by the user (2.2.4) (cognitive)
  • when a session expires the user can continue without having to remember all their data (2.2.5) (cognitive)
  • web sites not triggers epileptic seizures (2.3.1)
  • a simple and descriptive page title to give users a quick understanding of what was on the page (2.4.2) (cognitive and low vision)
  • visible focus so that people who could not use a mouse because of dyslexia or other cognitive issues, could follow the cursor (2.4.7) and use a keyboard to operate the site (2.1.1)
  • link text told users where the link went (2.4.4, 2.4.9) (cognitive)
  • the language of the page to be marked up so that screen readers for people who could not read, or were illiterate, or had dyslexia, could surf the page with the proper speech engine (3.1.1) and that it would change speech engines when the language changed. (cognitive)
  • unusual words, idioms and jargon be identified (3.1.3)  (cognitive)
  • abbreviations be expanded and their meanings available (3.1.4) (cognitive)
  • a pronunciation be identifiable (3.1.6) (cognitive)
  • the user not be sent to strange or confusing places on focus (3.2.1) or on input (3.2.2) (cognitive)
  • consistent navigation (3.2.3) and consistent identification of controls (3.2.4)
  • any change of context be initiated by the user so they would not be confused (3.2.5)
  • error fixes be suggested 3.3.3 and that legal commitments be reversible, checked or confirmed (3.3.4) and strengthened those requirements in 3.3.6 (cognitive)
  • context sensitive help (3.3.5) (cognitive)
  • the code be parse properly, paving the way to cognitive AT that could make use of clean code. (4.1.1) (cognitive)
  • finally, any custom widgets expose themselves to assistive technologies to help their users operate and understand them. (4.1.2) (cognitive)

We brought the plumbing to the door. I hope we can continue this tradition of service to ALL people with disabilities in this new version. In ways that are operable, implementable, testable, and achievable.

Feel free to comment on Twitter @davidmacd

Author information:

David MacDonald is a veteran WCAG member, co-editor of Using WAI ARIA in HTML5 and HTML5 Accessibility Task Force Member. Opinions are my own.


For a quote or just to chat about your organization's needs


help -at- can-adapt.com
(replace -at- with you know what)