Just In Time 4 Tech justintime4tech.fyi ← all guides

Privacy & Sovereignty

Your site should let everyone in

Accessibility gets filed under "compliance" — a legal box, a feature you bolt on if there's budget. But strip away the jargon and it's something simpler and more serious: a site that can't be used by people with disabilities is quietly taking their access away. That's not a missing feature. It's the same extraction this whole field guide is about, pointed at the people least able to route around it.

Just In Time 4 Tech · A field guide, not a sales pitch

Most of this field guide is about things added to your site that take from your visitors — their data, their attention, their time. Accessibility is the same idea seen from the other direction: not something extra taken, but something basic withheld. When a site can't be read by a screen reader, navigated by a keyboard, or seen by someone with low vision, it has shut a door on real people. They came to your page and couldn't get in.

And this isn't a rare edge case. Disability is ordinary — low vision, blindness, motor conditions that make a mouse impossible, and the simple fact that all of us age into needing larger text and clearer contrast. A site that only works for the able-bodied, mouse-using, sharp-eyed visitor is a site that turns away a large share of the people it was built to reach.

The web is failing this badly right now. A 2025 analysis of the top million websites found that roughly 96% fail basic accessibility standards — only about four in a hundred are genuinely usable by everyone, with an average of around 50 distinct barriers per page. The bar is on the floor. Clearing it is one of the easiest ways to stand apart.

The four doors every visitor comes through

The international standard (WCAG) rests on four plain principles — the acronym is POUR, but you can hold them as four doors a visitor needs open. Most failures are just one of these doors stuck shut, and most fixes are simply opening it.

P

Perceivablecan they sense it?

Can the content be seen or heard? Text needs enough contrast to read; images need text descriptions so a screen reader can speak them; nothing meaningful is conveyed by color alone.

Shuts out: blind and low-vision visitors, anyone on a glaring phone screen outdoors.

O

Operablecan they use it?

Can every button, link, and form be reached and used — including with only a keyboard, no mouse? No traps you can't tab out of, no menu that only opens on hover.

Shuts out: people with motor disabilities, many older users, keyboard power-users.

U

Understandablecan they follow it?

Is it clear and predictable? Plain language, forms with real labels (not just a placeholder that vanishes), errors explained in words, a page that doesn't rearrange itself unexpectedly.

Shuts out: people with cognitive differences — and, honestly, everyone in a hurry.

R

Robustdoes it work everywhere?

Clean, standard code that assistive technology can actually parse — buttons that announce themselves as buttons, a declared page language, structure a screen reader can navigate.

Shuts out: anyone using a screen reader or assistive tool against sloppy markup.

You'll notice none of these is exotic. They're the difference between a building with a step at the only entrance and one with a level threshold. The building isn't doing anything fancy. It just didn't put a barrier where it didn't need one.

Inaccessibility is rarely a decision someone made. It's a barrier nobody removed — which is exactly why it's yours to take down.

The handful of fixes that matter most

The encouraging part: a few issues cause most of the exclusion, and they're the cheap ones to fix. You don't need a rebuild. You need to open the doors that are stuck.

  • Contrast. Make text dark-enough against its background — the standard is a 4.5:1 ratio for normal text. The pale-gray-on-white that looks elegant in a mockup is unreadable for millions. (This very page holds every color to that ratio.)
  • Alt text. Every meaningful image gets a short, true description in its alt attribute, so a screen reader can speak what sighted visitors see. Decorative images get an empty alt="" so they're skipped. "IMG_4392.jpg" is not a description.
  • Real form labels. Every field needs a visible, programmatic label — not just placeholder text that disappears the moment someone types, leaving a screen-reader user lost.
  • Keyboard navigation. Tab through your whole site without a mouse. Can you reach the menu, the form, the submit button? Can you get out of every pop-up? If not, neither can a visitor who can't use a mouse.
  • Labeled links and buttons. An icon with no text just says "link" to a screen reader. Give it words, so people know where it goes.

Beware the "one-click" fix

There's a tempting shortcut worth a direct warning, because it's extraction wearing the costume of a solution: the accessibility overlay widget — a floating toolbar plugin that promises instant compliance. It looks like care. It mostly isn't.

Real accessibility

  • Fixes the actual code — contrast, labels, structure
  • Works with the assistive tools people already use
  • Helps every visitor, permanently, invisibly
  • Genuinely lowers legal risk because the site is usable
  • Costs some real work, mostly once

The overlay widget

  • Bolts a UI layer on top of code that's still broken
  • Often fights the screen reader the visitor already has
  • Courts have ruled it doesn't shield owners from lawsuits
  • Regulators have acted against false compliance claims
  • A monthly fee that buys reassurance, not access

The overlay is the same trade this whole field guide warns about: a paid layer that looks like it solves the problem while leaving the real one in place — and, often, quietly collecting from visitors in the process. The honest fix is plainer and cheaper: open the actual doors. There's nothing to subscribe to.

Why this is the purest form of building clean

Here's the quiet reward, and it's the same one that runs through everything here: accessibility and quality are the same direction. Better contrast makes a site more readable for everyone. Clear labels help every user. Keyboard navigation helps power-users. Clean, standard code is faster and more robust. A site built to let everyone in is simply a better-built site — there is no version of this where helping disabled visitors costs the others anything.

And it's non-extraction at its most fundamental. The other guides are about refusing to take from your visitors. This one is about refusing to shut them out — which is the same respect, aimed at the people a careless web most often forgets. A site that takes nothing and excludes no one is the whole ethic in a single page.

Check your own doors, right now

You can test the most important things yourself, free, in a few minutes — no audit required:

  1. Unplug your mouse (or just don't touch it) and Tab through your site. Can you reach and use everything? Can you escape every pop-up?
  2. Check your contrast with a free contrast-checker tool — paste your text and background colors, confirm they hit 4.5:1.
  3. Look at your images — does each meaningful one have real alt text, not a filename or blank?
  4. Click into your forms — does every field have a visible label that stays put when you type?
  5. Run a free automated checker for a first pass — it catches maybe a third of issues, but it's a fast start on the obvious ones.

Whatever you find, it isn't a disaster — it's a set of doors you now know how to open. Most sites have a handful stuck shut, and most of those are an afternoon's work. You don't have to fix everything at once. You just have to stop turning people away.

When you're ready

Want a site that genuinely lets everyone in?

Clean builds and privacy hardening that bake accessibility in from the first line — proper contrast, real labels, keyboard navigation, standard code screen readers can read — no overlay widget, no monthly "compliance" fee, just a site that actually works for everyone. The way this whole hub was built.

See privacy & hardening services →