Day 87: Guidelines, Laws, and Myths

My intention today was to complete the first Deque course within the WAS certification prep program. I did do that, but not without being led to more resources that I need to read through. I’ve done a little research into US laws, but I need to read them again, plus read other laws mentioned in what I reviewed today. Looks like tomorrow’s study session is laid out for me.

Thing I accomplished

Completed guidelines, laws, and myths sections of Deque’s Accessibility Fundamentals.

What I reviewed today


Principles, guidelines, and authoring practices help create an accessible interaction between user and website or application. These guidelines and practices ensure that a variety of disabilities are taken into consideration.

I covered these more in detail on my own, which I’ve journalled on this site, but Deque does a decent job of getting the learner started with the basic principles and guidelines, and points them to official specifications. I’ll admit, I need to go back and spend some serious review time to go over all these.


Web accessibility laws usually fit into one of the following categories:

  • civil rights: discrimination against disabilities (Americans with Disabilities Act)
  • procurement: purchasing accessible IT products (Section 508 of the Rehabilitation Act)
  • industry-specific: regulations for private industries (21st Century Communications and Video Accessibility Act, Air Carrier Access Act)

United States



Other Regions

The Web Accessibility Initiative (WAI) has a comprehensive list of international accessibility policies. Additionally, PowerMapper has a list of government accessibility standards.

Myths and Misconceptions about Accessibility

  1. It benefits only a small minority. Truth: It actually benefits everyone.
  2. It’s a short-term project. Truth: It’s on-going.
  3. It should be the last step. Truth: It needs to start at the beginning of the project and last throughout the project’s life cycle.
  4. It’s hard & expensive. Truth: Remediation is harder and more expensive than considering it throughout the life cycle.
  5. It’s ugly. Truth: Most accessibility features are not visible to everyone.

Best takeaway

“Inaccessible web sites are not just inconvenient for people with disabilities, they are blocking.”

Day 74: Striving for WCAG Level AAA, Part 3

Today I spent time with the Understandable Level AAA criteria. Some of the Readable Guideline’s success criteria (SC) seem like a nice effort to make for everyone who comes to your site. However, I can see how that can take a lot more communication between content creator and developer to provide the necessary additional content or appropriate code to implement sufficient techniques correctly.

Things I accomplished

  • Read Understandable’s Level AAA success criteria on How to Meet WCAG 2 site.
  • Mapped success criteria to failures of those criteria.

What I learned today

There are 7 Level AAA criteria under Understandable, none of which are new to 2.1:

  • 3.1.3 Unusual words
  • 3.1.4 Abbreviations
  • 3.1.5 Reading level
  • 3.1.6 Pronunciation
  • 3.2.5 Change on request
  • 3.3.5 Help
  • 3.3.6 Error prevention (all)

There are 0 Level AAA criteria under Robust.

Examples of Understandable Level AAA failures

SC 3.1.3 Unusual words Fail: Specialized words are used in the content, but no definitions are provided. Providing definitions or a glossary would greatly benefit people with cognitive, language, and learning disabilities.

SC 3.1.4 Abbreviations Fail: Abbreviations are present, but no expanded form is available on the page, in assumption that the user already knows what it means. This can create confusion for people with cognitive issues or those using a screen magnifier (which challenges contextual cues).

SC 3.1.5 Reading level Fail: No summary or additional visuals are provided for reading level below 8th grade. This may inhibit people with reading disabilities or English as a second language from understanding your content.

SC 3.1.6 Pronunciation Fail: No audio or text pronunciation is provided for difficult words. This hinders people who use screen readers and people with reading disabilities from fully understanding the content provided.

SC 3.2.5 Change on request Fail: A new window opens when the user clicks on a link without the user expecting the change of focus to a new window. Related to SC 3.2.1 and SC 3.2.2. This greatly affects people who use screen readers.

SC 3.3.5 Help Fail: A form supplies no detailed instructions about data format or additional information necessary to submit the form. Leaving out required information and helpful tips can hinder people with visual, cognitive, or motor disabilities form submitting the form correctly.

SC 3.3.6 Error prevention (all) Fail: A form that is not a legal, financial, or data transaction fails to provide a reversible, review, or confirmation step when error is possible. Related to SC 3.3.4. This may affect people with reading or motor disabilities.

Day 73: Striving for WCAG Level AAA, Part 2

