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.
It’s great to see the changes that Facebook’s four-person accessibility team have managed to push through.
This is a great response to my recent post about semantics in HTML. Steve explores the accessibility implications. I heartily concur with his rallying cry at the end:
Derek runs some tests on how screenreaders behave when block-level elements are wrapped in links, which is now legal in HTML5.
Test results for screen readers navigating content that uses new HTML5 elements and ARIA roles.
The results of the second screen reader survey from WebAIM are, once again, required reading.
This list of screenreader survey results is required reading. Conclusion: "there is no typical screen reader user."
A guide to using ARIA roles from the mighty Steve Faulkner.