The blind programmers who created screen readers - The Verge
A fascinating account of the history of JAWS and NVDA.
Link tags: screenreaders
55
In Quest of Search
On the surface this is about the pros and cons of minting a new HTML search element to replace div role="search" but there’s a deeper point which is that, while ARIA exists to the plug the gaps in HTML, the long-term goal is to have no gaps.
ARIA is not meant to replace HTML. If anything, the need to use ARIA as ‘polyfill’ for HTML semantics could be considered as a sign and a constant reminder of the fact that HTML falls short on some semantics that benefit users of assistive technologies.
Notes on synthetic speech - Tink - Léonie Watson
This is a fascinating deep dive by Léonie on the inner workings of speech synthesis. She has quite a conundrum: she wants fast playback, but she also wants a voice that doesn’t sound robotic. Unfortunately it’s the robotic-sounding voices that work best at speed.
If you’re interested in this topic, I highly recommend listening to (or reading) the accessibility episode of the Clearleft podcast which featured Léonie as a guest giving demos and explanations.
Skipping skip links ⚒ Nerd
Vasilis offers some research that counters this proposal.
It makes much more sense to start each page with the content people expect on that page. Right? And if you really need navigation (which is terribly overrated if you ask me) you can add it in the footer. Which is the correct place for metadata anyway.
That’s what I’ve done on The Session.
HTML test cases
This is handy—an up-to-date list of tests run on form fields with different combinations of screen readers and browsers.
The Importance of HTML – Jerry Jones
You’re not going to get a Webby Award or thousands of views on Codepen for how amazingly crafted your HTML is. You’ll need to be OK going unrecognized for your work. But know that every time I use a screen reader or keyboard on a site and it works correctly, I have a little spark of joy.
An opinionated guide to accessibility testing /// Iain Bean
- First impressions
- The Tab key
- Automated testing tools
- Screen reader testing
- Next steps
Not so short note on aria-label usage – Big Table Edition – HTML Accessibility
This is a very handy table of elements from Steve of where aria-label can be applied.
Like, for example, not on a div element.
Accessibility Support
A very handy community project that documents support for ARIA and native HTML accessibility features in screen readers and browsers.
How-to: Create accessible forms - The A11Y Project
Another five pieces of sweet, sweet low-hanging fruit:
- Always label your inputs.
- Highlight input element on focus.
- Break long forms into smaller sections.
- Provide error messages.
- Avoid horizontal layout forms unless necessary.
5 most annoying website features I face as a blind person every single day by Holly Tuke
Five pieces of low-hanging fruit:
- Unlabelled links and buttons
- No image descriptions
- Poor use of headings
- Inaccessible web forms
- Auto-playing audio and video
Takin’ five. — Ethan Marcotte
I linked to the first of Ethan’s short videos on accessibility last week, but it’s well worth checking out all five:
Introduction to Screen Readers Using Voiceover | Gymnasium
This is a great short introduction to using VoiceOver with Safari by the one and only Ethan Marcotte.
What’s in a name? | Sarah Higley
This is a terrific explanation of the concept of accessible names in HTML, written with verve and style!
Contrary to what you may think, naming an element involves neither a birth certificate nor the HTML
nameattribute. Thenameattribute is never directly exposed to the user, and is used only when submitting forms. Birth certificates have thus far been ignored by spec authors as a potential method for naming controls, but perhaps when web UI becomes sentient and self-propagating, we’ll need to revisit that.
CSS Can Influence Screenreaders | Ben Myers
This surprises me. But forewarned is forearmed.
HTML: The Inaccessible Parts - daverupert.com
Well, this is a grim collection from Dave:
There are some cases where even using plain ol’ HTML causes accessibility problems. I get frustrated and want to quit web development whenever I read about these types of issues. Because if browsers can’t get this right, what hope is there for the rest of us.
It’s worth clicking through each link he lists—the situation is often much more nuanced than simply “Don’t use X.”
Standards for Writing Accessibly – A List Apart
- Write Chronologically, Not Spatially
- Write Left to Right, Top to Bottom
- Don’t Use Colors and Icons Alone
- Describe the Action, Not the Behavior
What I’ve learned about accessibility in SPAs
Nolan writes up what he learned making accessibiity improvements to a single page app. The two big takeways involve letting the browser do the work for you:
Here’s the best piece of accessibility advice for newbies: if something is a button, make it a
<button>. If something is an input, make it an<input>. Don’t try to reinvent everything from scratch using<div>s and<span>s.
And then there are all the issues that crop up when you take over the task of handling navigations:
- You need to manage focus yourself.
- You need to manage scroll position yourself.
For classic server-rendered pages, most browser engines give you this functionality for free. You don’t have to code anything. But in an SPA, since you’re overriding the normal navigation behavior, you have to handle the focus yourself.
Amphora. — Ethan Marcotte
There’s no sugar-coating it—AMP components are dreadfully inaccessible:
We’ve reached a point where AMP may “solve” the web’s performance issues by supercharging the web’s accessibility problem, excluding even more people from accessing the content they deserve.
Truths about digital accessibility | Eric Bailey
Tough, but fair.