Accessibility Principles for ICT (WCAG)

Accessibility is the successful access that people with disabilities have to content and spaces. As I mentioned at the end of Accommodation versus Inclusive Design, I concluded that accessibility is a mismatch between the design and a user’s needs. On the web (or with ICT – information and communication technology) we can create that match by starting with W3C’s web content accessibility guidelines (WCAG). The 4 principles of WCAG are:

  • perceivable: broadening the sensory experiences to include sight, sound, and touch,
  • operable: all interactive components and navigation are navigable and usable,
  • understandable: content, component functionality, and design are easy to understand, and
  • robust: content & functionality is compatible with a variety of browsers, devices, and assistive technologies.

Challenges on the web

I won’t go into further detail about all its success criteria just because I’ve written quite a bit about them while studying for the WAS exam. However, I do want to mention some common challenges that people face when on the web, and how accessible design can help designers and developers be aware of how to address these barriers.

Problem area
Solution(s)
Images
  • Use alternative text or a visible caption/description
Color
  • Supplement color-coding with other coding information (shapes, texture, etc.)
Contrast
  • Foreground color should stand out (high contrast) against the background color
Video & audio
  • Include captions and transcripts with video and audio files
  • Include audio description with video
Links
  • Use understandable text with intent, functionality, or destination of the hyperlink
Headings
  • Create a logical outline with the headings to make it well-structured and navigable
Keyboard access
  • Make each interactive component on the page reachable by the keyboard
  • All interactive components should create a logical tabbing order
  • Focus should be visible on interactive components
Tables
  • Assign headers to columns or rows
Forms
  • Explicitly assign a label to every form input
Dynamic JavaScript
  • Explicitly assign a name, role, state and/or properties
  • Assign point of focus when widgets are created
PDF documents
  • Create tags for all structures in a PDF

Universal design can help

Universal design creates products and environments that the vast majority of people can use, taking into account the natural physical diversity among people. Universal design doesn’t just think about people with disabilities, it thinks about a lot of people. By expanding our view from accessible design to universal design, we can make a more usable experience for a lot more people.

Stay tuned for my next post that will go further into universal design, its origins, and its solutions in the context of the physical world.

Additional reading

Day 100: WCAG and Motor Disabilities

Last official study day! I’ll continue to review my notes, WCAG, screen reader shortcuts, and work through Deque courses, but I will not feel obligated to post everyday after this. Summary of 100-day journey still to come.

A couple days ago, I covered WCAG and hearing impairments, so today I reviewed WCAG again to so how it benefits people with motor impairments that want to use the web.

Things I accomplished

What I reviewed

  • WCAG success criteria that benefit people with motor impairments;

What I learned from it

The following lists target WCAG success criteria that benefit people with motor impairments.

Level A

  • 1.3.2 Meaningful sequence
  • 2.1.1 Keyboard
  • 2.1.2 No keyboard trap
  • 2.1.4 Character key shortcuts (v2.1)
  • 2.2.1 Timing adjustable
  • 2.2.2 Pause, stop, hide
  • 2.4.1 Bypass blocks
  • 2.4.3 Focus order
  • 2.5.1 Pointer gestures (v2.1)
  • 2.5.2 Pointer cancellation (v2.1)
  • 2.5.4 Motion actuation (v2.1)
  • 3.2.1 On focus
  • 3.2.2 On input

Level AA

  • 1.3.4 Orientation
  • 1.4.13 Content on hover or focus (v2.1)
  • 2.4.5 Multiple ways
  • 2.4.7 focus visible
  • 3.3.4 Error prevention (legal, financial, data)

Level AAA

  • 2.1.3 Keyboard (no exception)
  • 2.2.3 No timing
  • 2.2.4 Interruptions
  • 2.2.5 Re-authenticating
  • 2.2.6 Timeouts (v2.1)
  • 2.5.5 Target size (v2.1)
  • 2.5.6 Concurrent input mechanisms (v2.1)
  • 3.2.5 Change on requesst
  • 3.3.6 Error prevention (all)

Day 98: WCAG and Hearing Impairments

Yesterday’s learning about how WCAG benefits people with visual impairments pushed me forward into more WCAG overview to see how it benefits people with hearing impairments (deaf and hard of hearing). Deafblind benefit from using the combined design techniques of visually impaired and hearing impaired.

