A website should not require a mouse to reach its services or complete an inquiry. Keyboard navigation is part of the interaction design, especially when menus, overlays, and custom controls are involved.
Related service: Website and ecommerce development- 01Enter the page
- 02Reach navigation
- 03Open and close controls
- 04Complete the task
- 05Return to a sensible location
SECTION 01
Include interaction states in the agency brief
List the menus, accordions, dialogs, search controls, forms, and carousels the website will use. Ask what happens when each receives keyboard focus and how the visitor activates or closes it. Keep the order aligned with the meaningful reading sequence. A visually rearranged layout can become confusing if focus jumps around unrelated content.
W3C's menus guidance covers appropriate structure and keyboard operation. Its modal-dialog pattern explains focus behavior when a dialog opens and closes. These are practical references for implementation and testing, not a certification that the whole site is accessible. Prefer established controls unless a custom interaction solves a real requirement and its behavior can be maintained.
SECTION 02
Illustrative example: a service selector opens an overlay
Imagine a visitor opens a service selector using the keyboard. The overlay appears, but focus stays behind it and the next tab moves to a hidden footer link. The visitor cannot tell where they are. A mouse-only demonstration might never reveal the failure.
A better implementation moves focus into the appropriate part of the overlay, provides an understandable close control, and returns focus sensibly after dismissal. If the visitor chooses a service, the next page should have a clear heading and usable navigation. This hypothetical example shows why visual state and interaction state must be designed together rather than added separately at the end.
SECTION 03
Make the acceptance task concrete
Ask the agency to demonstrate finding a service, opening any relevant panel, submitting a corrected form, and returning to the main content without using a pointer. Check visible focus against both light and dark backgrounds. Test sticky headers and overlays that might cover the focused control. Include a way to skip repeated navigation where appropriate.
Record the supported interaction patterns and unresolved issues, then retest them after design changes. An automated scan can find some problems but cannot prove that the whole journey is understandable. The tradeoff may favor a simpler menu or static list over a complex carousel. Hand over component rules so later content additions do not introduce hidden links, unexpected focus order, or controls that only respond to hover.
SECTION 04
Frequently asked questions
Is keyboard access only for screen-reader users?
No. People use keyboards for many reasons, including mobility needs and personal preference.
Can we rely on an automated accessibility score?
No. Use automated checks alongside hands-on task testing and appropriate accessibility review.
Should every popup use a modal dialog?
No. Choose the interaction that fits the task; a simple disclosure or normal page may be easier to use.
PRIMARY REFERENCES
Sources and further reading
These references cover the standards, platforms, or published prices discussed in the guide. Worked examples and checklists are our editorial guidance.
- Menus TutorialW3C WAI
- Modal Dialog PatternW3C WAI
EDITORIAL METHOD
About this guide
We use AI to assist with drafting and editing. Catapult AI Work is responsible for the published content. Examples illustrate possible approaches; they are not client case studies unless identified as such.
Budget examples are not Catapult package prices. Check linked provider pages for current fees and plan limits before making a purchase.
Read the editorial policy