Web Accessibility: the Basics That Already Solve Most of It

Accessibility has a reputation for being an enormous, standards-heavy subject. It is genuinely large, but the problems are not evenly distributed. A handful of repeated mistakes account for most of the barriers people actually hit on the web, and nearly all of them are cheap to fix if you do it while building, rather than afterwards.

This article covers that handful. It is not the whole standard. It is the set that, once solved, already puts your site ahead of much of what is live today.

Who gets shut out when a site is inaccessible

It is tempting to picture a single user profile, a blind person with a screen reader. That person exists and matters, but the affected group is far larger and much less obvious.

• People with low vision browsing at 200 per cent zoom.
• People with colour blindness who cannot see an error state signalled only by red.
• People with motor limitations navigating by keyboard alone, or with a device that emulates one.
• People with dyslexia who stall on justified text with no hierarchy and lines that run too long.
• People with vestibular sensitivity who feel ill from parallax and auto-rotating carousels.
• Anyone with an arm in a cast. Anyone holding a phone in bright sunlight. Anyone who is 78.

Accessibility is not a feature for a fixed minority. It is your site's tolerance for conditions any person can have, temporarily or permanently. And it overlaps almost entirely with good usability: an accessible site is usually faster for everyone to understand.

Colour contrast and how to test it

This is the one section of this article with fixed numbers, and they are worth memorising. WCAG defines a contrast ratio between text colour and background colour, on a scale from 1:1 (invisible) to 21:1 (pure black on pure white).

At level AA, the practical benchmark most policies use:

• Normal text needs at least 4.5:1.
• Large text needs at least 3:1. Large text, by the standard's definition, starts at 18 point, or 14 point bold, which in practice lands near 24px, and 18.66px when bold.
• User interface components and essential graphics need 3:1. That includes the border of an input, an icon carrying meaning on its own, and the focus indicator.

The common failures are always the same: light grey text on white because "it looks more elegant"; a placeholder used as a label; white text over a photo with no darkening layer; a button in a light brand colour with white text on top.

Testing takes seconds. Chrome DevTools shows the contrast ratio in the inspector's colour picker. Lighthouse flags failures automatically. Any online contrast checker handles an isolated pair of colours. And the most honest test of all: open the site on a phone, outdoors, at midday.

One specific trap: when text sits on a background image, contrast varies pixel by pixel. Add a solid layer or a gradient with enough opacity, and test against the lightest part of the image, not the average. And if your images are heavy enough that the layer takes a while to appear, it is worth revisiting image optimisation with WebP and AVIF.

Keyboard navigation and visible focus

A thirty-second test: open your home page and press Tab repeatedly without touching the mouse. Three things need to be true.

1. You can see where you are. Every focused element needs a visible indicator. If someone on your project wrote outline: none in the CSS without putting anything in its place, that is probably the most serious accessibility bug on the site.
2. The order makes sense. Focus should follow the visual order of the page. A strange order is almost always a symptom of layout built with absolute positioning, or a DOM order that does not match the reading order.
3. You can reach everything and leave everything. Menu, dropdown, modal, carousel. If a modal opens and Tab keeps wandering through the content behind it, or if Esc does not close it, it is broken. If you enter a component and cannot get out, that is a keyboard trap, one of the few failures the standard treats as critical with no middle ground.

The best focus indicator is the one you design on purpose: a two-pixel outline, at least 3:1 against the background, with a small offset so it does not hug the element. Use :focus-visible so it shows up for keyboard navigation without cluttering mouse clicks.

Two details that fix a lot: use native elements wherever possible, button for actions, a for navigation, because they already come with focus, role and keyboard behaviour built in; and add a skip-to-content link at the top, for people who do not want to traverse the whole menu on every page.

Alt text that actually does something

Alt is not a caption, not a filename, and not a place for keywords. It is what the image does on the page, expressed as text.

The most important distinction, and the most ignored, is between informative and decorative images.

• A decorative image gets an empty alt: alt="". Empty on purpose, quotes present. That tells the screen reader to skip the image. It fits ornaments, textures, and icons that merely repeat text sitting right beside them. A phone icon next to the word "Phone" does not need announcing twice.
• An informative image gets a descriptive alt. Describe the information, not the file. On a portfolio page, "Clinic home page with the booking form in the hero" beats "project-01".
• Never omit the attribute. With no alt, many screen readers read the filename aloud. Nothing is worse than hearing "I M G underscore 4471 dot jay peg".
• An image that is a link gets the alt of its destination. If the logo goes home, the alt describes the action, not the artwork.
• An image containing text needs that text in the alt. And ideally should not exist: text inside an image does not scale with zoom and cannot be selected.