Things I accomplished

What I reviewed today

  • Semantic structures that screen readers (and sometimes everyone):
    • links (WCAG 2.4.4, A & 2.4.9, AAA)
    • navigation between pages (WCAG 3.2.3, AA & 3.2.4, AA)
    • navigation on page
  • Navigation keyboard shortcuts for screen readers.
  • WCAG success criteria that benefit people with hearing impairments;

What I learned from it

Tips from Giles Colborne’s book Simple and Usable (as quoted in Web for Everyone:

  • simplicity is good science and good interface design
  • simple designs put complexity in its place
  • observe real people to learn what’s needed
  • designing for multiple devices supports accessibility

aria-describedby and aria-labelledby WILL access content that is inside a container hidden using aria-hidden="true".

aria-labelledby, aria-describedby, aria-label, and hidden text are some ways to let a screen reader user know of current page. Or use aria-current=”page” which has some support.

The following lists target WCAG success criteria that benefit people with visual impairments. The main concern for hard of hearing is to provide text or sign language alternatives to any sound provided.

Level A

  • 1.1.1 Non-text alternatives
  • 1.2.1 Audio-only & Video-only
  • 1.2.2 Captions (pre-recorded)
  • 1.2.3 Audio description or media alternative (pre-recorded)
  • 1.3.3 Sensory characteristics

Level AA

  • 1.2.2 Captions (live)

Level AAA

  • 1.2.6 Sign language (pre-recorded)
  • 1.2.8 Media alternatives (pre-recorded)
  • 1.2.9 Audio-only (live)

Day 97: WCAG and Visual Impairments

Yesterday’s learning about how WCAG benefits people with cognitive disabilities inspired me to look over WCAG again to see how it benefits people with visual impairments (blind and low vision).

Things I accomplished

What I reviewed today

  • Semantic structures that screen readers (and sometimes everyone):
    • page title (WCAG 2.4.2, A)
    • page and parts language (WCAG 3.1.1, A & 3.1.2, AA)
    • landmarks (WCAG 4.1.1, A)
    • headings (WCAG 1,3,1, A & 2.4.6, AA & 2.4.10, AAA)
    • links
  • Navigation keyboard shortcuts for screen readers.
  • WCAG success criteria that benefit people with visual impairments;

What I learned from it

The support among screen readers is better for the simple two-letter language codes (like “en” for English) than for the localized language codes (like “en-au” for Australian English).

Screen readers list forms only if marked as role="form" (the <form> element will be ignored in landmark lists).

The name of a link is calculated as follows (in order of precedence by screen readers):

  1. aria-labelledby
  2. aria-label
  3. Text contained between the opening <a> and closing </a> elements (including alt text on images)
  4. title attribute (note that this is considered a last resort method for screen readers to find something; it should not be considered a primary technique for giving names to links)

If headings have images, the alt text will be show up in the headings list. Linked images (whether HTML img or CSS background image) can be assigned aria-label or aria-described by. Spans can hide extra meaningful content for screen readers. All these alternatives make me wonder how that impacts people with cognitive disabilities or people who use speech recognition. It’s so important to design for more than one disability.

There are so many success criteria for this disability, compared to cognitive disabilities, but I imagine that’s because it is more objective and measurable. The following lists target WCAG success criteria that benefit people with visual impairments.

Level A

  • 1.1.1 Non-text alternatives
  • 1.2.1 Audio-only & Video-only
  • 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
  • 2.1.1 Keyboard
  • 2.1.2 No keyboard trap
  • 2.1.4 Character key shortcuts (v2.1)
  • 2.2.2 Pause, stop, hide
  • 2.4.1 Bypass blocks
  • 2.4.2 Page titled
  • 2.4.3 Focus order
  • 2.4.4 Link purpose (in context)
  • 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
  • 4.1.1 Parsing
  • 4.1.2 Name, role, value

Level AA

  • 1.2.5 Audio description (pre-recorded)
  • 1.3.5 Identify input purposes (v2.1)
  • 1.3.4 Orientation (v2.1)
  • 1.4.3 Contrast (minimum)
  • 1.4.4 Resize text
  • 1.4.5 Images of text
  • 1.4.10 Reflow (v2.1)
  • 1.4.11 Non-text contrast (v2.1)
  • 1.4.12 Text spacing (v2.1)
  • 1.4.13 Content on hover or focus (v2.1)
  • 2.4.5 Multiple ways
  • 2.4.6 Headings and labels
  • 2.4.7 Focus visible
  • 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)
  • 4.1.3 Status messages (v2.1)

