Web-Accessibility Subscribe to Web-Accessibility RSS feed

There’s a month that doesn’t show up on most calendars, yet is observed all over the world. July — Disability Pride Month. The pairing of “disability” and “pride” can feel unfamiliar at first. The emotional register we’re used to around disability observances tends to be “consideration” or “overcoming.” Pride Month tells a different story: disability isn’t something to overcome or to hide — it’s a natural part of who a person is. ...

What happens when you run one million home pages through an automated accessibility checker? About 56 million accessibility errors come pouring out. That’s an average of 56.1 per page. The number alone might get a shrug — “that’s just the web.” The problem is the direction. Last year it was 51. In a single year, errors grew by 10.1%. After years of slow-but-steady progress, web accessibility just took a step backward. ...

Say you run an accessibility checker. You feed it a site’s URL, and the checker has to decide: which pages should it actually look at? Is the homepage enough? If so, you don’t have much basis for saying “this site is accessible” or “this site isn’t.” But checking every page isn’t realistic either — forums, blogs, and shopping sites can have hundreds or thousands of posts. Auditing all of them blows the time and cost budget. ...

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

↻ 2026-08-12 Updated Corrected the legal basis of Korea’s quality certification. With the Digital Inclusion Act taking effect on January 22, 2026, Article 47 of the Framework Act on Intelligent Informatization was repealed and the certification scheme moved to Articles 21–22 of the Digital Inclusion Act — this post had been citing the old provision. The body, FAQ, and comparison diagram are updated together. “Can we actually say our service is accessible?” ...

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