12

The origins of the steam engine

The fascinating pre-history of steam power, illustrated with interactive widgets.

Why the super rich are inevitable

The interactive widgets embedded in this article are excellent teaching tools!

I was doing some accessibility work with a client a little while back. It was mostly giving their site the once-over, highlighting any issues that we could then discuss. It was an audit of sorts.

While I was doing this I started to realise that not all accessibility issues are created equal. I don’t just mean in their severity. I mean that some issues can—and should—be caught early on, while other issues can only be found later.

Take colour contrast. This is something that should be checked before a line of code is written. When designs are being sketched out and then refined in a graphical editor like Figma, that’s the time to check the ratio between background and foreground colours to make sure there’s enough contrast between them. You can catch this kind of thing later on, but by then it’s likely to come with a higher cost—you might have to literally go back to the drawing board. It’s better to find the issue when you’re at the drawing board the first time.

Then there’s the HTML. Most accessibility issues here can be caught before the site goes live. Usually they’re issues of ommission: form fields that don’t have an explicitly associated label element (using the for and id attributes); images that don’t have alt text; pages that don’t have sensible heading levels or landmark regions like main and nav. None of these are particularly onerous to fix and they come with the biggest bang for your buck. If you’ve got sensible forms, sensible headings, alt text on images, and a solid document structure, you’ve already covered the vast majority of accessibility issues with very little overhead. Some of these checks can also be automated: alt text for images; labels for inputs.

Then there’s interactive stuff. If you only use native HTML elements you’re probably in the clear, but chances are you’ve got some bespoke interactivity on your site: a carousel; a mega dropdown for navigation; a tabbed interface. HTML doesn’t give you any of those out of the box so you’d need to make your own using a combination of HTML, CSS, JavaScript and ARIA. There’s plenty of testing you can do before launching—I always ask myself “What would Heydon do?”—but these components really benefit from being tested by real screen reader users.

So if you commission an accessibility audit, you should hope to get feedback that’s mostly in that third category—interactive widgets.

If you get feedback on document structure and other semantic issues with the HTML, you should fix those issues, sure, but you should also see what you can do to stop those issues going live again in the future. Perhaps you can add some steps in the build process. Or maybe it’s more about making sure the devs are aware of these low-hanging fruit. Or perhaps there’s a framework or content management system that’s stopping you from improving your HTML. Then you need to execute a plan for ditching that software.

If you get feedback about colour contrast issues, just fixing the immediate problem isn’t going to address the underlying issue. There’s a process problem, or perhaps a communication issue. In that case, don’t look for a technical solution. A design system, for example, will not magically fix a workflow issue or route around the problem of designers and developers not talking to each other.

When you commission an accessibility audit, you want to make sure you’re getting the most out of it. Don’t squander it on issues that you can catch and fix yourself. Make sure that the bulk of the audit is being spent on the specific issues that are unique to your site.

Overlay Fact Sheet

Based on the problems with accessiBe and its ilk, I have signed my name to this:

1. We will never advocate, recommend, or integrate an overlay which deceptively markets itself as providing automated compliance with laws or standards.
2. We will always advocate for the remediation of accessibility issues at the source of the original error.
3. We will refuse to stay silent when overlay vendors use deception to market their products.
4. More specifically, we hereby advocate for the removal of accessiBe, AudioEye, UserWay, User1st, MK-Sense, and all similar products and encourage the site owners who’ve implemented these products to use more robust, independent, and permanent strategies to making their sites more accessible.

Rethinking the date picker UI – UX Collective

I quite like this date-picking interface. It would be nice if browsers picked it up for input type="date".

Design Patterns on CodePen

This ever-growing curated collection of interface patterns on CodePen is a reliable source of inspiration.

You Might Not Need JavaScript

Una has put together a nice collection of patterns that use CSS for interactions. JavaScript would certainly be more suitable for many of these, but they still provide some great ideas for robust fallbacks.

Google Web Elements

Standalone embeddable widgets from Google that you can drop into any web page. The maps widget finally frees the maps API from the tyranny of coupling a domain with an API key.

Yahoo! Application Platform - YDN

This sounds like Yahoo's answer to Facebook Platform for single web pages or (spit!) widgets. We'll see if the reality matches the hype. "The Yahoo! Application Platform allows you to build and launch open-social applications to the largest daily …

Build Last.fm: Extend your Last.fm experience

Last.fm have gathered together the best apps built on their API and put them all in one handy browsable spot.

Home « Widgety Goodness

A conference all about, well, widgety goodness. In Brighton of course—home to all the best conferency goodness.

jQuery UI: Widgets, Components, and Interactions

From the people who brought you jQuery comes a set of widgets built using jQuery complete with documentation and tutorials.