Carrying on from Part 1, today I spent time with the Operable Level AAA criteria. There are a few, I feel, that should be on a lower conformance level, as well as best practice for web designers.

Things I accomplished

  • Read Operable’s Level AAA success criteria on How to Meet WCAG 2 site.
  • Mapped success criteria to failures of those criteria.

What I learned today

There are 12 Level AAA criteria under Operable:

  • 2.1.3 Keyboard (no exception)
  • 2.2.3 No timing
  • 2.2.4 Interruptions
  • 2.2.5 Re-authenticating
  • 2.2.6 Timeouts (new in 2.1)
  • 2.3.2 Three flashes
  • 2.3.3 Animation from interactions (new in 2.1)
  • 2.4.8 Location
  • 2.4.9 Link purpose (link only)
  • 2.4.10 Section headings
  • 2.5.5 Target size (new in 2.1)
  • 2.5.6 Concurrent input mechanisms (new in 2.1)

Examples of Operable Level AAA failures

SC 2.1.3 Keyboard (no exception) Fail: Div element has been scripted to be clickable, but is not identified as a link to assistive technology. This makes custom page navigation more difficult for people who use screen readers or voice input.

SC 2.2.3 No timing Fail: Web app forces a time limit on the user. This can make use of the web app harder for people with cognitive or motor impairments.

SC 2.2.4 Interruptions Fail: User is not given an option to delay or request non-emergency updates. Interruptions can be disorienting for a person who uses a screen reader when their cursor focus is forced elsewhere.

SC 2.2.5 Re-authenticating Fail: Form data is not saved when the user is timed out of a session. This can be frustrating for people who have motor or cognitive impairments.

SC 2.2.6 Timeouts (new in 2.1) Fail: Users are not explicitly warned about data loss due to inactivity time limits.

SC 2.3.2 Three flashes Fail: A video on the page contains three or more flashes in a 1-second period. This can greatly affect people who are prone to seizures.

SC 2.3.3 Animation from interactions (new in 2.1) Fail: Decorative animation that occurs when a user interacts with an element does not have a “reduce motion” option for users to turn it off. Animation can cause nausea for people with vestibular disorders and distraction for people with attention disorders.

Side note: This concept introduced me to the Reduced Motion media query. Before today, I didn’t know that existed!

SC 2.4.8 Location Fail: Users page location within that website is not evident. Breadcrumbs, sitemap, nor highlighted navigation bar has not been provided. This affects people with attention disabilities (as well as everyone else).

My two-cents: This seems like it should be good practice and common courtesy to help everyone find their way around your site. I had no idea it was Level AAA and have considered using breadcrumbs as part of business as usual when I build more pages for large sites.

SC 2.4.9 Link purpose (link only) Fail: Generic and unclear text is provided within hyperlinks. This can be confusing for people who use screen readers and voice input, as well as those with cognitive disabilities.

SC 2.4.10 Section headings Fail: Text-heavy content and instructions are provided on a page without any additional headings to segment sections of text for clarity. This greatly affects people with visual and cognitive disabilities.

Confession: This is a bit of a pet peeve of mine, and I often feel this should be part of best practice for web designers. It especially irritates me when I see lists nested within lists, but not headings are provided to chunk and clarify content areas that are text-rich. Please make your page more navigable for everyone by including section headings.

SC 2.5.5 Target size (new in 2.1) Fail: Interactive buttons and customized links are less than 44×44 pixels. This can make it especially hard for people with motor disabilities to activate the button or link.

Added note: this is already making its way into mobile web app best practice, which is where I was first introduced to this concept. I’m happy to see it considered as an accessibility issue, too.

SC 2.5.6 Concurrent input (new in 2.1) mechanisms Fail: Interactive components on a page restrict input from other input devices other than touch. Therefore, this restricts who uses that page because people of all abilities use their input device (or devices) of choice.

Day 72: Striving for WCAG Level AAA, Part 1

Originally, I thought I was going to do Level AAA conformance in one sitting. Turns out there were 28 additional criteria! To better digest the techniques and failures associated with these criteria, I had to break that reading up into three study sessions, given I spend approximately 1.5 hours a day studying. Not to mention, I find myself falling down a documentation rabbit hole to learn more about points I’m extremely curious about.

Things I accomplished

  • Read Perceivable’s Level AAA success criteria on How to Meet WCAG 2 site.
  • Mapped success criteria to failures of those criteria.

What I learned today

