Wednesday, March 13th, 2019
A handy accessibility tool. The browser plug-in is only for Chrome right now (I use Firefox as my main browser) but it’s pretty nifty—the tool for visualising tabbing is really useful.
Eric is down about the current dismal state of accessibility on the web. Understandably so. It’s particularly worrying that the problem might be embedded into hiring practices:
But it’s not all doom and gloom. Eric also points to initiatives that could really help.
Still, this is a tough question to ask out loud:
What if we’re losing?
Monday, February 25th, 2019
Accessibility on The Session
These forms have been enhanced with some Ajax to add some motion design: instead of refreshing the whole page, the next form is grabbed from the server while the previous one swooshes off the screen.
You can see similar functionality—without the animation—wherever there’s pagination on the site.
The pagination is using Ajax to enhance regular prev/next links—here’s the code.
The multi-step forms are using Ajax to enhance regular form submissions—here’s the code for that.
Both of those are using a wrapper I wrote for XMLHttpRequest.
That wrapper also adds some ARIA attributes. The region of the page that will be updated gets an
aria-live value of
polite. Then, whenever new content is being injected, the same region gets an
aria-busy value of
true. Once the update is done, the
aria-busy value gets changed back to
That all seems to work fine, but I was also giving the same region of the page an
aria-atomic value of
true. My thinking was that, because the whole region was going to be updated with new content from the server, it was safe to treat it as one self-contained unit. But it looks like this is what was causing the problem, especially when I was also adding and removing
class values on the region in order to trigger animations. VoiceOver seemed to be getting a bit confused and overly verbose.
I’ve removed the
aria-atomic attribute now. True to its name, I’m guessing it’s better suited to small areas of a document rather than big chunks. (If anyone has a good primer on when to use and when to avoid
aria-atomic, I’m all ears).
I was glad I was able to find a fix—hopefully one that doesn’t negatively impact the experience in other screen readers. As is so often the case, the issue was with me trying to be too clever with ARIA, and the solution was to ease up on adding so many ARIA attributes.
For me, all of this really highlights the beauty of the web, when everyone is able to contribute to a community like The Session, regardless of what kind of software they may be using. In the tunes section, that’s really helped by the use of ABC notation, as I wrote five years ago:
One of those screen-reader users got in touch with me shortly after joining to ask me to explain what ABC was all about. I pointed them at some explanatory links. Once the format “clicked” with them, they got quite enthused. They pointed out that if the sheet music were only available as an image, it would mean very little to them. But by providing the ABC notation alongside the sheet music, they could read the music note-for-note.
That’s when it struck me that ABC notation is effectively alt text for sheet music!
Then, for those of use who can read sheet music, the text of the ABC notation is automatically turned into an SVG image using the brilliant abcjs. It’s like an enhancement that’s applied, I dunno, what’s the word …progressively.
Monday, February 11th, 2019
A nice counterpoint to the last time I linked to Paul’s weeknotes:
However, there’s another portion of the industry, primarily but not exclusively within the public sector, where traditional development approaches (progressive enhancement, server-side rendering) remain prevalent, or less likely to be dismissed, at least. Because accessibility isn’t optional when your audience is everyone, these organisations tend to attract those with a pragmatic outlook who like to work more diligently and deliberately.
Tuesday, February 5th, 2019
Ire takes a deep dive into implementing an accessible tool tip.
Friday, February 1st, 2019
A good reminder from Chris—prompted by Scott O’Hara’s article—that the
figcaption element and the
alt attribute do different things. If you use an empty
alt attribute on an
img inside a
figure, then your
figcaption element is captioning nothing …and no, using the same text for both is not the solution.
Sunday, January 27th, 2019
Vasilis has published his magnificent thesis online. It’s quite lovely:
You can read this thesis in a logical order, which is the way that I wrote it. It starts with a few articles that explore the context of my research. It then continues with four chapters in which I describe the things I did. I end the thesis with four posts with findings, conclusions and recommendations.
Friday, January 11th, 2019
How did I miss this great post from 2016 by one of my favourite people‽ It’s even more more relevant today.
Wednesday, January 9th, 2019
When you stop to consider all the implications of poor performance, it’s hard not to come to the conclusion that poor performance is an ethical issue.
Tuesday, January 1st, 2019
These are good challenges to think about. Almost all of them are user-focused, and there’s a refreshing focus away from reaching for a library:
It’s tempting to read about these problems with a particular view library or a data fetching library in mind as a solution. But I encourage you to pretend that these libraries don’t exist, and read again from that perspective. How would you approach solving these issues?
Saturday, December 29th, 2018
The secret is: if you use semantic HTML, then they do the work, not you. Their browser does the work, not you. If your pages use semantic HTML, you’re not going to get bug reports saying that your web app doesn’t work in a screenreader, or your buttons don’t work without mouse clicks, or your site doesn’t show anything on a Yoyodyne SuperPhone 3 running FailBrowser, because it will and they will and it will. And using semantic HTML elements is no more effort; it’s just as easy to use
mainas it is to use
div id="main". Easier, even.
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.
Thursday, December 6th, 2018
I’ve come to believe that accessibility is not something you do for a small group of people. Accessibility is about promoting inclusion. When the product you use daily is accessible, it means that we all get to work with a greater number and a greater variety of colleagues. Accessibility benefits everyone.
Monday, November 26th, 2018
Prototypes and production
When we do front-end development at Clearleft, we’re usually delivering production code, often in the form of a component library. That means our priorities are performance, accessibility, robustness, and other markers of quality when it comes to web development.
We do a lot of design sprints, where time is of the essence. The prototype we produce on the penultimate day of the sprint definitely won’t be production quality, but it will be good enough to test.
What’s interesting is that—when it comes to prototyping—our usual front-end priorities can and should go out the window. The priority now is speed. If that means sacrificing semantics or performance, then so be it. If I’m building a prototype and I find myself thinking “now, what’s the right
class name for this component?”, then I know I’m in the wrong mindset. That question might be valid for production code, but it’s a waste of time for prototypes.
So these two kinds of work require very different attitudes. For production work, quality is key. For prototyping, making something quickly is what matters.
Alternating between production projects and prototyping projects can be quite fun, if a little disorienting. It’s almost like I have to flip a switch in my brain to change tracks.
When a prototype is successful, works great, and tests well, there’s a real temptation to use the prototype code as the basis for the final product. Don’t do this! I’ve made that mistake in the past and it always ends badly. I ended up spending far more time trying to wrangle prototype code to a production level than if I had just started from a clean slate.
Build prototypes to test ideas, designs, interactions, and interfaces …and then throw the code away. The value of a prototype is in answering questions and testing hypotheses. Don’t fall for the sunk cost fallacy when it’s time to switch over into production mode.
Of course it should go without saying that you should never, ever release prototype code into production.
Heydon recently highlighted an article that offered this tip for aspiring web developers:
As for HTML, there’s not much to learn right away and you can kind of learn as you go, but before making your first templates, know the difference between in-line elements like
spanand how they differ from block ones like
That’s perfectly reasonable advice …if you’re building a prototype. But if you’re building something for public consumption, you have a duty of care to the end users.
Monday, November 12th, 2018
Thursday, November 8th, 2018
Ethan ponders what the web might be like if the kind of legal sticks that exist for accessibility in some countries also existed for performance.