Digital Experiences Accessibility (a11y)

Assess: Web, Mobile, Desktop

Each person involved in digital product creation at some point faces with a question of users equal ability to interact with it.

That’s great when inclusive design and a11y principles lay down in the product basis from the early beginning. But how to approach in cases of skipped a11y and remediate consequences?

This article focuses at:
— Key a11y principles and documents
— Approach to missed a11y
— Assistive technologies at different platforms

Key a11y principles and documents

Principles

W3C Web Accessibility Initiative (WAI) as international standards highlight four accessibility principles. Conformance levels in WCAG 2.0 and WebAIM checklist are distributed accordingly.

— Perceivable information and user interface
— Operable user interface and navigation
— Understandable information and user interface
— Robust content and reliable interpretation

Documents

• WCAG 2.0 compliance
• 508 compliance & Section 508 standards for electronic and information Technology (Non US/EU based users may require VPN connection)
• ADA compliance
• National or state-level guidelines
• Organizations guidelines (for each particular case you need to check official guidelines documentation e.g: IBM, Microsoft, Apple)

Approach to missed a11y

Reach product compliance to a11y standards will be easier with clearly planned and defined steps:

1. Assess: evaluate accessibility needs, determine priorities, make a plan
2. Remediate: implement changes and achieve accessibility compliance
3. Integrate: maintain a11y compliance at on-going project

How to assess

Understand users
Before interface assessment start evaluator should be familiar with user needs and abilities . W3C has a section Stories of web users to describe main user archetypes with diverse abilities and barriers, tools and techniques, accessibility principles. Another great example of user archetypes description can be seen in the book “A web for everyone” by Sarah Horton & Whitney Quesenbery. Authors describe user abilities, aptitude, attitude and usage of assistive technologies.

User Archetypes from “A web for everyone” by Sarah Horton & Whitney Quesenbery

Define what are the a11y documents to be compliant with:
WCAG 2.0 compliance, 508 compliance, ADA compliance, National or state-level guidelines, Organizations guidelines

Understand evaluation principles:
Perceivable, Operable, Understandable, Robust

Define evaluation tools:
Automated tools, User testing, Screen readers check, Keyboard support

How to remediate

Implement changes in existing product to achieve accessibility compliance of defined level. Structured report with outlined next steps helps in issues communication to product owners and implementation team.

How to integrate

Establish trackable a11y process during further product evolution. Ask support from implementation team with a11y regression testing integration into product built process. Tech guys can use aXe core as a library for ongoing automatic a11y validation.

Platform specific assistive technologies

Web

“Web for all” mindset means that product should be created with principles of usability, accessibility and inclusive design. W3C have gathered key Tools & techniques that people with disabilities use to interact with the web.

Testing tools
— Browser plugin Accessibility developer tools
— Automated accessibility testing tools by Laura Johnson
— aXe core automation and integration

Mobile

Nowadays main mobile platforms have very similar assistive technologies.

Android:
— TalkBack (screen reader for blind & low vision users)
— Switch access (key combinations with external keyboard)
— Magnification gestures (zoom by triple-tappe on the screen)
— Grayscale view (monochrome mode)

iOS:
— VoiceOver (screen reader for blind & low vision users)
— Zoom (screen magnifier)
— Invert colors (high-contrast screen mode)
— Grayscale (monochrome screen mode)

Testing tools
— Android Accessibility Scanner
— XCode Accessibility Inspector

Desktop

Desktop applications are usually more complex than web or mobile apps. Still key areas to be maintained remains the same: keyboard navigation, screen reader, color contrast, text alternatives.

Check a11y for desktop application case from Amoli in her awesome article Accessibility testing toolkit for desktop applications

Windows:
— Narrator (light-duty screen reader for blind & low vision users)
— Magnifier (zoom in/out, invert colors)
— High contrast (clearer visually interface)
— Closed captions (deaf and limited hearing)
— Keyboard (click to type on-screen keyboard)
— Mouse (noticeability)

Mac OS:
— VoiceOver (built-in screen reader for blind & low vision users)
— Closed captions (deaf and limited hearing)
— Switch control (physical and motor skills disabilities)
— Text to speech (learning and literacy disabilities)
— Display (color contrast)

Testing tools
— Windows UI Accessibility Checker (AccChecker)
— Mac OS XCode Accessibility Inspector

Sum up

Hope this article help you to find right directions and support while facing a11y challenges at projects.

Check some interesting a11y things by the links:
— How to do an accessibility review by Rob Dodson
— aXe: the accessibility engine
— Accessibility accessories