Tags: wcag

7

sparkline

Tuesday, September 14th, 2021

Accessibility testing

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.

Saturday, February 15th, 2020

Link Targets and 3.2.5 | Adrian Roselli

Here are the many, many reasons why you should not open links in a new window (or tab).

Regardless of what accessibility conformance level you target, do not arbitrarily open links in a new window or tab. If you are required to do so anyway, inform users in text.

Thursday, December 6th, 2018

Drupal’s commitment to accessibility | Dries Buytaert

Shots fired!

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.

Wednesday, March 7th, 2018

How we’ve made GOV.UK Elements even more accessible

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!

Monday, November 3rd, 2008

Web Content Accessibility Guidelines (WCAG) 2.0

WCAG 2.0 has just entered proposed recommendation status. What a long strange trip it's been.

Thursday, February 8th, 2007

Web Directions North, day one

The first day of Web Directions North just wrapped up and what a day it was.

Everything went super-smoothly right from the get-go with some opening remarks from the ever-sauve Dave Shea followed by some very entertaining audience participation led by Molly. Her Crimes Against Web Standards presentation was punctuated with hilarious video cliplets from Eric Meyer and others.

After that, I did my talk which went pretty well. As I said at the outset, I was covering the basic Ajax stuff to set the scene for Derek. I was John The Baptist to his Jesus Christ.

Once that was done, I had a long lunch in the rotating restaurant on the nineteenth floor of the hotel… if only the damn fog would lift a little bit more.

The afternoon was spent luxuriating in the microfromats presentation from John, Dan and Tantek followed by Joe Clark in scintillating form. He conducted a fireside chat and had the audience in the palm of his supple hand. He gave us a scoop by unveiling his call to Tim Berners-Lee to scrap WCAG 2. Quelle surprise.

Now I’m kicking back with a beer courtesy of Adobe and meeting some great people. All in all, a great day. May tomorrow go equally smoothly.

Thursday, October 26th, 2006