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.
I started writing for myself. The writing was helpful for me and luckily it was helpful for other people as well. But even if you’re the only one that reads your blog it is still helpful as a way to learn.
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.
A step-by-step guide to implementing drag’n’drop, and image previews with the Filereader API. No libraries or frameworks were harmed in the making of this article.
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.
Heydon asked screen readers some questions about their everyday interactions with websites. The answers quite revealing: if you’re using headings and forms correctly, you’re already making life a lot easier for them.
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.