Level AAA

  • 1.2.7 Extended audio description
  • 1.2.8 Media alternatives (pre-recorded)
  • 1.3.5 Identify purpose (v2.1)
  • 1.4.6 Contrast (enhanced)
  • 1.4.8 Visual presentation
  • 1.4.9 Images of text (no exception)
  • 2.1.3 Keyboard (no exception)
  • 2.2.4 Interruptions
  • 2.4.8 Location
  • 2.4.9 Link purpose (link only)
  • 2.4.10 Section headings
  • 2.5.5 Target size (v2.1)
  • 2.5.6 Concurrent input mechanisms (v2.1)
  • 3.2.5 Change on request
  • 3.3.6 Error prevention (all)

Day 96: WCAG and Cognitive Disabilities

Even as I’m learning about design, it still comes down to me focusing more on people, their abilities, and the way they interact with the web. As usual, some learning leads to more questions, and more discoveries.

Things I accomplished

What I reviewed today

  • WCAG success criteria that benefit people with cognitive disabilities;
  • overview of ATAG, Part B (Authoring Tool Accessibility Guidelines):
    1. Fully automatic processes produce accessible content
    2. Authors are supported in producing accessible content
    3. Authors are supported in improving the accessibility of existing content
    4. Authoring tools promote and integrate their accessibility features
  • design considerations for various disability categories
  • accessibility-first mindset:
    • avoid exclusive design patterns
    • embrace diversity
    • create inclusive design

What I learned from it

The following lists target WCAG success criteria that benefit people with cognitive disabilities.

Level A

  • 2.5.1 Pointer gestures (v2.1)
  • 2.5.3 Label in Name (v2.1)
  • 2.5.4 Motion actuation (v2.1)
  • 3.3.1 Error identification
  • 3.3.2 Labels or instructions

Level AA

  • 1.3.4 Orientation (v2.1)
  • 1.3.5 Identify input purposes (v2.1)
  • 1.4.10 Reflow (v2.1)
  • 1.4.12 Text spacing (v2.1)
  • 1.4.13 Content on hover or focus (v2.1)
  • 2.5.6 Concurrent input mechanisms (v2.1)
  • 3.2.3 Consistent navigation
  • 3.2.4 Consistent identification
  • 3.3.3 Error suggestion
  • 3.3.4 Error prevention (legal, financial, data)

Level AAA

  • 1.3.6 Identify purpose (v2.1)
  • 2.2.6 Timeouts (v2.1)
  • 2.3.3 Animation from interactions (v2.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)

Day 89: Writing a Real Accessibility Evaluation

Today I had the joy of practicing what I’ve been learning over the last 88 days. I’ve been itching to work through a formal evaluation, and this real opportunity came up.

Things I accomplished

  • Presented an accessibility issue to an accessibility working group that I chair.
  • Wrote an official evaluation to a separate working group to present aforementioned findings in a formal way.

What I reviewed today

First, I gathered the details that I’d written down. Next, I walked through the WCAG-EM Report Tool to reaffirm my findings, as well as add to them. Lastly, I composed a formal evaluation of the features that were not in conformance with WCAG 2.1, Level AA.

The base outline of my evaluation:

  1. Overview
  2. WCAG-EM evaluation
    1. Scope
    2. Failures
  3. QA testing
    1. Automated testing
    2. Manual testing
    3. Personas
  4. Remediation recommendations

What I learned from it

The process of evaluation can take a quite a bit of time, especially for someone who is new. I had to re-read many WCAG success criteria over again, limit my scope, and deeply think about what techniques were sufficient, advisory, or failures. Additionally, I encountered some bad practice and some not-so-optimal coding solutions, but refrained from delving into those since they are were not part of the aim of conformance. It was a true learning experience, and one I hope to refine over the next few years!

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

Guidelines

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.

Laws

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

Canada

Europe

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

Operable

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.

Understandable

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.

Robust

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.