Wednesday, December 19th, 2018
Saturday, December 15th, 2018
A terrific explanation of the
aria-live attribute from Ire. If you’re doing anything with Ajax, this is vital knowledge.
Friday, November 2nd, 2018
Bruce reveals that the theory and the reality are somewhat different when it comes to the accessibility of inline elements like
Thursday, September 13th, 2018
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.
Tuesday, August 7th, 2018
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.
Tuesday, July 31st, 2018
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.
Friday, July 20th, 2018
Léonie makes a really good point here: if you’re adding
Monday, March 26th, 2018
Really handy accessibility information in a single tweet.
Wednesday, March 7th, 2018
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!
Friday, March 2nd, 2018
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.
Sunday, January 28th, 2018
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.
Thursday, December 7th, 2017
Great advice on keeping your hyperlinks accessible.
Thursday, October 19th, 2017
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.
Tuesday, August 29th, 2017
Tuukka Ojala is a programmer working on the web. He’s also blind. Here are the tools of his trade.
Monday, November 14th, 2016
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
Sunday, November 6th, 2016
Ire rounds up a bunch of tools you can use to test accessibility, from dev tools to Tenon.
Wednesday, August 31st, 2016
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.
Thursday, May 5th, 2016
Hidden little details that make a big difference for screen readers.
A website is only as beautiful as the underlying markup.
Friday, January 15th, 2016
It’s tempting to think of testing with screen-readers as being like testing with browsers. With browser testing, you’re checking to see how a particular piece of software deals with the code you’re throwing at it. A screen reader is a piece of software too, so it makes sense to approach it the same way, right?
I don’t think so. I think it’s really important that if someone is going to test your site with a screen reader, it should be someone who uses a screen reader every day.
Think of it this way: you wouldn’t want a designer or developer to do usability testing by testing the design or code on themselves. That wouldn’t give you any useful data. They’re already familiar with what problems the design is supposed to be solving, and how the interface works. That’s why you need to do usability testing with someone from outside, someone who wasn’t involved in the design or development process.
It’s no different when it comes to users of assistive technology. You’re not trying to test their technology; you’re trying to test how well the thing you’re building works for the person using the technology.
Don’t think of screen-reader testing as a form of browser testing; think of it as a form of usability testing.
Saturday, November 7th, 2015
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…”