I’ve done a decent amount of accessibility work in the past few months, largely thanks to a nice fellow who uses JAWS and seems to enjoy our sessions together testing various bits of CodePen, old and new. I use classic tools like the axe and the WebAIM tools to find issues, and still, testing over a video call has found some really embarrassing stuff on CodePen that felt good to clean up. We had a page with four <h1> tags on it, for cripes sake, and I’m not going to tell you which page it was (it was the homepage).
There are lots of accessibility failures that are hard or impossible to detect without actual usage and sometimes with unique people. And sometimes they are just blunders that come from too narrow of a world view. Bruce Lawson pointed out an example with a “First Name” and “Last Name” form where the “First Name” required 2 characters and the “Last Name” was required, both assumptions that just aren’t culturally true. Jimmy Eaglechest works fine but, as Bruce pointed out, U Nagaharu the Korean-Japanese botanist couldn’t use the site (booo).
It’s nice when the big companies that lots of us use take accessibility seriously.
It’s nice to see that GitHub now has (at least optionally) underlined links, which are highly recommended for accessibility. They faced harder challenges, like their very complex search form inputs with a whole variety of accessibility considerations.
It’s also nice to see the design systems of heavily-visited news sites like the Washington Post incorporate an accessibility checklist.
And the winner of the best blog post title I’ve seen recently is Ian Lloyd’s When I Get That Low Contrast Feeling, I Need Non-Textual Healing. The post is a great reminder that testing for color contrast is tricker than it seems. I thought he was going to get into how the actual math to calculate the contrast is hard (I’m sure it is), but the interactive examples get into much more nuanced situations. It’s not just the color vs the background in the normal/default state, but also in the various states of interactivity, importantly the focus state.
Just in case you didn’t know, the minimum size for a “clickable target” is 24px × 24px. The bigger the target the easier to click, which is true, and even more true when we think “touch” instead of “click”. This accessibility guideline is really driven by, well, average human finger sizes. Make clickable/touchable things too small, people can’t actually click/touch them, and you have a real accessibility failure.
There is also an element of proximity to it. In Nicole Sullivan’s Expanding your touch targets, she notes the WCAG 2.2 guideline about when you absolutely need a smaller target:
If your design requires a smaller clickable target, keep any other clickable elements at least 12px from the center of the target.
Nicole’s article gets all into how browsers even figure out what thing a user is trying to touch, which is pretty fascinating. And it all started with a Pen, naturally.
You’ll have to pardon my French on this last one. I was captivated by Eric Bailey’s Swearing and automatic captions. While they are “better than nothing at all”, automatic captions are rife with problems.
Many automatic captioning services censor swear words. I feel this is done because there’s the assumption that they’ll be used in a business context.
You can’t solve culture with technology. If you need to rely on software to police your employee’s language, you’ve got bigger fucking problems.
