Category: wcag2

The Accessibility Interpretation Problem

Some aspects of digital accessibility can be straight-forward. But many are complex and can be subjective, especially when interpreting WCAG 2.0 guidelines. The following tweet is humorous because there’s a strong ring of truth to it—if you ask 10 accessibility specialists you will get 20 different answers.

Inconsistency in accessibility reporting can be a big problem in an organization and its employees. In the white paper A11Y Wars: The Accessibility Interpretation Problem, Glenda Sims (@goodwitch) and Wilco Fiers (@wilcofiers) do a deep dive into this issue. Topics in the paper include:

  • Summary of Findings
  • Causes of Interpretation Problems
  • Causes of WCAG 2.0 Interpretation Differences
  • Accessibility Peace Model
  • Standardization
  • Recommendations

The paper proposes an “Accessibility Peace Model” which helps clearly define the perspective your organization is using for accessibility testing. This will reduce inconsistencies in accessibility testing and reduce the natural tension between the goals of users, designers, developers, testers, trainers, project managers, and executive employees. In turn, this will save much time, hassle, and ultimately lower costs.

The Accessibility Peace Model recognizes that there are different, equally valid, ways to use WCAG 2.0. To get consistent results, organisations should define with what perspective they want their tests to be done. This is by no means the only measure that needs to be taken to ensure consistency, but it does make discussions on interpretations significantly more effective.

If your organization is serious about accessibility, consider reading A11Y Wars: The Accessibility Interpretation Problem.

This white paper was presented by Glenda and Wilco at CSUN 2018 in San Diego, CA, and are also presenting on the topic this week at AccessU 2018 in Austin, TX.

CSUN17 Review

Another successful CSUN Assistive Technology Conference has come and gone. Below is a curated list of slide decks, reviews, photos, and more. Also check out my CSUN17 preview.

Slides etc. from presentations

Feel free to cite more in the comments.

Workshops

Other reviews, etc.

More awesome stuff

WCAG 2.1 First public working draft. Also see Quick Guide to WCAG 2.1 First Public Working Draft by David MacDonald

By IBM Va11yS, or Verified Accessibility Samples, is a repository of live working code samples that designers and developers can easily access to test with different assistive technologies and tools.

OATMEAL – An accessibility testing methodology for the web, by eBay. Stands for Open Accessibility Testing Methods for Experts And Layfolk—nice!

Mind Your Lang by Adrian Roselli from role=drinks event.

Photos

Terry Thompson speaking on audio description at CSUN17
Terry Thompson speaking on audio description at CSUN17
Denis Boudreau fills the Deque Suite at CSUN17
Denis Boudreau fills the Deque Suite at CSUN17
Karaoke at CSUN17, Makoto and Matt lead C-S-U-N
Karaoke at CSUN17, Makoto and Matt lead C-S-U-N (to the tune of YMCA)

More from CSUN17 Flickr album by Dennis Lembree

WCAG Cheat Sheets

Here are some great checklists and filtering tools for the W3C’s Web Content Accessibility Guidelines—WCAG 2.0. Know any others?

W3C WCAG 2.0

Overwhelmed? Stick To Basics

A few people at the CSUN conference last week commented on the overbearing WCAG 2.0 specs. Many folks agree that WCAG is extremely large and difficult to read (not unlike the HTML5 spec). And especially for accessibility newbies, WCAG can be a difficult place to start.

In a session at CSUN, even the W3C WAI members said that beginners should not read the spec but start with other docs such as How To Meet WCAG2 which pulls the Understanding and Techniques together. The WAI is also working on a “Easy Checks” documents. Here’s a sneak peak to the draft titled Easy Checks – A First Review of Web Accessibility [link updated].

If you are feeling overwhelmed or confused about web accessibility, my advice is this: stick to the basics.

For design, this means not re-inventing HTML elements and behaviors. Particularly form elements, such as re-rendering a select dropdown for the sake of aesthetics. There’s also the horrible trend to make labels appear and function like placeholders.

For development, this means the proper foundational techniques. Namely, the four layers of web development:

  • Semantic HTML for content.
  • CSS for presentation.
  • JS to enhance behavior.
  • ARIA to fill any accessibility gaps.

This fun diagram on Flickr helps illustrate this point.

Using the four layers approach encourages the following good practices:

  • Separating content from presentation from behavior.
  • Maintaining code in external files.
  • Adding ARIA only when needed.

If these practices are implemented in a website, it’s well on its way to being accessible.

WCAG Improvements

It was such a relief when WCAG 2.0 became a W3C Recommendation back in December of 2008. But in the fast paced world of the web, nothing stays the same for very long. Even WCAG could use many improvements, especially after over three years. (Time sure flies!)

Jared Smith (@Jared_W_Smith) of WebAIM recently wrote an excellent article WCAG Next which explains some of the top issues and suggests how they can be improved. I pretty much agree with all. Here is a summary:

  • Remove the CAPTCHA Exception – should prohibit all CAPTCHA at Level AA.
  • Media Guidelines – a few suggestions here plus a recommendation for restructuring.
  • Contrast at Level A -minimal contrast requirement needed for Level A.
  • Decrease the 200% Text Resizing Requirement -biggest burden of Level AA.
  • Clarify Images of Text -this is subjective.
  • Specify Mechanisms to Bypass Blocks – add techniques such as skip-to, headings, landmark roles, and others.
  • “Can Be Programmatically Determined” -a confusing aspect of page conformance.
  • Require Keyboard Focus Indicators at Level A – “There is no reason why this should not be a Level A requirement.” Totally!
  • Remove Parsing Requirement – no direct benefit and difficult to test for accessibility; possibly move code validation requirement to Level AAA.