A good test: read the page aloud, replacing each image with its alt. If the result still makes sense and does not feel repetitive, you got it right.

Headings as structure, not as styling

Screen reader users navigate by headings the same way you skim a page with your eyes. It is the most used shortcut. A site with proper headings is navigable; a site that uses h3 because "it was the right size" is a maze.

The rules are few:

• One h1 per page, describing what that page is about.
• Do not skip levels going down. From h2 go to h3, not straight to h4.
• A heading is hierarchy, not size. If the title needs to be smaller, change the CSS, not the tag.
• Big bold text is not a heading. To a screen reader it is just a fat paragraph.

There is a bonus: the same structure that helps a screen reader helps search engines parse the document. Accessibility and technical SEO overlap heavily here, as covered in the technical SEO checklist for small businesses.

Forms with real labels

Forms are where broken accessibility turns into direct lost revenue, because that is exactly where conversion happens.

1. Every field has an associated label. With for pointing at the field's id. That gives the field a name for the screen reader and also makes clicking the label focus the field, which helps everyone on mobile.
2. A placeholder is not a label. It disappears when typing starts, usually has low contrast, and is not read reliably. Use placeholders for format examples, never for the field name.
3. Errors need text, not just colour. A red border alone communicates nothing to someone with colour blindness. Write the message, place it near the field, and associate it programmatically.
4. The message has to say what to do. "Invalid field" does not help. "Enter the phone number with area code, digits only" does.
5. Use the right types and autocomplete values. type="email", type="tel" and proper autocomplete values switch the mobile keyboard and enable autofill. That is cognitive and motor accessibility as much as conversion, a topic that crosses into the anatomy of a landing page that converts.

Motion and prefers-reduced-motion

Large animations, parallax, self-rotating carousels and page transitions with wide displacement cause real discomfort for people with vestibular sensitivity, from nausea to migraine.

The standard asks for two things. First, any content that moves, blinks or scrolls automatically for more than five seconds needs a way to pause it. Second, and easier, respect the system preference. Every modern operating system has a reduce-motion setting, and the browser exposes it through prefers-reduced-motion.

In practice: keep opacity and colour transitions, which rarely bother anyone, and switch off large displacements, zooms and parallax when the preference is on. It is a small block of CSS and it settles the whole category. Side benefit: less heavy animation usually improves the visual stability measured by Core Web Vitals too.

And avoid anything that flashes more than three times per second. That is a safety limit, not a comfort one: flashing at that rate can trigger seizures in people with photosensitive epilepsy.

Testing with a screen reader in fifteen minutes

You do not need to become an advanced screen reader user. You need to hear your own page once. It is uncomfortable and extremely efficient.

On Windows, install NVDA, which is free. On macOS and iOS, VoiceOver is already there. On Android, so is TalkBack.

A fifteen-minute script:

1. Turn the reader on, close your eyes, and try to work out what the page offers from audio alone.
2. Browse the headings list and see whether the structure makes sense without the visuals.
3. Browse the links list. If you hear "click here", "learn more", "read more" repeated, your link text does not work out of context.
4. Fill in the whole contact form. Was every field announced with a name? Were the errors read out?
5. Open the mobile menu and close it. Could you?

Automated tools, Lighthouse, axe, WAVE, catch a meaningful share of the problems, but not all: they know an alt exists, not whether the alt is right. Use both.

WCAG without memorising the standard

WCAG is organised around four principles, and knowing only those already guides a decision well: content has to be perceivable, operable, understandable and robust. The criteria split into three levels, A, AA and AAA. AA is the bar adopted by most public and private policies, and it is a realistic target for an ordinary website. AAA is too strict for general content.

If you do only what is in this article, contrast within 4.5:1 and 3:1, working keyboard navigation with visible focus, correct alt text, hierarchical headings, real labels and respect for the motion preference, you cover a large slice of level AA without opening the standard once.

The rest comes later, and comes easier, because the foundation is already in place. The expensive path is always the reverse: discovering all of this in a finished site and having to reopen every component.

If you want a site built with these basics baked in from the first component, see our portfolio and talk to ALB Seven.