There are 9 Level AAA criteria under Perceivable:

  • 1.2.6 Sign language (prerecorded)
  • 1.2.7 Extended audio (prerecorded)
  • 1.2.8 Media alternative (prerecorded)
  • 1.2.9 Audio-only (live)
  • 1.3.6 Identify purpose
  • 1.4.6 Contrast (enhanced)
  • 1.4.7 Low or no background audio
  • 1.4.8 Visual presentation
  • 1.4.9 Images of text (no exception)

Examples of Perceivable Level AAA failures

SC 1.2.6 Sign language (prerecorded) Fail: Sign language is not provided along with a prerecorded video. This SC benefits deaf who rely on American Sign Language as their first language.

SC 1.2.7 Extended audio (prerecorded) Fail: Movie moves to quickly to accommodate synchronized audio description. Video needs to be extended for substantial audio description. This SC enables blind and visually impaired to better understand what the movie is conveying.

SC 1.2.8 Media alternative (prerecorded) Fail: Full text transcripts of equal experience for a prerecorded video are not provided  This SC benefits people who have a combination of visual and auditory impairments.

Confession: I often confuse captions and transcripts. They are not the same and do not provide the same access to everyone. Ultimately, captions are the bare minimum. Transcripts are more inclusive.

SC 1.2.9 Audio-only (live) Fail: No text alternative, like live captioning, was offered during a live audio performance. This would benefit people with auditory

SC 1.3.6 Identify purpose Fail: Landmarks are not identified across the page. This inhibits the adaptability of the page to meet the needs of those with cognitive disabilities. Related to SC 4.2.1.

SC 1.4.6 Contrast (enhanced) Fail: Contrast of foreground text/images over background does not meet the 7:1 ratio. This enhanced criterion makes it easier for people with low vision or colorblindness to perceive content. Related to SC 1.4.3.

SC 1.4.7 Low or no background audio Fail: An audio track that is embedded on the page that contains a speech with background music doesn’t offer the user the ability to turn off the background music. This criterion is meant to enhance the distinguishability of that speech for people who are hard of hearing.

SC 1.4.8 Visual presentation Fail: Paragraph text is justified. This presents reading challenges to those with reading, cognitive, or visual disabilities.

Confession: I strongly feel that SC 1.4.8 could easily be pushed into Level AA, so more people would strive for better visual presentation for all users, since it strikes me as just good practice and even common courtesy for everyone. I mean, who doesn’t benefit from left-aligned text, greater line spacing, shorter paragraph width, a choice or foreground/background colors, and elimination of horizontal scrolling of text??

SC 1.4.9 Images of text (no exception) Fail: Images of text (not including the brand logo) are present throughout the site. People who zoom or magnify their screen would benefit greatly from the elimination of all images with text. Related to SC 1.4.5.

Off topic but interesting

Today I learned that there are over 120 HTML elements from 4.01 on up to 5.2. Then there are all those attributes to go along with them. This huge inventory just confirms to me that more developers should spend more time with the “basics” of HTML. Some parts of Level AAA could be more achievable (i.e. SC 1.3.6) if people spent more time understanding the building blocks, along with CSS, rather than focusing on the “perfection” of JavaScript and other programming languages to get the front-end job done.

Day 71: How to Fail WCAG Level AA, Part 2

Continuing on from Part 1 with how to pass or fail WCAG Level AA…

Things I accomplished

  • Read Operable, Understandable, and Robust success criteria (Level AA) failure techniques on How to Meet WCAG 2 site.
  • Mapped success criteria to failures of those criteria that I’ve encountered or read about.

What I learned today

There are only 3 additional operable success criteria:

  • 2.4.5 Multiple ways
  • 2.4.6 Headings and labels
  • 2.4.7 Focus visible

There are only 5 additional understandable success criteria:

  • 3.1.2 Language of Parts
  • 3.2.3 Consistent navigation
  • 3.2.4 Consistent identification
  • 3.3.3 Error suggestion
  • 3.3.4 Error prevention (legal, financial, data)

There is only 1 additional robust success criterion, which was added in 2.1:

  • 4.1.3 Status messages (new to 2.1)

Examples that fail base conformance


SC 2.4.5 Multiple ways Fail: Not enough options to explore the website for people who have visual or cognitive disabilities. Provide alternative ways to navigate via search, sitemap, or table of contents.

SC 2.4.6 Headings and labels Fail: No section titles have been provided for a text/content-heavy page. This eases navigation for people with visual, motor, and cognitive impairments (and everyone else).

