Tags: aria



Thursday, June 25th, 2020

Accessible to some - Manuel Matuzović

A score of 100 in Lighthouse or 0 errors in axe doesn’t mean that you’re done, it means that you’re ready to start manual testing and testing with real users, if possible.

Wednesday, June 10th, 2020

Optimizing keyboard navigation using tabindex and ARIA — Sara Soueidan

Smart thinking from Sara to improve usability for keyboard users by using aria-hidden="true" tabindex="-1" to skip duplicate links:

A good rule of thumb for similar cases is that if you have multiple consecutive links to the same page, there is probably a chance to improve keyboard navigation by skipping some of those links to reduce the number of tab stops to one. The less tab stops, the better, as long as it does not worsen or compromise on other aspects of usability.

I’ve cautiously implemented this pattern now over on The Session where snippets of comments had both a title link and a “more” link going to the same destination.

Tuesday, May 5th, 2020

Times New Arial

Ever wanted to set some text in 70% Times New Roman and 30% Arial? Me neither. But now, thanks to variable fonts, you can!

Saturday, April 25th, 2020

Dark mode and variable fonts | CSS-Tricks

This is such a clever use of variable fonts!

We can use a lighter font weight to make the text easier to read whenever dark mode is active.

Friday, April 17th, 2020

What’s in a name? | Sarah Higley

This is a terrific explanation of the concept of accessible names in HTML, written with verve and style!

Contrary to what you may think, naming an element involves neither a birth certificate nor the HTML name attribute. The name attribute is never directly exposed to the user, and is used only when submitting forms. Birth certificates have thus far been ignored by spec authors as a potential method for naming controls, but perhaps when web UI becomes sentient and self-propagating, we’ll need to revisit that.

Monday, March 23rd, 2020

Inclusive Inputs « Texte | ovl – code & design

This is a great walkthough of making a common form pattern accessible. No complex code here: some HTML is all that’s needed.

Friday, March 13th, 2020

Rise of the Digital Fonts

A history of typesetting from movable type to variable fonts.

Friday, March 6th, 2020

A Variable Fonts Primer

Everything you ever wanted to know about variable fonts, gathered together into one excellent website.

Tuesday, March 3rd, 2020

HTML: The Inaccessible Parts - daverupert.com

Well, this is a grim collection from Dave:

There are some cases where even using plain ol’ HTML causes accessibility problems. I get frustrated and want to quit web development whenever I read about these types of issues. Because if browsers can’t get this right, what hope is there for the rest of us.

It’s worth clicking through each link he lists—the situation is often much more nuanced than simply “Don’t use X.”

Friday, February 14th, 2020

ARIA labels | Amber’s Website

A great explanation of aria-label and aria-labelledby!

Variable fonts’ past, present and future, according to Dalton Maag

In this interview, Biance Berning says:

Cassie Evans from Clearleft is an interesting person to follow as she combines web animation with variable font technology, essentially exploring the technology’s practicality and expression.

Hells yeah!

We’re only just scratching the surface of what variable fonts can do within more interactive and immersive spaces. I think we’ll see a lot more progress and experimentation with that as time goes on.

Wednesday, November 27th, 2019

Accessibility on The Session revisited

Earlier this year, I wrote about an accessibility issue I was having on The Session. Specifically, it was an issue with Ajax and pagination. But I managed to sort it out, and the lesson was very clear:

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.

Well, fast forward to the past few weeks, when I was contacted by one of the screen-reader users on The Session. There was, once again, a problem with the Ajax pagination, specifically with VoiceOver on iOS. The first page of results were read out just fine, but subsequent pages were not only never announced, the content was completely unavailable. The first page of results would’ve been included in the initial HTML, but the subsequent pages of results are injected with JavaScript (if JavaScript is available—otherwise it’s regular full-page refreshes all the way).

This pagination pattern shows up all over the site: lists of what’s new, search results, and more. I turned on VoiceOver and I was able to reproduce the problem straight away.

I started pulling apart my JavaScript looking for the problem. Was it something to do with how I was handling focus? I just couldn’t figure it out. And other parts of the site that used Ajax didn’t seem to be having the same problem. I was mystified.

Finally, I tracked down the problem, and it wasn’t in the JavaScript at all.

Wherever the pagination pattern appears, there are “previous” and “next” links, marked up with the appropriate rel="prev" and rel="next" attributes. Well, apparently past me thought it would be clever to add some ARIA attributes in there too. My thinking must’ve been something like this:

  • Those links control the area of the page with the search results.
  • That area of the page has an ID of “results”.
  • I should add aria-controls="results" to those links.

