WordCamp 2019 - Performance and Accessibility

@ericwbailey

accessibility tree

• name - short identifier to designate purpose
• role - how to interact
• properties
• description eg:

OS > Browser > HTML/JS/CSS

• Browsers use different accessibility trees
• DOM is part of Accessibility tree, but not only part
• AT is brittle
• AT trying to render DOM can be slowed or crashed

#TODO add real accessibility to SLDS/components

use semantic HTML
Fieldset/legend could be good
Accessibility Inspector in Firefox (Chrome?)
Pacelli Group's AViewer and Apple's Accessibility viewer

The crash of reader was linked to radio choice elements

• 10k lines for Material radio buttons Max depth of 32 nodes recommended by Lighthouse

http://wave.webaim.org/report#/application.jstart.org
http://wave.webaim.org/extension/

A11y form control project -- good test work
A11y v SLDS??

Screen Readers

• JAWS - closed source, open tracker
• NVDA - open source, open tracker
• VoiceOver - closed source, closed tracker
• Talkback - open source, open tracker

Accessibility audits tend to happen after lawsuits
https://i.imgur.com/5cdTYEq.jpg

NASA Task Load Index - https://humansystems.arc.nasa.gov/groups/tlx/downloads/TLXScale.pdf do this
Cognitive load - a million radio buttons can actually be a performance problem for the user regardless of page render
use pre-questions to narrow down following options

• 2018 Design In Tech report is good
  • 12/32/46% testing for early/mid/late stage startups, and trails off from there ## Test everything

aria-label is the big one: https://dequeuniversity.com/rules/axe/3.3/label