Day 66: Circling Back to WCAG and Other Standards

Published on 04 Feb 2019

• journal
• was
• specifications

Getting myself organized this week to continue studying is proving a bit challenging. The next section I've segued into within the WAS Body of Knowledge (BOK) is Section II list item B: Determine conformance to accessibility specifications based on accessibility issues found.

Suggested study topics within that section include:

• Re-familiarizing myself with the specifications (WCAG, WAI-ARIA, and ATAG), and determine which success criteria apply to which conformance level.
• Distinguish between failures of accessibility criteria versus other bad accessibility practices that are not referenced in one of these specifications.

It took me a lot of re-reading this section several times to finally decide how to proceed, what I needed to focus on, and divide up each day of this week.

• Interpreted the WAS BOK study material to determine a course of action this week.
• Began review of my WCAG cheat sheet to prepare for mapping failures to success criteria.

The first thing that confused me when I first read this part of the BOK was the mention of pointing out accessibility failures, but don't point all of them out. What?! A failure is a failure, and something that's inaccessible is inaccessible, right? What finally dawned on me was that I was thinking just in terms of WCAG, especially since WCAG was used as examples throughout. This section is really saying,

1. Find out what conformance level you have to measure your client's site against.
2. When a failure is found, cite the criterion that it failed.
3. Don't point out accessibility issues that are not within the measuring stick of which you are using.

After 66 days of focusing on web accessibility, I've found that I'm retaining things better than I hoped, understanding concepts more deeply, and can quickly research something now that I have so many resources and correct terminology at hand. The biggest transition that is happening in my brain is the change of focus from technicalities (code and standards) to a focus on the people using our sites and the challenges they face. The standards are still important to me, but they are more of a means to achieve my goal of enabling people with disabilities to surf the web just like everyone else. Technicalities worked as a good starting point. However, starting with understanding (empathizing with) people and the barriers they face would seem to be an even better place to start, so that the technicalities come easier.

This image comes to mind when expressing Tim Berners-Lee's dream to build an open web that's for everyone:

All that being said, this week I'm going to enjoy putting the puzzle pieces together when it comes to mapping failures with standards, all the while, reinforcing the reasons behind those standards (the people!).