Web-Accessibility Subscribe to Web-Accessibility RSS feed

“Can we actually say our service is accessible?” Is it done when the checker reports zero errors? If a service has hundreds of screens, do you have to scan them all — or is checking a few enough? And if you pick a few, which screens, how many, and on what grounds can you claim “we comply”? A hand ticking checkboxes one by one on a tablet screen - accessibility evaluation is a matter of following a procedure, not intuition Photo: Jakub Żerdzicki / Unsplash When you study accessibility, there is plenty of material about the standard (WCAG), but surprisingly little about this “how do we evaluate” question. As it turns out, the W3C has had an official answer all along. And on July 23, 2026, that document got its first new version in twelve years: WCAG Evaluation Methodology (WCAG-EM) 2.0. ...

“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. ...

I had clearly written a dark gray into my CSS. color: #595959. On a white background that color has a contrast of 6.4:1, which comfortably clears the accessibility bar of 4.5:1. Pass. Then I ran an accessibility checker, and a red line appeared. This text has a contrast of 4.04:1, which is insufficient. Expected ratio: 4.5:1. I put in a color that measures 6.4:1, so why is it calling it 4:1? Was the checker wrong? ...

Some people set their screen to maximum contrast. Yellow text on black, white text on blue, that sort of thing. For low-vision users this is the difference between being able to read the text and not; people with migraines or light sensitivity go the other way, using a muted, low-contrast palette. They have one thing in common — the user decides the colors. And the moment they do, a good chunk of the colors we wrote in CSS get ignored. ...

I turned on dark mode and my eyes hurt more. The background was black but the text was a heavy gray, so the contrast was far too low; links were still the default blue (#0000ff), which stung. Images blazed alone against the dark screen. One button was the same color as its background, so it was simply invisible. It said “dark mode supported.” But it was dark mode by color inversion, nothing more. ...

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. ...

Imagine scoring 71 on a test. Not quite “well done,” but surely enough to say “you tried,” right? Carrefour, one of France’s largest retailers, seems to have thought so too. In court, the company argued: “Our website complies with 71% of the French accessibility standard.” The court’s answer was blunt. “An e-commerce site cannot be only somewhat accessible; it must be totally accessible.” On June 4, 2026, the judicial court of Caen, France, ordered Carrefour to make its website and mobile app fully accessible within six months. Miss the deadline, and a penalty of 500 euros accrues every single day. It’s the first enforcement ruling to come out of the European Accessibility Act (EAA) regime. ...

This is Part 7 of the “Frontend Testing, Done Right” series. Browse the full series · Glossary Testing Library is the de facto standard for component testing in React and beyond. But the real substance of this tool isn’t its API — it’s one philosophy. The moment you start testing components, temptations appear: “should I find it by class name? peek at internal state?” Testing Library answers firmly: do what the user does. In this article we’ll see what that philosophy means, the order for choosing queries, and why this approach is inseparable from accessibility — all while building a search component from scratch. ...

This is Part 1 of the “Frontend Testing, Done Right” series. Browse the full series · Glossary “Tests? But it already works.” We’ve all said it — or heard it. I said it for years. Look at the screen, click around, “yep, works,” done. But then the features pile up, and every time you touch the code a little voice asks, “if I change this, what breaks over there?” That creeping anxiety is exactly the moment tests become worth their price. ...

Take a moment to think about your day. Did you watch a video with captions because you were somewhere too noisy — or too quiet? Did you crank up your screen brightness because you couldn’t see it in the sun? Did you navigate your phone with just your thumb while carrying something in your other hand? Did you switch on dark mode because your eyes were tired? Congratulations. You are already an accessibility user. ...