Validation and accessibility

A valid page is not automatically an accessible page, and an accessible page does not have to be perfectly valid. But the two overlap more than most people expect, and the overlap is exactly where the cheapest accessibility wins are found. If you are going to run a validator anyway, you may as well know which of its messages are also barriers for real users.

Why structure matters more to assistive technology

A sighted visitor reads a page by scanning it. Size, position, colour and whitespace tell them what is a heading, what is a menu and what is the main content, regardless of what the markup says underneath. A screen reader has none of that. It builds its entire picture from the document tree: the heading levels, the landmarks, the labels, the order of elements.

Which means that markup errors a browser papers over silently can become navigation errors for somebody else. An unclosed element that shifts half your content inside the navigation region does not change what a sighted visitor sees. It changes what a screen reader announces.

Validation errors that are also barriers

Missing alt attributes

The validator reports the missing attribute. The person using a screen reader hears the file name read out, character by character, or nothing at all. The fix is not to fill every alt with the same word: an image that carries information gets a description of that information, an image that is pure decoration gets alt="" so it is skipped cleanly.

<img src="sales-2026.png" alt="Sales by quarter, peaking in Q3">
<img src="divider.svg" alt="">

A form control with no label

A field with only a placeholder validates in most cases and is a genuine problem: the placeholder disappears as soon as typing starts, and many screen readers do not announce it as a label at all. Connect a real label to the field, either by wrapping it or with matching identifiers.

<input type="email" placeholder="Your email">

<label for="email">Your email</label>
<input type="email" id="email" name="email">

Duplicate identifiers

A validation error, and the reason a label can end up pointing at the wrong field. Clicking the label then focuses something unexpected, which is confusing for everyone and disorienting for a keyboard user.

A missing language attribute

One line in the html tag, and without it a screen reader may read your English text using the pronunciation rules of another language. The result ranges from odd to incomprehensible.

Nesting that breaks tab order

Interactive elements inside interactive elements, a button within a link for instance, are invalid and produce unpredictable keyboard behaviour. The focus order stops matching the visual order, and a keyboard user loses their place.

What a validator will never catch

This is the important half of the page. Automated checking finds perhaps a third of accessibility problems, and validation alone finds fewer. Everything below passes validation and fails people.

The elements that do the work for you

Most accessibility problems are solved by choosing the right element rather than adding attributes to the wrong one. A <button> is focusable, announced as a button, and activated by the space bar and the enter key, all for free. A div with a click handler has none of that and needs a role, a tabindex and two keyboard listeners to catch up, which is three opportunities to get it wrong.

<div class="btn" onclick="submit()">Send</div>

<button type="button" onclick="submit()">Send</button>

The same logic applies to <nav>, <main>, <header> and <footer>, which let a screen reader jump straight to a region, and to <table> with proper header cells, which lets it announce the column a value belongs to.

A practical sequence

Start with validation, because it is automatic and it clears the structural errors that make everything else harder to diagnose. Run our site wide validator, fix what comes back using the common errors reference, then move on to the manual checks.

The manual pass is shorter than it sounds. Navigate one page with the keyboard alone and confirm you can reach every control and see where the focus is. Zoom the text to two hundred percent and check nothing overlaps or disappears. Read your alt texts and your link labels out of context. Run a contrast check on your main text and button colours. That is an hour for a small site, and it finds the problems no tool reports.

References

The Web Content Accessibility Guidelines are published by the W3C Web Accessibility Initiative, which also maintains practical tutorials on forms, images and tables that are far more readable than the guidelines themselves. Element by element documentation is on MDN Web Docs.

For the relationship between markup quality and search visibility, see HTML validation and SEO.