Make Accessibility
Easier to Get Right
(& Harder to Get Wrong)
Slides: https://bit.ly/a11y-ag
Hey 👋
I'm Austin Gil
austingil.com | @heyAustinGil
- Hacking on websites since 2013
- Help folks build better websites
- Interests: bikes, soccer, camping, pinball, roller derby, my chiweenie
Make Accessibility
Easier to Get Right
(& Harder to Get Wrong)
Slides: https://bit.ly/a11y-ag
Hey 👋
I'm Austin Gil
austingil.com | @heyAustinGil
- Hacking on websites since 2013
- Help folks build better websites
- Interests: bikes, soccer, camping, pinball, roller derby, my chiweenie
🚧 DISCLOSURE 🚧
I work at Akamai (akamai.com)
We offer a lot of relevant services
Really hard not to mention (kind of my job)
Impossible to be 100% unbiased
🤝 ASSURANCE 😘
This is not a sales pitch in disguise
I’m here to teach practical, general concepts
I may mention Akamai because it’s familiar
But this info applies anywhere
What is a11y
"Accessibility is the practice of making your websites usable by as many people as possible." - MDN
Impairments can be:
- Visual
- Hearing
- Mobility
And they can also be:
- Cognitive
- Technological
- Temporary
Why you should care
Accessibility has a lot of positive benefits
- More users = more conversions
- Better code = happy robots (SEO)
- Legal compliance = fewer lawsuits
- Ethical (subjective) = I feel better
But a11y is HARD
It’s hard to learn
It’s hard to remember
It’s hard to implement
It’s hard to test
The facts - WebAIM Million Report
Feb 2022 - 50,829,406 distinct errors / 50.8 errors per page webaim.org/projects/million
- Low contrast text: 86.4%
- Missing alternative text for images: 60.6%
- Missing form input labels: 54.4%
- Empty links: 51.3%
- Missing document language: 28.9%
- Empty buttons: 26.9%
IMPORTANT: Based on automated WCAG metrics
Challenge
How do we get more participation?
Some approaches
- Educating & advocating
- Pleading & guilt tripping
- Warning & threatening
I don’t like this
- Requires indivudual buy-in
- Doesn’t acknowledge hurdles
- Asks people to change process
- Not very scalable
What I’m proposing today
Meet people where they are!
Build a11y guardrails into the existing environments
- Design
- Development
- Testing
- CI/CD
- QA
Designers
Natural Habitat:
- Figma
- Sketch
- AdobeXD
Challenge
If a background color is #bada55 , what color should the foreground text be…?
(Hint: WCAG AA requires color contrast ratio of 4.5:1)
🤷 Pfft!!!
Plugins
Stark (getstark.co)
Make It Easy
Accessible alternatives
Developers
Natural Habitat:
- Text editor
- Terminal/CLI
- Browser
Editor Extensions
VS Code:
- axe Accessibility Linter by Deque
- webhint
Pros: Very easy to get started
Cons: Hard to coordinate across teams (IDE, extension, settings)
Component Frameworks & Libraries
Components:
- Required props (input label)
- Optional/Default props (input ID)
- TypeScript/JSDocs (red squigglies)
Libraries:
- Vue: Vuetensils
- React: Reach UI
- Web components: Lion
Libraries
Make it easy to do right
Components
Make it hard to do wrong
Why not CSS (???)
img:not([alt]){
outline: 5px dashed red;
outline-offset: 5px;
}A11y.css (ffoodd.github.io/a11y.css)
(Remove from production at build!)
CLI Linters
ESLint (eslint.org)
CLI analysis = 😍
- Enforce coding standards
- Highlight issues
- Fix some problems
- Intergrates with IDE
- Red squigglies
- Fix on save
+ a11y checks = 😍😍😍
- Vue: eslint-plugin-vuejs-accessibility
- React/JSX: eslint-plugin-jsx-a11y
- Lit HTML: eslint-plugin-lit-a11y
Pros: Runs in terminal (cross platform)
Cons: Must run it manually
Git hooks
Run arbitrary commands during Git processes
Integrate CLI tools to automatically check (& fix) code during git process
pre-commitpre-push
(github.com/evilmartians/lefthook)
Pros: Prevents bad code being pushed
Cons: --no-verify
IDE Plugins
Make it easy to do right
CLI Linters
Make it hard to do wrong
Reviewers,
Testers,
& QA
Natural Habitat:
- Pull requests
- CI/CD logs
- Staging site
Pull Requests
Integrate automated a11y review to PRs
Accesslint (accesslint.com)
- Checks a11y during code reviews
- Faster review feedback loop
- Reduces unnecessary back & forth
- Can prevent merge/deploys
Browser Extensions
Analyze real pages directly from dev tools
axe DevTools by Deque (deque.com/axe/devtools)
Browser Bookmarklets
Run arbitrary JavaScript on any webpage.
Similar to extensions, but not in dev tools.
- HTML_CodeSniffer (squizlabs.github.io/HTML_CodeSniffer)
- Sa11y (ryersondmp.github.io/sa11y)
- Tota11y (khan.github.io/tota11y)
Automated tests & CI/CD
Run a11y analysis from your deployment pipeline, automatically.
Playwright (playwright.dev) & Cypress (cypress.io) are amazing
- Run tests in real browsers (not synthetic)
- Deque axe plugins:
@axe-core/playwright&cypress-axe - Test entire pages or just components
- Integrate into CI/CD
- Prevent pushing a11y issues to prod
Caveats
- We’re only catching things robots can test.
- Accessibility isn’t about numbers, it’s about experience.
- Tooling and automation doesn’t replace real user testing.
- Analytics can tell you details about YOUR users.
- 100% WCAG score doesn’t always mean accessible.
(see “Building the most inaccessible site possible with a perfect Lighthouse score” by Manuel Matuzovic)
Final thoughts
Make it easy to do right and hard to do wrong.
Not everyone needs to care about a11y (🌶).
Robots multiply your impact (🤖 = 👨💻x100).
But robots don’t replace humans.
They unlock time/brainpower to focus on bigger things.
100% lighthouse scores is the start line, not the finish line.
That’s it, but before I go…
Shoutout to all the folks that made this happen
Organizers
Sponsors
Venue staff
YOU!!!