This surprises me. But forewarned is forearmed.
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.”
- Write Chronologically, Not Spatially
- Write Left to Right, Top to Bottom
- Don’t Use Colors and Icons Alone
- Describe the Action, Not the Behavior
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
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.
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.
Tough, but fair.
A deep dive with good advice on using—and labelling—sectioning content in HTML:
A very useful explanation of the ARIA attributes relating to state:
If you’re using Apple’s VoiceOver, both your phone and your computer will broadcast your assumed disability to the entire internet, unless and until you specifically tell it to stop.
I also discussed this accessibility events feature with my friend who is a screen reader user herself. She said it feels like it’s a first step towards a well-meant digital apartheid.
A terrific explanation of the
aria-live attribute from Ire. If you’re doing anything with Ajax, this is vital knowledge.
Bruce reveals that the theory and the reality are somewhat different when it comes to the accessibility of inline elements like
This is very timely. I’ve been doing some consulting at a company where they are perhaps a little over-reliant on automated accessibility tests.
Automated accessibility tests are a great resource to have, but they can’t automatically make your site accessible. Use them as one step of a larger testing process.
Inclusive design is also future-proofing technology for everyone. Swan noted that many more developers and designers are considering accessibility issues as they age and encounter poor eyesight or other impairments.
A great collection of styled and accessible form elements:
Form controls are necessary in many interfaces, but are often considered annoying, if not downright difficult, to style. Many of the markup patterns presented here can serve as a baseline for building more attractive form controls without having to exclude users who may rely on assistive technology to get things done.
Léonie makes a really good point here: if you’re adding
Really handy accessibility information in a single tweet.
A nice run-down of incremental accessibility improvements made to Gov.uk (I particularly like the technique of updating the
title element to use the word “error” if the page is displaying a form that has issues).
Crucially, if any of the problems turned out to be with the browser or screen reader, they submitted bug reports—that’s the way to do it!
Heydon keeps on delivering the goods. This time, he looks at making on-screen notification messages accessible using ARIA’s live regions.
As ever, structuring content is paramount, even where it pertains to dynamic events inside realtime web applications.