Accessibility problems are not evenly distributed across a website. They concentrate, and they concentrate hardest in exactly the two places where a visitor most needs to succeed: navigation, which is how people get anywhere at all, and forms, which is how they actually do anything, book, enquire, order, register, pay. A site can be reasonably accessible everywhere else and still be unusable if these two fail. Accessible website design gives them particular attention for that reason. Here is what they require.
Why these two matter most
Navigation and forms carry disproportionate weight because they are gateways rather than destinations. If a visitor cannot navigate, nothing else on the site is reachable, however well built it is. If a visitor cannot complete a form, they cannot become a customer, which turns an accessibility failure directly into a lost enquiry or sale. Everything else on a site can be imperfect and still leave a visitor able to get what they came for; these two cannot.
They are also, unhelpfully, the most complex interactive parts of most sites, which is precisely why they break. Menus, filters, multi-step forms, validation, and dynamic behaviour all introduce the kind of complexity that accessibility problems hide inside, while a simple block of text rarely goes wrong. There is a commercial dimension to this that is easy to overlook. Accessibility is often discussed as an ethical and legal matter, which it is, but navigation and form failures are also straightforwardly expensive: they turn people who wanted to become customers into people who could not. A business rarely hears about it, because someone who cannot complete a booking form does not write in to explain why, they simply go somewhere that works.
What accessible navigation requires
Navigation that works for everyone rests on a few things.
Complete keyboard operability. Every navigation element must be reachable and usable without a mouse, in a sensible order, including dropdown and nested menus. Menus that only open on hover are a classic failure, since a keyboard user never hovers.
A visible focus indicator. Someone navigating by keyboard needs to see where they currently are. A focus indicator that has been removed for aesthetic reasons, which is distressingly common, leaves them moving blind through the page.
No keyboard traps. It must always be possible to move out of a component as well as into it. Anything a keyboard user can enter but not leave without a mouse strands them entirely.
Descriptive wording. Navigation text should describe where it goes, because screen reader users often review navigation elements out of their surrounding context, where vague wording conveys nothing.
A way to skip repetition. A mechanism to jump past a long, repeated navigation block straight to the main content saves keyboard and screen reader users from traversing the same items on every page.
Predictable, consistent structure. Navigation that appears in the same place and behaves the same way throughout lets people build a mental model of the site instead of relearning it on each page.
Beyond the main menu
It is worth remembering that navigation means more than the header menu. Site search, filters on a listing page, pagination, breadcrumbs, and the movement between steps in a process are all navigation, and each needs the same treatment: reachable by keyboard, clearly focused, sensibly ordered, and described in a way that makes sense without surrounding visual context.
Filters deserve particular mention, because they are common on any site with a catalogue and are frequently built as custom controls that look simple and behave badly. When a filter updates results without a page reload, a visitor using a screen reader may have no idea anything happened unless the change is announced, so they are left with an apparently unchanged page and no feedback. Making dynamic changes perceptible, rather than only visible, is one of the more commonly missed requirements in modern interfaces, and one of the more disorienting to encounter.
What accessible forms require
Forms are where the most damaging failures happen, and they need care in several places.
Every field properly labelled. Each input needs a label that is programmatically associated with it, so assistive technology announces what the field is for. Placeholder text alone is not a label: it typically disappears on typing and is not reliably announced.
Clear grouping. Related fields, such as a set of options or an address block, should be grouped and identified so their relationship is conveyed rather than presented as a stream of unrelated inputs.
Instructions before they are needed. Requirements such as accepted formats belong with the field, in text, before someone tries to complete it, not only in an error afterward.
Errors identified in text, and helpfully. When something goes wrong, the error must be conveyed in text rather than by colour alone, must identify which field it concerns, and should say how to fix it. Colour alone excludes anyone who cannot distinguish it, and a message like "invalid input" helps nobody. It is also worth surfacing errors in a way that does not require hunting: a summary at the top identifying what went wrong, alongside the individual field messages, saves a visitor from working through a long form to locate the problem.
Focus managed sensibly. After a failed submission, focus should be moved somewhere useful, so a screen reader user learns immediately that something went wrong rather than discovering it by chance.
Adequate targets and no unnecessary time limits. Controls should be large enough to use reliably, and where a time limit exists it should be adjustable, since not everyone can complete a form quickly.
The failures that recur
The same handful of problems appear again and again: labels replaced by placeholder text, focus indicators removed for visual tidiness, menus operable only by hover, errors signalled purely by turning a field red, custom-built controls that look like standard ones but do not behave like them for assistive technology, and keyboard focus that becomes invisible or trapped inside a component.
There is a common thread. Most of these arise from building custom interface elements that imitate the appearance of standard ones while discarding the behaviour that came with them. Standard elements are accessible by default because that behaviour is built in; a custom substitute has to reimplement all of it deliberately, and usually does not. Using standard elements where possible, and being rigorous when they genuinely have to be replaced, prevents a large share of accessibility problems before they exist. The same principle applies to the design stage. Many of these failures originate in a visual decision made without knowing its consequence, removing a focus indicator because it looked untidy, choosing a hover-only menu, signalling errors purely through colour, so the most effective prevention is for designers and developers to share an understanding of what these choices cost. Accessibility problems in navigation and forms are far more often the result of an uninformed decision than a deliberate one.
Testing what actually matters
Automated tools are useful here and will catch a meaningful set of these issues, missing labels among them, but the most important checks are the simple manual ones. Put the mouse aside and move through the site by keyboard alone: can you reach everything, see where you are, open and close every menu, complete and submit a form, and recover from an error? That single exercise surfaces more real problems in navigation and forms than any scan, and anyone can do it in a few minutes.
Testing with an actual screen reader, and where possible with people who genuinely rely on assistive technology, goes considerably further. But the keyboard test is the one no site should ship without: it is the single most revealing check in accessible website design, it costs nothing, and a site that fails it is failing at the two things visitors most need to do.
Where to go next
Navigation and forms are where accessibility succeeds or fails for most visitors. For the full picture, see our guide to website accessibility and how we approach web design, and read on into what ADA website compliance actually requires and accessibility for healthcare and booking websites.
Could you get through your own site's main navigation and complete its most important form using only a keyboard, seeing clearly where you were the whole way?