SC 2.4.7 Focus visible Fail: Focus outline was removed for input controls. This impacts keyboard-only users who need to see their navigation points throughout the page.


SC 3.1.2 Language of Parts Fail: Paragraph and span elements do not contain a lang attribute when a change of language is obviously present. This impacts understanding for anyone, but especially impacts screen reader users and browsers that need explicit identification of document and parts of text language. Related to SC 3.1.1.

SC 3.2.3 Consistent navigation Fail: Global navigation links are not consistent in presentation and order across the website. This can be confusing for anyone, but especially impacts people with cognitive impairments.

SC 3.2.4 Consistent identification Fail: Components with the same function are not consistently labelled across the website, which impairs recognition of similar tasks and functionality. Related to SC 1.1.1 and SC 4.1.2. This can affect people with visual or cognitive impairments.

SC 3.3.3 Error suggestion Fail: No description of required input error is provided client-side nor server-side. Related to SC 3.3.1 and SC 3.3.2. This can affect people with visual or cognitive impairments.

SC 3.3.4 Error prevention (legal, financial, data) Fail: During an online data transaction, the user is not given an opportunity to review, correct, or reverse the form data being submitted. Especially on multi-step forms that requires a few pages, this can affect people with cognitive disabilities.


SC 4.1.3 Status messages (new to 2.1) Fail: A role=”status” was not assigned to a search update that returned x-amount of results. Role needs to be assigned to the status update of how many results found. This can greatly impact visually impaired who use screen readers.

You can quickly find what you need

Last night (in bed, of course), I was thinking about how the WCAG Quick Reference could use some filtering options, like tags, in order to quicken my information discovery. Well, someone was already thinking of this! They have many filters, including WCAG version, tags, conformance levels, techniques, and technologies, set up to help people find what they’re looking for:

Filter tab open revealing options like version, tags, levels, and techniques.

I should have explored this option earlier in my week!

In conclusion

9 more success criteria across three principles is not too much more to ask of designers and developers. To reinforce that idea, I don’t find these nine criteria especially hard to implement.


Day 70: How to Fail WCAG Level AA, Part 1

The last three days I’ve reviewed failures for WCAG Level A within Perceivable, Operable, and Understandable and Robust. Now it’s time to step up our expectations and look out how we’re all fairing at the middle conformance level: Level AA.

Things I accomplished

  • Read through Perceivable success criteria (Level AA) techniques on How to Meet WCAG 2 site.
  • Mapped success criteria to failures.

What I learned today

Within the Perceivable principle, there are 11 additional success criteria to meet Level AA conformance within the latest WCAG recommendation (2.1).

5 SC within WCAG 2.0:

  • 1.2.4 Captions (live)
  • 1.2.5 Audio descriptions (pre-recorded)
  • 1.4.3 Contrast (minimum)
  • 1.4.4 Resize text
  • 1.4.5 Images of text

6 more SC added in WCAG 2.1:

  • 1.3.4 Orientation (new to 2.1)
  • 1.3.5 Identify input purposes (new to 2.1)
  • 1.4.10 Reflow (new to 2.1)
  • 1.4.11 Non-text contrast (new to 2.1)
  • 1.4.12 Text spacing (new to 2.1)
  • 1.4.13 Content on hover or focus (new to 2.1)

Examples that fail base conformance

SC 1.2.4 Captions (live):  In Level A, pre-recorded video with audio required captions. Level AA conformance fails when no open/closed or synchronized text stream is provided with captioning during live synchronized video with audio. This affects people with hearing impairments.

SC 1.2.5 Audio descriptions (pre-recorded): In Level A some sort of alternative (AD or text) needs to be provided for videos. Level AA conformance fails when there is no audio description track provided. This presents a challenge to users who may not be able to see the video.

SC 1.3.4 Orientation (new to 2.1): The user is prevented from using landscape view within a web app that does not essentially need to remain in portrait view. This affects people who magnify the screen and choose to view webpages in landscape.

SC 1.3.5 Identify input purposes (new to 2.1): No input data type or instructions for restricted data input are conveyed to the user. This affects people who use screen readers and some people with cognitive disabilities.

SC 1.4.3 Contrast (minimum): Background color and foreground text color have a contrast ratio of under 4:5:1 which makes it hard for people with visual impairments to perceive.

