Day 97: WCAG and Visual Impairments

Published on 07 Mar 2019

• journal
• resources
• review
• was
• design
• people
• ux
• wcag

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

• Completed Deque's MS PowerPoint Accessibility course.
• Read through Deque's Design Considerations for Disabilities [PDF] cheatsheet
• Added visual impairments alongside success criteria in my my WCAG cheatsheet.
• Started Deque's Semantic Structures and Navigation course. 35% complete.

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

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.

• 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

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

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