Accessibility Fundamentals for Site Owners

Accessibility has an intimidating reputation: a wall of WCAG success criteria, legal acronyms, and audit reports long enough to bind. That reputation keeps site owners from starting, which is a pity, because the field has an open secret — a small set of fundamentals fixes the large majority of real barriers on typical sites. Missing alt text, unlabeled form fields, poor contrast, keyboard traps, and vague link text account for most of the failures automated scans find year after year, and none of them requires specialist knowledge to fix.

This is the working set. Not everything — a guide to the fixes with the highest ratio of human impact to effort.

Reframe it first: who this is for

The framing "accessibility is for disabled users" is true but undersells the scope. Somewhere around one in six people worldwide lives with a significant disability — visual, auditory, motor, or cognitive — and that's before you count situational limits: the parent holding a baby and navigating one-handed, the commuter watching a video muted, the sixty-year-old whose near vision isn't what it was, anyone in bright sunlight. Accessibility work is the practice of not accidentally excluding these people. It also happens to improve SEO (search crawlers consume the same semantics screen readers do), usability for everyone, and — depending on your jurisdiction — your legal exposure. The European Accessibility Act, for instance, now applies to a wide range of businesses selling to EU consumers.

Images: alt text that actually helps

Every meaningful image needs an alt attribute describing what the image conveys. The rules that matter:

• Describe the function, not the file. For a photo in an article: what would you say if you were reading the page aloud to someone? "Bakery storefront with a striped awning at dusk" beats "image1-final-v2.jpg" and beats "photo of bakery."
• Decorative images get empty alt — alt="", deliberately empty, which tells screen readers to skip them. A missing attribute is worse: some screen readers then read the filename aloud.
• Images that are links or buttons describe the destination. A logo linking home: alt="Acme Bakery — home". Not "logo."
• Text baked into images is invisible to screen readers, translators, and search engines. If a promotional banner announces a sale this week, that text needs to exist as real text somewhere.

In WordPress, alt text lives in the Media Library and can be set per-placement. A pragmatic catch-up plan for an existing site: fix your top 20 pages by traffic first, then handle the long tail as you touch pages.

Structure: headings are a table of contents, not a font size

Screen reader users navigate by jumping between headings — it's their equivalent of scanning. That only works if your headings are real (<h1>–<h3> elements, not bolded paragraphs) and hierarchical (one <h1> per page, <h2> for sections, <h3> nested under them, no skipping from h1 to h4 because the h4 "looked right").

If you've ever chosen a heading level for its appearance, decouple the two: pick the level for structure, then restyle that level in your theme. Two minutes with a heading-outline browser extension will show you your pages the way a screen reader user experiences them; it's frequently a humbling two minutes.

Color and contrast: the most common failure on the web

Low-contrast text is the single most frequent accessibility failure detected by automated scans — light gray on white, thin white text over busy hero images, brand colors chosen for vibes rather than legibility. The working standard (WCAG AA) asks for a contrast ratio of at least 4.5:1 for normal text and 3:1 for large text (roughly 24 px and up, or 19 px bold).

• Check your palette once with a contrast-checker tool (WebAIM's is the standard) and record which text/background combinations pass. This is a one-afternoon audit for most brands.
• The usual offenders: placeholder text, "muted" captions, disabled-looking buttons that are actually enabled, and text over photos. For text over images, add a scrim — a subtle dark overlay — rather than hoping the photo cooperates.
• Never encode meaning in color alone. "Fields in red are required" fails for the roughly 1 in 12 men with color-vision deficiency. Pair color with an icon, a label, or text.

Keyboard access: the five-minute test that finds real bugs

Plenty of people never touch a mouse: screen reader users, people with motor impairments, power users, anyone with a broken trackpad. Your site should be fully operable with Tab, Shift+Tab, Enter, Space, and arrow keys.

The test costs five minutes: put your mouse out of reach and traverse your homepage, menu, and most important form using only the keyboard. You're checking for:

1. A visible focus indicator. As you Tab, you must always be able to see where you are. If your theme removed focus outlines for aesthetics (a distressingly common CSS crime: outline: none), keyboard users are navigating blind. Restore it — modern :focus-visible styling lets you show outlines to keyboard users without showing them on mouse clicks.
2. Everything interactive is reachable. Dropdown menus, carousels, modal close buttons, custom video controls. Elements built as clickable <div>s instead of real buttons and links are the usual culprits when something's unreachable.
3. No traps. You can get into every widget and back out. Modals are notorious: focus should move into the dialog when it opens, stay within it while open, and return to the trigger when it closes. (The native <dialog> element handles most of this for free — one more reason to prefer platform features over custom widgets.)
4. Sensible order. Focus should move in reading order, not leap around the layout.

Forms: labels, errors, and not relying on placeholders

Forms are where accessibility failures cost you money directly — an inaccessible checkout or contact form is a lost customer, not a lost abstraction.

• Every input gets a real, visible label, programmatically associated (<label for="email">). Placeholder text is not a label: it vanishes on typing, is usually low-contrast, and isn't reliably announced.
• Mark required fields in text, not color or asterisk-folklore alone.
• Errors must be specific, textual, and adjacent. "Please enter a valid phone number" next to the phone field — not a red border and a prayer. After a failed submit, moving focus to the first error (or a summary at the top) turns a frustrating hunt into a quick fix.
• Don't disable the submit button as validation. A disabled button with no explanation is a dead end; let users submit and show them exactly what to correct.

Links, buttons, and the tyranny of "click here"

Screen reader users often pull up a list of all links on a page, out of context. A list reading "click here, click here, read more, read more, learn more" is unusable. Link text should describe the destination: "Read our returns policy," "Download the current price list (PDF)." This same discipline improves SEO — descriptive anchor text is a ranking signal — and helps every skimming reader.

Related: use the right element for the job. Links go places; buttons do things. A link styled as a button is fine; a <div onclick> pretending to be either is invisible to keyboards and assistive tech until you rebuild everything the native elements gave you for free.

Media: captions and the pause button

• Videos need captions. Deaf and hard-of-hearing users need them; so does everyone watching muted, which by most industry rules of thumb is a large share of social and mobile viewing. Auto-generated captions are a starting point, not a finish — review them, especially for names and jargon.
• Anything that moves should be stoppable. Auto-playing carousels, background videos, and animations need a pause control, and your site should respect the prefers-reduced-motion setting for users whose vestibular disorders make motion physically unpleasant. One CSS media query covers most of it.

How to test without a consultant

A layered testing routine, cheapest first:

The important number in that table: automated tools catch only a minority of problems. They're a floor, not a certificate. A clean Lighthouse score with a keyboard-trapped menu is still a broken site.

Where to start, in order

1. Run an automated scan on your five most important pages; fix the contrast and alt-text findings.
2. Do the keyboard test; restore focus outlines if they're missing.
3. Fix your forms: real labels, textual errors.
4. Rewrite "click here" links as you encounter them.
5. Add the heading-structure check and caption habit to your content workflow so new material starts clean.

None of this requires a rebuild, a budget line, or a compliance officer. It requires treating accessibility the way you treat backups: not a project you finish, but a habit you keep — one that quietly ensures the site you're working so hard on is actually usable by everyone who arrives.

Photo: Eren Li on Pexels