Accessibility-Testing Subscribe to Accessibility-Testing RSS feed

This is Part 15 of the “Frontend Testing, Done Right” series. Browse the full series · Glossary Whether a button has a name, you can tell by looking at that button. But whether its text contrasts enough with the background, whether the page declares a language, whether an id is duplicated — you can’t tell from one element. You have to look at the whole screen, and at the state it’s actually rendered in. That’s tiring to do by eye every time, which is exactly why you want an automated checking engine. ...

“We’re certified, so we should be fine.” It’s an easy thing to believe on the side that builds the website. Yet even on sites with a certification mark, it’s common for a screen reader user to fail to find the log-in button, or a low-vision user to be unable to read gray text on gray. Having been audited once, and being usable right now, are two different stories. The tool I built to shrink that gap is A11y Check. Put in a URL and it audits the accessibility automatically, then hands back a report and a fix guide. This article covers what A11y Check does, how it works, and why I opened the code. Let’s start with where it came from. ...

This is Part 10 of the “Frontend Testing, Done Right” series. Browse the full series · Glossary What comes to mind when you hear “accessibility testing”? Hiring a consultant, adopting a dedicated audit tool, working through checklists hundreds of items long… it’s easy to picture something big. Surprisingly, though, half of accessibility verification comes free just from writing component tests well. This article is that principle plus the practice — flushing out div buttons, naming icon buttons, and guarding focus that vanishes into thin air. ...