As I reread the last @webaim screenreader survey, I'm struck by:
1. 94.6% respondents reported at least intermediate screenreader proficiency (most said advanced)
2. 98.8% reported at least intermediate internet proficiency (also mostly advanced)
#a11y webaim.org/projects/scree…
1. 94.6% respondents reported at least intermediate screenreader proficiency (most said advanced)
2. 98.8% reported at least intermediate internet proficiency (also mostly advanced)
#a11y webaim.org/projects/scree…
Disabled people become power users of our assistive technology out of necessity.
Even if you do #a11y testing, if you don't test like a power user of assistive tech, you're still not reflecting many users' experiences.
Even if you do #a11y testing, if you don't test like a power user of assistive tech, you're still not reflecting many users' experiences.
As devs, when we scratch the surface of a screenreader without learning it more fully, we can do a lot of harm.
I've seen people put tabindexes on static text to make it focusable because "you couldn't tab to it with a screenreader!"
(Only interactive things should be tabbable)
I've seen people put tabindexes on static text to make it focusable because "you couldn't tab to it with a screenreader!"
(Only interactive things should be tabbable)
Or adding hidden phonetic spellings so the screenreader pronounces a word correctly… and forcing refreshable braille display users to read those phonetic spellings.
(Screenreader users are well-acquainted with mispronunciation, and can read character-by-character if they need)
(Screenreader users are well-acquainted with mispronunciation, and can read character-by-character if they need)
Or cluttering the page with control hints telling users how to use the page, like @aardrian describes below.
These hints often act like users have never experienced a webpage, and often rely on faulty assumptions about how they'll actually use your page.
adrianroselli.com/2019/10/stop-g…
These hints often act like users have never experienced a webpage, and often rely on faulty assumptions about how they'll actually use your page.
adrianroselli.com/2019/10/stop-g…
These efforts are well-meaning, but they all make your user experience worse.
It's death by overcorrection, stemming from a lack of understanding of how disabled people actually navigate the web… and a disbelief that disabled people could even use the web.
It's death by overcorrection, stemming from a lack of understanding of how disabled people actually navigate the web… and a disbelief that disabled people could even use the web.
So, how do we keep from overcorrecting in #a11y and making UX worse?
1. Deeply familiarize yourself with assistive tech such as screenreaders. Learn how beginners and power users alike use these tools.
1. Deeply familiarize yourself with assistive tech such as screenreaders. Learn how beginners and power users alike use these tools.
2. Lean on strong foundations everywhere.
When you use semantic markup, disabled users get familiar, expected, predictable experiences out of the box.
They've used the web before — they know how form elements and landmarks work… and how they work for THEM. No hints needed!
When you use semantic markup, disabled users get familiar, expected, predictable experiences out of the box.
They've used the web before — they know how form elements and landmarks work… and how they work for THEM. No hints needed!
3. Take the time to understand why.
When you receive an #a11y finding or read a WCAG criterion… take the time to understand the UX that it's actually addressing. Who needs this, and why?
(You'd be amazed the wealth of articles out there for each WCAG requirement)
When you receive an #a11y finding or read a WCAG criterion… take the time to understand the UX that it's actually addressing. Who needs this, and why?
(You'd be amazed the wealth of articles out there for each WCAG requirement)
• • •
Missing some Tweet in this thread? You can try to
force a refresh