SC 1.4.4 Resize text: When text is resized within the browser at 200%, text is clipped. This makes reading your text difficult for people with visual impairments.

SC 1.4.5 Images of text: An image with text was used, even though it could have been presented in the same way with true text and use of CSS. This greatly affects people who magnify or zoom into their screen and the image pixelates.

SC 1.4.10 Reflow (new to 2.1): Media queries are absent. Content forces user to scroll horizontally and vertically. This presents a challenge to people who need to enlarge text or zoom into the screen.

SC 1.4.11 Non-text contrast (new to 2.1): Low contrast between text box and its background. No border is present. Like SC 1.4.3, this affects anyone with a visual impairment, including colorblindness.

SC 1.4.12 Text spacing (new to 2.1): Content boxes are restrictive in size and don’t allow for text spacing to be adjusted by the user without text being clipped. This greatly affects people with visual impairments, dyslexia, and cognitive disabilities.

SC 1.4.13 Content on hover or focus (new to 2.1): Custom tooltip is not persistent nor dismissable. This greatly affects people who magnify their screen.

In conclusion

I had to cut the list of Level AA SC in half since there are 20 additional criteria, in total. I’m feeling a little more confident about my organizations efforts to achieve Level AA, and am happy to see that other people are paying attention to color contrast and reflow issues. Pertaining to the Perceivable principle, I don’t think it takes to much effort to step up a level to remove even more barriers for people of all abilities.

Day 69: How to Fail the Bare Minimum of Understandable and Robust

Today I’m concluding Level A conformance evaluation, looking at the Understandable and Robust principles of WCAG.

Things I accomplished

  • Read Understandable and Robust success criteria (Level A) failure techniques on How to Meet WCAG 2 site.
  • Mapped success criteria to failures of those criteria that I’ve encountered or read about.

What I learned today

There are 5 bare minimum (Level A) success criteria recommended by W3C in order for websites to be understandable (readable, predictable). These success criteria are, as follows:

  • 3.1.1 Language of Page
  • 3.2.1 On focus
  • 3.2.2 On input
  • 3.3.1 Error identification
  • 3.3.2 Labels or instructions

There are 2 bare minimum (Level A) success criteria recommended by W3C in order for websites to be robust (compatible for assistive tech and adaptive strategies). These success criteria are, as follows:

  • 4.1.1 Parsing
  • 4.1.2 Name, role, value

When these seven success criteria are met, it enables people of different abilities, no matter what aids they use, to understand and continue using your online content and services.

Examples that fail base conformance

SC 3.1.1 Fail:  A lang attribute is not present on the html element. The language of the web document needs to be explicitly defined for screen readers and browsers.

SC 3.2.1 Fail: Link opens a new tab. This should be avoided if not critical for the user because it can be disorienting to people of all abilities. I still see this a LOT for links, in particular, where no alternative of additional warning text is provided.

SC 3.2.2 Fail:  Form submitted ‘onchange’ rather than allowing the user to submit the form when they were actually done. This impairs people from completing forms accurately and at their own pace.

SC 3.3.1 Fail: No descriptive error text was provided for required fields to help user know why their form was unable to submit.

SC 3.3.2 Fail: No label was associated with an input control by using ‘for’ and ‘id’.

SC 4.1.1 Fail: I’ve recently run across a few of these failures! They usually come down to typos. For instance, if quotes or brackets aren’t closed, or no space is left between attributes, it can create an incomplete picture for assistive technologies and browsers.

SC 4.1.2 Fail: No role, name, or state were provided on a custom component control with a div or span.

In conclusion

Though this evaluation was shorter, I recognized several things I knew to cause accessibility problems, but I didn’t realize how bare minimum they were in this specification and how long they’ve been around (none are new in 2.1). I would be bold enough to say that all of these are easy failures to avoid and come at no real cost to the developer who knows what she’s doing. Now, if you’ll excuse me, I have a few bare minimum things to fix in my code this week…

Tomorrow I’ll start looking at the next level up, which is a common goal for many organizations, including my own. I’ll find out if we’re meeting that goal or not!

Day 68: How to Fail the Bare Minimum of WCAG Operable

Yesterday I got a head start on looking through the Level A conformance fails within WCAG’s perceivable principle. To keep that momentum going, I’ll be traversing through the other “bare minimum” recommendations to make sites mostly accessible with minor challenges. Today my sights were set on Operable.

