Accessible Graphics on the Web

What does accessibility mean?

• The user can understand the information presented
• The user can control any interactive functions
• Regardless of sensory limitations, mobility limitations, cognitive limitations

How does accessibility work on the web?

• For accessibility tools such as screen readers, content must be machine-readable
  1. Web pages contain markup describing the meaning & function of content
  2. The browser processes it & interacts with OS accessibility API
  3. Accessibility tools interface with the accessibility API
• But, many people with limitations do not use these tools, so the web page must stand on its own
  • Color blindness
  • Low vision (just use browser zoom, etc.)
  • Hearing problems
  • Cognitive/neurological differences
• For user input, most specialized devices act like keyboard or mouse
  • But often slower
  • But often less precise
  • Touchpads & onscreen keyboards make these universal issues

Two sides to the story…

• Are your software tools accessible?
  • Can anyone who want to create a graphic use your tool?
  • Can they understand it?
  • Can they make it do what they want?
• Do your tools create accessible graphics?
  • Can you automatically make things more accessible?
  • Can you prompt the user to add more accessibility support?

Can you be more specific?

• Use the Web Content Accessibility Guidelines (WCAG 2.0)
  • http://www.w3.org/TR/WCAG20/
  • Designed for the web, but applicable to all software
• Guidelines == broad goals
• Conformance standards == specific requirements
  • Level A: Avoid the worst problems
  • Level AA: Avoid more tricky issues
  • Level AAA: Make things easy to use
• Guidelines & standards are technology-agnostic
  • Specific techniques are available for HTML, PDF, other web documents
• For designing software that creates accessible content
  • WCAG authoring tool guidelines (somewhat out of date)
  • http://www.w3.org/TR/ATAG10/
  • Primarly HTML-focused, but might give you some ideas

WCAG 2: Four Categories

1. Perceivable
2. Operable
3. Understandable
4. Robust

Perceivable

Users can receive information, regardless of sensory limitations

1. Text alternatives for image, video, and audio (and text stored within images!)
2. Captions or other formats for audio, video, and animation (time-based media)
3. Provide logical structure independent of visual layout
4. Effectively contrast foreground vs background graphics and audio

Operable

Users can interact with content, regardless of input device

1. All functions keyboard operable
2. Avoid time-based limitations
3. Do not create epilipsy seizure triggers (flashing/blinking content)
4. Provide effective navigation tools

Understandable

The content & function is easy to understand, regardless of how a user perceives & interacts with it

1. Clearly identify the language of text, and offer interpretation hints
2. Avoid sudden/unexpected changes in the content as the user navigates or fills in input
3. Make the purpose of user input clear, and help users avoid and correct mistakes

Robust

Content works in many software/input environments, even after accessibility alterations

1. Maximize compatibility, ensure optimum fallback, make important information machine-accessible

Can graphics be accessible?

• What are you trying to communicate?
• Brand?
• Data?
• Structure?
• Mood?

SVG for Accessible Graphics

• Vector graphics == good resolution when magnified
• XML == structured content
• Visible text stored as text
• Alternative text within the main document
• Alternative text associated with sub-components of graphic

Current Limitations of SVG Accessibility

• XML text not always accessible through modern (SVG-supporting) web browsers
• Font & text problems == text as path
• Interactive components difficult to make keyboard accessible
• The meaning of text formatting and grouping structure is not accessible
• No easy way to navigate complex graphical structures (e.g., data charts)

Improving Accessible SVG

• Use ARIA (Accessible Rich Internet Applications) attributes
• Support keyboard navigation
• Allow multi-lingual alternative text
• Allow greater user style customization

Using ARIA

• role attributes defines what content is
  • heading
  • list item
  • clickable button
• property attributes define additional information for navigation
  • label
  • heading level
• state attributes define current status of interactive components
  • a checkbox is checked
  • a collapsible section is expanded & visible
• Limitation: ARIA was defined for standard web page layouts and widgets, not a lot of support for graphics yet
• The SVG Accessibility Task Force is trying to come up with more roles for charts & graphics

Better keyboard navigation

• SVG 2 will have basic tabIndex support similar to HTML
• More complex navigation being considered
  • 2D scanning
  • Tree traversal

Multi-lingual alternative text

• Currently, only one text alternative is possible per element
• SVG 2 will allow multiple <title> and <desc> elements distinguished by language code
• Backwards compatible: existing browsers will use first element

User style overrides

• Easy to implement, difficult to implement effectively
• Many possible alterations could improve accessibility:
  • larger fonts
  • thicker lines
  • higher contrast
  • color replaced with texture
• But, how to implement so that meaning of graphic is not lost?
• ARIA might help distinguish information from decoration

Making Other Graphics Accessible

• In the web browser
  • For HTML+CSS, use semantic markup where possible, ARIA where required
  • For HTML 5 Canvas graphics, use a structured HTML+ARIA shadow DOM tree
  • Wherever possible, provide content in multiple formats (e.g., data table + data chart)
• In other software
  • Need to directly communicate with OS accessibility API
  • For XML-based formats, consider using ARIA
• New ARIA roles and other attributes will help with all XML/HTML markup graphics