WebAIM: 95.9% of home pages failed on contrast and labels, the same six errors for seven years

Accessibility keeps getting framed as a separate credential, some badge you send a designer off to earn. A fresh batch of hands-on posts says the opposite: the fixes are already in your team's hands, and a few of them ship this week. Let me catch you up.

The deep cut

• Accessibility is design finished properly. WebAIM found errors on 95.9% of home pages, and the top failures are contrast and labeling, not exotica.
• Focus must leave a region before it hides. Chrome's aria-hidden warning overrules your code, and blur() hands the user silence.
• Static markup first, enhance second. Andy Bell shipped last.fm links in plain HTML, then let a web component add the rest.

The gap is vocabulary, not skill

The scary number first. WebAIM crawls the top million home pages every year, and the 2026 results found errors on 95.9% of them, averaging 56 barriers per page. That went up, reversing six years of slow gains. Here is the part that should land with your team: the six most common failures have not changed in seven years.

Read that list as a designer. Contrast. Labeling. Hierarchy. Affordance. Contrast alone shows up on 83.9% of pages. One in three form inputs has no label. These are first-semester fundamentals, not legal trivia. The standards are a translation of design work your team already knows how to do.

Which means the fix is upstream. A contrast problem caught in a Figma review is a token swap. The same problem caught after launch is a ticket, a sprint, and a remediation plan. Your designers sit ahead of nearly all of this.

The warning Chrome is not really warning you about

Here is the one that trips up shipped code. Close a modal and the console turns mustard yellow: a focused element sits inside a region you just hid with aria-hidden. Durgesh Rajubhai Pawar makes the sharp point that this is not advisory. Chrome looked at your markup, decided you were wrong, and shipped a different accessibility tree than the one you wrote.

The popular fixes all make it worse. The blur() one-liner, the setTimeout wrap, stripping aria-hidden. Each quiets the console and hands a screen reader user silence. They press Tab, a control lights up, and nothing speaks. He calls it ghost focus.

The real fix is one sentence: focus has to leave a region before that region becomes hidden. It is an order-of-operations problem, not a new API. Move focus to the trigger first, then mark the overlay inert. Better still, if your team can move to the native <dialog> element with .showModal(), the browser runs the whole focus dance for you.

Enhancement that survives a dead network

Andy Bell wanted streaming links on every album page in his music collection. He pulls them from the MusicBrainz API, but he did not want the page to depend on that call. So he rendered two links he always controls, last.fm and Open Scrobbler, as plain static HTML. Then a small web component fetches the rest on visit and appends them.

If JavaScript fails or the API is down, the user still gets working links. If everything works, they get more. That is the whole pattern, and it is worth stealing for any feature that leans on a third party.

The restraint here matters. He queries once per visit instead of at build time to avoid rate limits, and locks the endpoint to same-origin traffic. Progressive enhancement is not extra polish. It is a floor under the experience.

Craft you can hand a developer Monday

Not every post here is a warning. Some are just good tools sitting on the shelf. Daniel Schwarz's roundup collects fixes worth a look: paint-order to stop text-stroke from chewing the inside of your letters, the Custom Highlight API now supported across browsers, and CSS ways to style skeleton loaders.

There is a small delight one too. A CSS trick for iOS Safari sets a body background color so the area behind the status bar and tab bar matches your header and footer instead of defaulting to white. One line for the simple version. It is a small touch, but it stops the page from feeling like it ends at a hard seam.

The thread across all of it: you do not need a research budget or a new hire to move your numbers. You need existing judgment to survive the trip from comp to production.

Three questions for your team

• Which of the six recurring WebAIM failures, contrast, labeling, empty buttons, missing landmarks, can we push into our design system components so no contributor has to remember them?
• Where are we currently silencing the aria-hidden warning with blur() or setTimeout, and can we reorder the close code or move to native <dialog> instead?
• Which features lean on a third-party API with no static fallback, and what breaks for the user when that call fails?