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.
A nice analogy to help explain what it’s like to navigate with a screen reader—and how much well-structured markup can help make it easier.
Great advice on keeping your hyperlinks accessible.
Great advice for writing usable
alt attributes. This gem seems obvious in hindsight but I hadn’t considered it before:
End the alt-text with a period. This will make screen readers pause a bit after the last word in the alt-text, which creates a more pleasant reading experience for the user.
Tuukka Ojala is a programmer working on the web. He’s also blind. Here are the tools of his trade.
The Government Digital Service have published the results of their assistive technology survey, which makes a nice companion piece to Heydon’s survey. It’s worth noting that the most common assistive technology isn’t screen readers; it’s screen magnifiers. See also this Guardian article on the prevalence of partial blindness:
Of all those registered blind or partially sighted, 93% retain some useful vision – often enough to read a book or watch a film. But this can lead to misunderstanding and confusion
Ire rounds up a bunch of tools you can use to test accessibility, from dev tools to Tenon.
I wrote a while back about how I switched from using a button to using a link for progressive disclosure patterns. That looks like it was a good move—if I use a button, I’d need to use
aria-controls and, as Heydon outlines here, the screen reader support is pants.
Hidden little details that make a big difference for screen readers.
A website is only as beautiful as the underlying markup.
This is such an incredibly useful resource by Steve and Léonie: documenting how multiple screen readers handle each and every element in HTML.
It’s a work in progress, but it’s definitely one to remember the next time you’re thinking “I wonder how screen readers treat this markup…”
Léonie gives a great, clear description of how screen readers switch modes as they traverse the DOM snapshot.