Accessibility quick wins a small team can ship this month

Most of the accessibility problems on a typical business website come from a short list of repeat offenders: headings chosen for their size instead of their meaning, images with useless alt text, low-contrast copy, invisible focus rings, and form fields with no real label. A small team can fix that list in a month without a redesign, a paid audit or a plugin subscription. What follows is the order to work in, and the free tools to check yourself as you go.

Test first: one keyboard pass and three free tools

Start with a test, not a fix list. Plenty of teams begin by installing a scanner, collecting hundreds of warnings and losing the month to triage. The keyboard pass is faster, and it surfaces the failures that actually stop people: a menu that cannot be opened, a modal that traps you, a checkout button you can never reach.

1. Open your busiest page, move the mouse aside, and press Tab from the very top. A "Skip to main content" link should be the first thing that appears.
2. Keep tabbing through the entire page. Watch for two failures: a stop where you cannot tell what has focus, and a control you can click with a mouse but never reach with Tab.
3. Open the main navigation with Enter or Space. Move through submenus with arrow or Tab keys, and close them with Escape.
4. Tab into every overlay: the cookie banner, the newsletter modal, the chat widget, the carousel. Focus should move into it, stay inside while it is open, and return to the trigger when it closes.
5. Complete your main form with the keyboard alone. Submit it with a deliberate mistake and see whether focus lands on the error message or leaves you guessing.
6. Write down every place you got stuck. That list, in order, is your backlog for the month.

Then bring in the tools. The axe DevTools extension and WAVE both run in the browser and flag missing labels, empty links, contrast failures and broken heading order. Lighthouse, built into Chrome DevTools, gives you a repeatable score you can watch over time, though the score measures what a machine can check rather than whether the page is usable. Add a screen reader for ten minutes: VoiceOver ships with macOS and iOS, and NVDA is free on Windows. Automated checks only ever catch part of the problem, because a machine cannot tell you whether alt text is helpful, only whether it exists.

Headings and landmarks: give the page a spine

Headings are the table of contents for anyone who cannot see the layout. Screen reader users routinely jump from heading to heading rather than reading top to bottom, so a page where every heading is an h2 because that was the size someone liked reads as a flat wall.

Three rules cover almost every case. Use one h1 that names the page. Do not skip levels on the way down. Never choose a heading level for its appearance; choose the level for the structure and set the size in CSS.

Landmarks do the same job at a larger scale. Wrap the banner in header, the primary menu in nav, the page content in a single main, and the bottom in footer. If a page has two navigation regions, label them with aria-label so they are distinguishable. Add a skip link as the first focusable element, pointing at your main element. If your site runs on a CMS, all of this is usually a template change made once, not a page-by-page edit.

Many people using assistive technology do not read your page top to bottom. They scan it by heading, landmark and link, the same way you scan it by eye.

Alt text that actually helps

The test for alt text is simple: if you removed the image and replaced it with your sentence, would the page still make sense? Describe the job the image does in context, not the pixels. Skip "image of" and "photo of", since screen readers already announce that an image is there, and keep it to one useful sentence.

Colour contrast and focus people can see

WCAG 2.2 AA asks for a contrast ratio of at least 4.5:1 for body text, 3:1 for large text, and 3:1 for icons, control borders and focus indicators against what sits next to them. The WebAIM contrast checker and the eyedropper in your browser's colour picker will settle any argument in seconds.

The usual offenders are predictable: placeholder text, light grey captions and footnotes, white labels on a mid-tone brand colour, disabled buttons, and any text laid over a photo without a scrim behind it. Fix them in your design tokens rather than one component at a time, and check the same values in dark mode if you offer one. While you are there, make sure colour is never the only signal. An error state needs an icon or wording, not just a red border; a link inside body copy needs an underline, not only a different hue.

Focus indicators are the other half of this. If your reset stylesheet contains outline: none, that is almost certainly a bug. Use the :focus-visible pseudo-class to show a clear ring for keyboard users without adding one to every mouse click, give it two or three pixels of width and a small offset, and confirm that a sticky header or floating chat bubble does not cover the focused element when you tab down the page. WCAG 2.2 also asks that interactive targets be at least 24 by 24 CSS pixels, with a handful of exceptions such as links inside a sentence, which usually means giving small icon buttons more padding.

Forms: labels, errors and instructions

Forms are where accessibility failures turn directly into lost enquiries. Work through yours in this order.

1. Give every field a real label element tied to the input with the for attribute. A placeholder is not a label: it disappears the moment someone types, and it usually fails contrast.
2. Keep help text visible rather than hiding it in a tooltip, and connect it to the field with aria-describedby so it is announced along with the label.
3. Set the right input type and autocomplete value on name, email, phone and address fields. It fills forms faster for everyone and puts the correct keyboard on phones.
4. Group related radio buttons and checkboxes in a fieldset with a legend, so the question is announced with the options.
5. Write errors as text beside the field, in plain language that says how to fix the problem. "Enter a phone number with area code" beats "Invalid input".
6. On a failed submission, show a summary at the top of the form, link each item to its field, and move focus to that summary. Never leave the person hunting for what went wrong.
7. Do not leave the submit button disabled until the form is valid. Let people submit, then tell them what needs changing.

Link text, motion and captions

Link text should make sense read on its own, because that is exactly how assistive technology often presents it. A page where every link says "Read more" is unusable in a links list. Name the destination instead: "Read the accessibility checklist". Flag anything unexpected in the text itself, such as a PDF download or a link that opens a new tab.

Motion is a quick win most teams skip. Wrap your animations, parallax effects and auto-advancing carousels in a prefers-reduced-motion media query so that people who have asked their operating system for less movement get a static version. Carousels that advance on their own also need a visible pause control, and nothing should autoplay with sound.

Captions close the loop. Every video with speech needs a caption track, and auto-generated captions need a human pass before they go live, because names, product terms and numbers are where machines fail. Publish a transcript alongside podcasts and recorded webinars: it helps people in noisy rooms and open-plan offices, and it gives search engines and AI assistants something to read.

How OlDevs helps

OlDevs has been building software in Vancouver since 2014, and we hold every build to WCAG 2.2 AA rather than treating accessibility as a later phase. On a typical engagement that means a review of your current templates, a prioritised fix list you can ship in sprints, and accessibility checks folded into the front-end work so the same faults do not come back next quarter. You get one accountable team, a working demo every week, and full ownership of all code, designs and accounts, which you can read more about in how we work.

If you would like a second pair of eyes on your site, or help turning the backlog from your keyboard pass into shipped work, request a quote. We reply to every enquiry within one business day, in English or French.