Accessible website: the 10 mistakes I find most often in audits, and how to fix them in code

Lists of the "most common accessibility mistakes" all look alike: contrast, alt text, labels. They are right, but they describe symptoms. In the audits I run, the mistakes that really block users are almost always in interactive components and in how the code communicates state and structure to assistive technology. Here are the ten I find most often, with the WCAG criterion involved and the fix.

1. Interactive elements that are not interactive elements

divs and spans with a click handler instead of button and a. They do not receive focus, do not respond to Enter and Space, have no role. Criteria 2.1.1 and 4.1.2. The fix is not adding tabindex and role="button", but using the native element, which brings all the correct behaviour with it.

2. ARIA used as decoration

aria-label on elements that already have different visible text, role="menu" on ordinary navigation, aria-hidden="true" on content that can receive focus. Wrong ARIA is worse than no ARIA: it communicates false information. Rule of thumb: semantic HTML first, ARIA only for what HTML cannot express.

3. Modals without focus management

On opening, focus stays under the modal, Tab escapes to the page, Esc does not close it, and on closing focus is lost at the top of the document. Criteria 2.4.3 and 2.1.2. Today the dialog element with showModal() solves most of this natively: it makes the rest of the page inert and handles Esc. What remains is returning focus to the element that opened it.

4. Invisible or obscured focus

outline: none with no replacement, or a visible focus hidden under a sticky header or cookie banner. Criteria 2.4.7 and 2.4.11. Use :focus-visible with a clear, consistent style across all components, and scroll-margin-top equal to the sticky header's height.

5. Component contrast, not just text

Text contrast is almost always checked. The contrast of field borders, text-less icons, state indicators and focus rings almost never. Criterion 1.4.11, 3:1 threshold. It is the most frequent mistake in minimalist designs with light grey fields on white.

6. Forms: labels, instructions and errors

Placeholders used as labels (they disappear while typing), errors signalled only in red, messages not linked to the field. Criteria 1.3.1, 3.3.1, 3.3.2. Every field has an associated label, instructions are linked with aria-describedby, the error is textual, linked to the field and announced, and autocomplete is set on personal data fields.

7. Dynamic content not announced

Updated search results, a changing cart, a confirmation after submitting: a screen reader user does not notice. Criterion 4.1.3. You need an aria-live region (or role="status") present in the DOM from the start, into which the message is inserted. Added on the fly, it often is not read.

8. Heading structure chosen for looks

An h4 because "it is smaller", skipped levels, bold text instead of a heading. Anyone navigating by headings with a screen reader gets a wrong map. Criterion 1.3.1. The hierarchy follows the content structure; appearance is handled in CSS.

9. Mechanical alt text

Images whose alt is the file name, decorative images described, informative images (charts, diagrams) with a generic alt. Criterion 1.1.1. Decorative ones get alt="", informative ones describe the information, not the appearance. In a CMS the alt field should be mandatory where needed.

10. Motion and animation without an alternative

Auto-playing carousels without pause, reveal animations on everything, parallax effects. Criteria 2.2.2 and 2.3.3. Carousels have pause controls; animations respect the prefers-reduced-motion preference and are reduced or switched off.

Fix it in the component, not the page

Almost all these mistakes repeat identically on every page, because they come from a component. Fixing them page by page never ends; fixing them in the component removes them everywhere at once. It is also why a coherent component system makes accessibility much cheaper to maintain. The regulatory picture is in Web accessibility: what the rules require.

A quick check in one hour

Before a full audit, this protocol gives a realistic picture:

1. Keyboard only on the home page, an inner page and the main form: can you reach everything? Is focus always visible? Do modals close with Esc?
2. Zoom to 200% and 400%: does content reflow without horizontal scrolling or clipped text?
3. Automated scan with axe or Lighthouse on the main templates, in both themes if the site has more than one.
4. Navigating by headings with a screen reader: does the structure tell the story of the page?
5. Submitting the form with errors: are errors announced, textual and linked to fields?
6. Reduced motion switched on in the system: do the animations stop?

If problems show up on three of these points within an hour, the site needs work on its components, not scattered fixes.

My take

When I build a site I start here: native elements, focus states designed together with everything else, animations that switch off for anyone who asked for less motion. On this site, for example, all reveal animations and moving scenes respect prefers-reduced-motion, and the light and dark themes are built on colour variables, so contrast is checked in a single place.

The problem with sites made of builders and plugins from different sources is that each component brings its own mistakes, and you do not control the code to fix them. There, accessibility becomes a fight against the tools rather than a property of the site.

Why work with me

I have been programming since 1999, delivered more than 300 projects and work as an external developer with about 30 agencies, from Rome and remotely. I run WCAG audits with manual keyboard and screen reader testing, and fix mistakes in the components, where they start.

If you want to know which of these mistakes your site has, get in touch: in a call of about 20 minutes we choose where to start. The service is in Web accessibility: WCAG audit and fixes.