That was the problem …which is kind of weird, because VoiceOver isn’t supposed to have any support for aria-controls. Anyway, once I removed that attribute from the links, everything worked just fine.

Just as the solution last time was to remove the aria-atomic attribute on the updated area, the solution this time was to remove the aria-controls attribute on the links that trigger the update. Maybe this time I’ll learn my lesson: don’t mess with ARIA attributes you don’t understand.

Thursday, November 7th, 2019

What I’ve learned about accessibility in SPAs

Nolan writes up what he learned making accessibiity improvements to a single page app. The two big takeways involve letting the browser do the work for you:

Here’s the best piece of accessibility advice for newbies: if something is a button, make it a <button>. If something is an input, make it an <input>. Don’t try to reinvent everything from scratch using <div>s and <span>s.

And then there are all the issues that crop up when you take over the task of handling navigations:

  • You need to manage focus yourself.
  • You need to manage scroll position yourself.

For classic server-rendered pages, most browser engines give you this functionality for free. You don’t have to code anything. But in an SPA, since you’re overriding the normal navigation behavior, you have to handle the focus yourself.

Friday, September 6th, 2019

Recursive | Recursive

Play around with this variable font available soon from Google Fonts in monospaced and sans-serif versions.

Saturday, August 31st, 2019

Friday, August 9th, 2019

Meaning without markup: Accessibility Object Model

Hidde gives an in-depth explanation of the Accessibility Object Model, coming soon to browsers near you:

In a way, that’s a bit like what Service Workers do for the network and Houdini for style: give developers control over something that was previously done only by the browser.

Tuesday, July 30th, 2019

Thursday, July 25th, 2019


I like good design principles. I collect design principles—of varying quality—at principles.adactio.com. Ben Brignell also has a (much larger) collection at principles.design.

You can spot the less useful design principles after a while. They tend to be wishy-washy; more like empty aspirational exhortations than genuinely useful guidelines for alignment. I’ve written about what makes for good design principles before. Matthew Ström also asked—and answered—What makes a good design principle?

  • Good design principles are memorable.
  • Good design principles help you say no.
  • Good design principles aren’t truisms.
  • Good design principles are applicable.

I like those. They’re like design principles for design principles.

One set of design principles that I’ve included in my collection is from gov.uk: government design principles . I think they’re very well thought-through (although I’m always suspicious when I see a nice even number like 10 for the amount of items in the list). There’s a great line in design principle number two—Do less:

Government should only do what only government can do.

This wasn’t a theoretical issue. The multiple departmental websites that preceded gov.uk were notorious for having too much irrelevant content—content that was readily available elsewhere. It was downright wasteful to duplicate that content on a government site. It wasn’t appropriate.

Appropriateness is something I keep coming back to when it comes to evaluating web technologies. I don’t think there are good tools and bad tools; just tools that are appropriate or inapropriate for the task at hand. Whether it’s task runners or JavaScript frameworks, appropriateness feels like it should be the deciding factor.

I think that the design principle from GDS could be abstracted into a general technology principle:

Any particular technology should only do what only that particular technology can do.

Take JavaScript, for example. It feels “wrong” when a powerful client-side JavaScript framework is applied to something that could be accomplished using HTML. Making a blog that’s a single page app is over-engineering. It violates this principle:

JavaScript should only do what only JavaScript can do.

Need to manage state or immediately update the interface in response to user action? Only JavaScript can do that. But if you need to present the user with some static content, JavaScript can do that …but it’s not the only technology that can do that. HTML would be more appropriate.

I realise that this is basically a reformulation of one of my favourite design principles, the rule of least power:

Choose the least powerful language suitable for a given purpose.

Or, as Derek put it:

In the web front-end stack — HTML, CSS, JS, and ARIA — if you can solve a problem with a simpler solution lower in the stack, you should. It’s less fragile, more foolproof, and just works.

ARIA should only do what only ARIA can do.

JavaScript should only do what only JavaScript can do.

CSS should only do what only CSS can do.

HTML should only do what only HTML can do.

Monday, July 1st, 2019

Variable Fonts for Developers

A showcase of fun experiments with variable fonts, courtesy of Mandy.

Sunday, June 9th, 2019

German Naming Convention

Don’t write fopen when you can write openFile. Write throwValidationError and not throwVE. Call that name function and not fct. That’s German naming convention. Do this and your readers will appreciate it.