Decoupled Accessibility

A presentation at DrupalCon Seattle in April 2019 in Seattle, WA, USA by Carie Fisher

Decoupled Accessibility — Decoupled Accessibility
Using patterns and tools to improve inclusivity in your next project

Carie Fisher — Carie Fisher
Sr. Accessibility Instructor & Developer - Deque Systems Twitter/LinkedIn/Medium: @cariefisher GitHub: @cehfisher Slides: https://noti.st/cariefisher

Outline — Outline
Digital accessibility 101 Accessibility: traditional vs. decoupled Resources, tools, & demo time!

Digital accessibility 101

What is digital accessibility? — What is digital accessibility?
Web accessibility means that websites, tools, and technologies are designed and developed so that people with disabilities can use them. Web Accessibility Initiative (WAI)

Who is digital accessibility for? — Who is digital accessibility for?
According to last US census results, about 19% of the United States population identifies as having a disability. That works out to roughly 57 million individual people. Thinking of these numbers in a different way, there are more people with disabilities than populations of New York and California combined. If you consider a global audience, you are talking about 15% of the world’s population according to the World Health Organization (WHO). That is over one billion people worldwide!
Of course 19% is a huge number of people who could benefit from an accessible website or app right from the start, but keep in mind, the official numbers do not even include people that either do not identify as having a disability or those populations that could benefit from accessible websites and apps, such as the aging population — so the number of people needing accessibility in reality is closer to 32% if you just consider those two groups. And of course, that number will continue to grow as people live longer and technology becomes even more prevalent and important to our daily lives.

Fun Fact — Fun Fact
“a11y” is a numeronym that is short for “accessibility” A -> [11 letters] -> Y

What are the different types of disabilities? — What are the different types of disabilities?
➔ Visual Impairments ➔ Mobility Impairments ➔ Hearing Impairments ➔ Cognitive Impairments ➔ Vestibular Disorders ➔ Speech Impairments ➔ Seizure Disorders ➔ Many others

Why should I care about accessibility? — Why should I care about accessibility?
➔ Right thing to do ➔ Smart thing to do ➔ Lawful thing to do ➔ Your future self

We all wear a lot of hats

Who is in charge of accessibility? — Who is in charge of accessibility?
➔ Managers, clients & shareholders ➔ Marketing & sales ➔ Designers & UI/UX specialists ➔ Front-end & back-end developers ➔ Digital strategists, editors & content creators ➔ Users of your website/app

Building accessibility into your workflow

Accessibility: traditional vs. decoupled

Traditional Drupal systems - the good — Traditional Drupal systems - the good
ARIA elements out of the box
Inline form errors and labeling
Image alt text and descriptions
Skip navigation to core themes
Color and contrast checks
Some modules exist that extend performance (D7AX)
Umami demo great example that Drupal can be made accessible

Traditional Drupal systems - the bad — Traditional Drupal systems - the bad
ARIA elements not always the correct ones
CMS systems have hard to predict order of “chunks/blocks”
Existing accessibility features are not always required or turned on by default
Markup/code included in a lot of add-on modules or themes are not accessible
No real governance or standardization on accessibility best practices or testing

Decoupled Drupal systems - the good — Decoupled Drupal systems - the good
Can be “lighter” in code cruft (no Drupalisms to fight or override)
Full control over layout, components, and patterns
A lot of current JavaScript frameworks include accessibility features or add-ons
Lots of frameworks to choose from
Hot newness = more (experienced) eyes on accessibility bugs

Decoupled Drupal systems - the bad — Decoupled Drupal systems - the bad
No Drupal means no built-in accessibility support
You may need to build some components and patterns from scratch
You may have to override certain built-in styles/features that are not accessible
Some current JavaScript frameworks have sparse/bad accessibility
Hot newness = more eyes on other bugs/features, not enough people to help with accessibility ones

Which set-up should I choose?

Demo time!

What rules should I follow?

How do I test for accessibility?

Accessible pattern libraries & guides — Accessible pattern libraries & guides
➔ A11y Project - Web Accessibility Checklist ➔ A11y Style Guide ➔ Deque University Library ➔ GOV.UK ➔ Inclusive Components ➔ U.S. Web Design System

Accessibility helpers — Accessibility helpers
➔ HTML5 Accessibility ➔ WAI - Web Accessibility Tutorials ➔ WCAG Quick Reference Library

Automatic accessibility tools — Automatic accessibility tools
➔ Accessibility Insights ➔ Axe Extension ◆ Desktop ◆ iOS/Android ➔ Pa11y ➔ WorldSpace Attest Extension

Other accessibility tests — Other accessibility tests
➔ Keyboard/Mobile ➔ Assistive Technology Devices (ATs) ◆ Windows: Chrome/Firefox + NVDA and IE/Edge + JAWS ◆ Mac: Safari + VoiceOver ◆ Android: Chrome/Firefox + TalkBack ◆ iOS: Safari + VoiceOver ➔ Content/Readability/User

Questions?

Thanks! — Thanks!
bit.ly/a11yresources Twitter/LinkedIn/Medium: @cariefisher GitHub: @cehfisher Slides: https://noti.st/cariefisher

Carie Fisher
@cariefisher

1 / 27

Using patterns and tools to improve inclusivity in your next project.

Resources

The following resources were mentioned during the presentation or are useful additional information.

A11y Resources