ACCESSIBILITY FIXES THAT ALSO HELP SEO

You have a report with an intimidating number on it. Before touching anything, understand two things about that number.

It's inflated by repetition. Scanners report every instance, so one template mistake becomes forty errors. A gallery with forty images missing alt attributes is one fix applied forty times. Sorting by type rather than working down the list turns the report from a wall into a short list of jobs.

It's also incomplete, and that matters more. Automated tools detect only a minority of real barriers. They're good at things a machine can check: a missing attribute, a contrast ratio, an unlabelled input. They can't tell you whether your alt text is useful, whether your headings describe the content, or whether the tab order makes sense. A clean scan isn't a working site, and the steps that follow are ordered so the manual ones aren't left to last.

So group the report into four buckets, which between them account for most of what gets found: contrast, missing alt, form labels, and empty or unclear links. Anything left over goes in a fifth pile for step 8.

Headings are how a page is navigated without eyes. Screen reader users jump between them the way a sighted reader skims, so a page whose headings are chosen for their font size rather than their level is a page with a broken table of contents.

Three rules, and they're the same three that make a page legible to a crawler:

• One H1 per page, and it describes what the page is. Not the site name, not the logo.
• No skipped levels. An H2 is followed by an H3, never straight to an H4 because that size looked better. If the size is wrong, that's a CSS problem, not a markup one.
• Headings describe content. A line styled to look like a heading but marked up as a bold paragraph is invisible as structure to both audiences.

The test is quick: extract the headings alone and read them as an outline. If that outline tells you what the page covers and in what order, the structure is sound. If it reads as a list of disconnected phrases, or jumps from a big idea to a detail and back, the levels are wrong.

Where the overlap is exact. This one is genuinely identical for both goals, which is why it goes first. There's no version of this fix that helps accessibility and not search, or the reverse.

Alt text is the most commonly reported failure and the most commonly misunderstood fix, because the instruction people remember is "add alt text to images" and that isn't quite the rule.

The rule is that every image needs an alt attribute, and not every image needs words in it. Three outcomes, and the decision tree artifact below runs them properly:

• It conveys information. Describe what it conveys, not what it depicts. A photo of your van outside a house isn't "white van"; it's what it tells the visitor, which is usually that you did this kind of job in this kind of place.
• It's decorative. A flourish, a divider, a background texture. It gets alt="", empty, which tells assistive software to skip it. This is a real answer, not a cop-out.
• It's a link or a button. Then the alt text describes the destination or action, not the picture. An icon linking to your contact page is "Contact us", not "envelope icon".

Leaving the attribute off entirely is the actual error, because software then falls back to guessing and often reads the filename, so somebody hears a string of digits and a file extension.

Where the overlap ends. Both audiences want a real description, so far so aligned. But alt text is also where people stuff keywords, and that fails both goals simultaneously: it degrades the experience for the person depending on it, and it's the kind of signal search engines discounted years ago. If you find yourself editing alt text with a keyword list open, close the list.

Screen reader users can pull up a list of every link on a page and navigate by it. On a typical small business site that list reads: click here, click here, read more, https://example.com/services/, learn more, click here.

The test is to read each link out of context and ask whether it says where it goes. That single question resolves almost every case.

• Click here to see our services becomes See our services.
• Read more becomes Read more about furnace repair.
• A bare URL becomes what the page is, since a screen reader may otherwise announce the address character by character.
• Six Learn more links on one page become six different phrases, because six identical link texts pointing at six destinations is ambiguous by definition.

Where the overlap is exact, with one caveat. Descriptive link text is anchor text, and anchor text is one of the clearer signals about what you're linking to, so this fix is unusually well aligned. The caveat is the same as alt text: descriptive means describing the destination honestly, not packing the phrase with terms. Emergency furnace repair in Etobicoke, available 24 hours as link text isn't descriptive, it's an advert wearing a link's clothes.