Things I accomplished

  • Read Operable success criteria (Level A) failure techniques on How to Meet WCAG 2 site.
  • Mapped success criteria to failures of those criteria that I’ve encountered or read about.

What I learned today

There are 14 bare minimum (Level A) success criteria recommended by W3C in order for websites to be operable (keyboard, mouse, touch, voice, switch). That’s almost half of Operable’s success criteria! These success criteria are, as follows:

  • 2.1.1 Keyboard
  • 2.1.2 No keyboard trap
  • 2.1.4 Character key shortcuts (new in WCAG 2.1)
  • 2.2.1 Timing adjustable
  • 2.2.2 Pause, stop, hide
  • 2.3.1 Three flashes or below threshold
  • 2.4.1 Bypass blocks
  • 2.4.2 Page titled
  • 2.4.3 Focus order
  • 2.4.4 Link purpose (in context)
  • 2.5.1 Pointer gestures (new in WCAG 2.1)
  • 2.5.2 Pointer cancellation (new in WCAG 2.1)
  • 2.5.3 Label in name (new in WCAG 2.1)
  • 2.5.4 Motion actuation (new in WCAG 2.1)

When these fourteen operable success criteria are met, it enables people who use assistive technology and adaptive strategies to access, navigate, and interact with your static and dynamic content.

Examples that fail base conformance

SC 2.1.1 Fail: Several projects I’ve worked on have implemented hover-only focus styling effects or tooltips/pop-ups that excluded keyboard users.

SC 2.1.2 Fail: Modals can be tricky to create. When the keyboard user has no way to close the modal (Esc or Tab to close button) and get back to the content, this SC doesn’t pass.

SC 2.1.4 Fail: Creating single-character keyboard shortcuts without giving the user control to deactivate or change those shortcuts can greatly affect keyboard and speech input users.

SC 2.2.1 Fail: I am guilty of the client-side meta redirect! I know now that setting a timer of any kind requires extra consideration for people who need more time to make decisions and understand what’s going on. There is no user control in this situation.

SC 2.2.2 Fail: Carousels, the bane of my existence, can easily fail this success criteria if it doesn’t have a pause, stop, or hide mechanism. It’s taking choice away from any user. Additionally, it makes content less perceivable by people with visual or cognitive disabilities.

SC 2.3.1 Fail: I’ve seen video ads, fixed a web page, that are not only distracting, but have a flashing when its trying to grab a users attention. If the contrast is high and lasts more then 3 flashes, it’s a fail. Not only does it fragment attention for people with cognitive disabilities, but could create a severe reaction for people with photosensitive seizure disorders.

SC 2.4.1 Fail: No additional links are provided to skip repetitive content or navigate to different regions of the page. This creates an exhaustive experience for keyboard users tabbing through that web page.

SC 2.4.2 Fail: This is a current issue I’m battling. A web page doesn’t have a unique title or descriptive title that identifies the pages purpose or intent.

SC 2.4.3 Fail: I’ve seen some bad tabindexing, which ruins the relationship between keyboard (or screen reader) navigation and understanding content’s logic.

SC 2.4.4 Fail: This is a recent fail I’ve found in a recent accessibility audit. An image is linked, but there is not alternative text given to that image to let a screen reader user know what it’s purpose is.

SC 2.5.1 Fail: Custom complex gestures (requires multiple touch points) for touch devices is difficult for people with motor disabilities and those who use assistive technology that cannot equate these actions.

SC 2.5.2 Fail: No room for touch error was enabled. People with visual, cognitive, and motor disabilities could suffer from accidental button activation or disorientation when inadvertently taken to another part of the site.

SC 2.5.3 Fail: Visible linked text is different from a hidden accessible name (i.e. title or aria-label), which becomes an unknown hidden voice command for people who use speech input to operate controls and navigate the webpage. It also confuses understanding of content for screen reader users.

SC 2.5.4 Fail: No alternative means of control activation other than device motion (e.g. shaking or tilting) is available. This can exclude people with motor disabilities.

In conclusion

This was a lot to digest in under two hours. However, these base recommendations are so critical in order for people with disabilities (and everyone else) to be able to operate, navigate, understand, and appreciate a site and its services. I cannot afford to glaze over them, but rather advocate for at least this bare minimum in sites I collaborate on.

Day 67: How to Fail the Bare Minimum of WCAG Perceivable

The next few days are going to feel like review. And, yet, the next few days should bring satisfaction of putting some of this knowledge to use.

