What to know
Test a website with the keyboard by navigating links, opening menus, using forms and closing dialogs without a mouse. Check visible focus, logical movement and a reliable way to escape overlays. A strong visual design should still support these everyday tasks.
Put the mouse aside. Open your website and press Tab.
If the focus indicator disappears, the menu won't open or a dialog captures you without an exit, you've learned something important about the implementation. Keyboard testing is one of the quickest ways to discover whether a polished interface is also a robust interface.
Accessible interaction is a named part of Web Dev Awards' judging criteria. It deserves practical attention well before a site is submitted for recognition.
Start with the page's ordinary journey
Move from the logo to navigation, the main content and the primary action. The focus order should follow a sensible reading and interaction sequence. Visual layout can be complex, but keyboard navigation should not jump unpredictably between unrelated parts of the page.
Check that interactive elements are actually operable with the keyboard. A styled div that responds to clicks may not behave like a button, and adding tabindex alone rarely solves the deeper problem.
Focus needs to remain visible
People need to know which element will respond if they press Enter or Space. Removing focus outlines to make a design feel cleaner can make a site impossible to operate confidently.
Custom focus styles are fine when they remain visible against the surrounding interface. Test them over images, dark panels, hover states and modals, not just on a white background.
Menus, popovers and dialogs
Menus should expose a clear opening action, predictable focus movement and a reliable close behaviour. Dialogs need particular care: focus should move into the relevant content, avoid escaping to unavailable controls behind it and return to a sensible place when the dialog closes.
The WAI-ARIA Authoring Practices Guide includes patterns for common interactive components. The patterns aren't a substitute for testing with people, but they are valuable implementation references.
Forms: errors are part of the interface
Submit an empty form. Does it tell you what went wrong? Are error messages associated with the relevant fields? Can you find the problem and correct it without having to guess?
A form that looks beautiful before submission but becomes confusing after a failed validation is unfinished. Technical craft includes recovery paths and feedback states.
Don't forget reduced motion and device differences
Keyboard testing is one piece of accessibility. Consider text resizing, reduced-motion settings, touchscreen input and screen-reader structure as well. The WCAG overview provides a wider framework for evaluating access.
An automatic checker can detect some issues. It cannot reliably decide whether a flow is understandable or whether a complex interface behaves naturally.
A 10-minute pre-submission exercise
- Refresh the page and navigate without touching the mouse.
- Open every top-level navigation item.
- Complete the primary action, including an error path.
- Open and close any modal or overlay.
- Check the visible focus indicator on light and dark areas.
- Repeat on at least one important interior page.
This is not an official award scoring checklist. It is a useful developer's rehearsal before formal review. In the Web Dev Awards process, accessible behaviour sits alongside performance, implementation quality and creative development.
Award recognition should never depend solely on how impressive an interface looks when everything works. The difficult states show whether it was engineered for real people.