This is the most revealing test in the guide, it takes five minutes, and most sites fail it at the navigation menu. It's also the step with the least SEO overlap, and it's here anyway, because it's the one where you find out whether somebody can actually use the site.

Hands off the mouse. Press Tab repeatedly from the top of the page and watch:

1. Can you see where you are? There must be a visible focus indicator on every stop. If your CSS has outline: none anywhere, that's almost certainly why it's missing, and removing that line is often the entire fix.
2. Can you reach everything? Every link, every button, every form field. Dropdown menus are the usual failure, particularly ones built to open on hover.
3. Does the order make sense? It should follow the visual order. Jumping from the header to the footer and back means the markup order doesn't match the layout.
4. Can you get out? If focus enters something and can't leave by keyboard, that's a trap, and it's the most serious thing on this list. Modals and embedded widgets are the usual culprits.
5. Then complete your own contact form using only the keyboard. Tab to it, fill it, submit it. This is the whole test in one action, and it's the one that surprises people.

A useful thing to add while you're here: a skip link, a link at the very top that jumps past the navigation to the main content. Without one, a keyboard user tabs through your entire menu on every single page. It's a few lines of markup and it's the fix with the best ratio of effort to relief on this list.

Contrast is the most commonly failed check on the web and the easiest to fix, because it's a colour value rather than a structural change.

The thresholds, from WCAG 2.2 at Level AA:

Run a contrast checker over the places designers reliably get it wrong, which are rarely the body copy:

• Light grey placeholder text in form fields. Almost always fails, and it's often carrying the instruction for the field.
• Button labels, especially white text on a mid-tone brand colour, which is the classic near-miss.
• Text over images, where it may pass in one part of the photo and fail in another.
• Muted secondary text: captions, form hints, footer links, disabled-looking states that aren't actually disabled.

Where the overlap ends completely. This one does nothing for SEO. Nothing. It's in the guide because it takes twenty minutes, it affects every visitor in bright sunlight or with ageing eyes, and pretending it carries a ranking benefit would be the kind of overclaim this guide is trying to avoid.

Forms are where accessibility failures cost money directly, because a form that's hard to complete is abandoned by everybody, not only by people using assistive technology.

• Every input needs a real label, properly associated. The label's for attribute matches the input's id. A styled span sitting above the box isn't a label, however much it looks like one. The markup artifact below has the pattern.
• A placeholder isn't a label. It disappears when typing starts, so anyone who loses their place has lost the question too. Use both if you like the look, but never the placeholder alone.
• Errors must be in text, next to the field. A red border says nothing to a screen reader and nothing to somebody who can't distinguish the colour. Say what's wrong and how to fix it.
• Required fields need more than colour or an asterisk. Say required, or mark it in a way that survives being read aloud.
• Group related fields. Radio buttons and checkboxes need their question associated with the set, not just with each option.

Where the overlap ends, and something better begins. None of this helps rankings. It helps conversions, which is usually the thing the ranking was for, and this is the step whose business case is easiest to make. It also pairs with the form test in guide 01: that one checks the submission actually arrives, this one checks a person can fill it in. Both failures are silent and both cost you enquiries you never hear about.

The last step is the one that separates this from an afternoon of tinkering, and it's the one most likely to be skipped because it feels like admitting failure. It's the opposite.

Re-run the scan, compare against the number you wrote in step 1, then write a short handoff document with three sections:

• Fixed. What you corrected, on which pages, and the date.
• Known and not fixed. Things you found and couldn't resolve, usually because the markup comes from a theme or a third-party widget. Say what and say why.
• Not assessed. The honest one. You didn't test with a screen reader, you didn't test with real users, and you haven't looked at every page. Name that plainly.

This document is worth more than the fixes alone. It stops you re-discovering the same unfixable theme problem in six months, it tells whoever works on the site next what was already considered, and if you engage a specialist they begin from your work rather than zero, which is a materially cheaper start.

Then set a reminder to re-run the scan after any redesign or theme update, because these regress quietly. The focus outline in particular has a habit of disappearing again.