Today I landed on looking over WCAG’s perceivable principle again in order to focus on the success criteria at the base conformance level, and dug into sufficient and failure techniques. My intention at this point in my journey was to approach this with another person’s perspective, and better understand how content and components might inadvertently be “invisible” to anyone who has a visual or auditory impairment or makes use of assistive technology.

Things I accomplished

  • Read Perceivable success criteria (Level A) failure techniques on How to Meet WCAG 2 site.
  • Mapped success criteria to failures of those criteria that I’ve encountered.

What I learned today

There are 9 bare minimum (Level A) success criteria recommended by W3C in order for websites to be perceivable (seen, heard, touched). These success criteria are, as follows:

  • 1.1.1 Non-text content
  • 1.2.1 Audio-only/Video-only (pre-recorded)
  • 1.2.2 Captions (pre-recorded)
  • 1.2.3 Audio description or media alternative (pre-recorded)
  • 1.3.1 Info and relationships
  • 1.3.2 Meaningful sequences
  • 1.3.3 Sensory characteristics
  • 1.4.1 Use of color
  • 1.4.2 Audio control

When these nine perceivable success criteria are met, it enables people with visual impairments and hearing impairments to enjoy your content and interactive components.

Examples that fail base conformance

SC 1.1.1 Fail: Customized radio buttons in a survey were invisible to me when I was using Windows High Contrast Mode. That’s because they used a background-image to replace the actual radio button, which was also set to opacity=”0″. This failure results in excluding people with visual or cognitive impairments who use HCM or custom stylesheets.

SC 1.2.1 Fail: Audio files of a recorded meeting do not have a transcript or long description that provides equivalent information in text format for people who have a hearing impairment.

SC 1.2.2 Fail: So often do I see recorded video with sound, but no captions are provided. As a note, YouTube does provide auto captioning which can be sufficient to meet SC 1.2.2, but could result as a failure if the captioning is not accurate and could leave out important information. A manual check may be necessary. This failure excludes people with hearing impairments.

SC 1.2.3 Fail: Also, another common fail. People don’t realize this is not a nice to have feature. Leaving out audio description in a video that has a lot of undescribed actions within the video is a fail at WCAG’s most basic level. This can exclude people with visual impairments.

SC 1.3.1 Fail: Another recent fail I found in an ongoing accessibility audit was the discovery of tables with out row or column headings identified. The relationship of the data isn’t explicit and may exclude people with visual impairments.

SC 1.3.2 Fail: Related to the prior fail of SC 1.3.1, I also found tables that were used for layout rather than relational data. This can confuse people who use screen readers (visual and cognitive impairments) when a table is read aloud, but the content’s relationship is meant to convey something else.

SC 1.3.3 Fail: I see this failure a lot in content I receive to post online. Within the content, a spatial location is inserted (e.g. “the photo to the right”). This is not only meaningless to people with visual impairments. It also is meaningless to mobile users who see a different layout on their smaller screen, but that isn’t an accessibility issue.

SC 1.4.1 Fail: Surprisingly, I still run across input error messages that stand out in red, but don’t offer any other indicator that the user has made an error. This can exclude people with visual disabilities from submitting forms.

SC 1.4.2 Fail: The days of inserting background music on a webpage seem far behind us, but what about those ads that autoplay on a webpage? If the autoplay doesn’t have a pause or close button, the page fails SC 1.4.2. I haven’t run across this fail personally, but it would interfere with a screen reader users interaction with the page due to the uncontrollable interruptions. Not to mention, how annoying that would be to everyone else visiting the site.

In conclusion

I’m horrified that many of the most basic success criteria still fail on a regular basis across the web. None of these are even new in WCAG 2.1. What really astounds me is how easy and inexpensive most of these techniques are to follow. Captions and audio descriptions aside, since those are usually outsourced and need to be budgeted, the other seven leave no excuses, in my mind. We need to do better to make the bare minimum part of business (development) as usual, and not even consider them an accessibility issue, but rather as best practice in content creation, design, and development.


Day 66: Circling Back to WCAG and Other Standards

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.

Things I accomplished

  • 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.

What I learned today

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:

Lights around a stadium spelling out

Caption: Lights around the London’s 2012 Olympic stadium describe Sir Tim Berners-Lee’s invention, the world wide web. The Open Data Institute, which he co-founded, declares a mandate of ‘Knowledge for Everyone’. Photograph: Martin Rickett/PA

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!).