UX & Software Ergonomics
Keyboard accessibility and focus management are interaction sequences, not static markup checks. A technical examination defines relevant tasks, follows the actual keyboard path, inspects accessible semantics and records dynamic focus changes in the concrete browser and component state.
Short answer
Define the task and relevant components, reproduce the keyboard sequence, check focus order and visibility, inspect role, accessible name and state, and test focus changes when dialogs or dynamic content appear. A passed keyboard path is not a complete accessibility conclusion.
WCAG and WAI-ARIA references are particularly relevant to web content and web applications. The conclusion remains limited to the tested technology, components, browser or platform and interaction paths.
1. Define scope and concrete keyboard paths
Start with relevant user tasks rather than random tabbing. Identify the controls that must be reached and activated, the browser or platform environment and the product state.
Distinguish native HTML controls from custom widgets. Native elements usually provide browser keyboard behaviour, while ARIA-based components often require explicit interaction logic that must be examined in context.
The examination records the concrete task, user group, system version, device or input method and the selected assessment criterion before interpreting the result. An observation on one path is not silently generalised to all users, components or product states. Technical and ergonomic findings are kept separate from a legal conformity assessment, and untested contexts remain outside the conclusion.
2. Reproduce keyboard operation and order
Test whether every required function can be reached and triggered without pointer or touch. Tab and Shift+Tab normally move between components, while composite widgets can use additional keys defined by common authoring patterns.
A component can technically receive focus yet still create an unusable order. Compare focus order with document and reading order and note artificial positive tabindex values or skipped controls.
The examination records the concrete task, user group, system version, device or input method and the selected assessment criterion before interpreting the result. An observation on one path is not silently generalised to all users, components or product states. Technical and ergonomic findings are kept separate from a legal conformity assessment, and untested contexts remain outside the conclusion.
3. Check visible and unobscured focus
Users need to identify which element currently holds keyboard focus. Observe the indicator throughout the path and whether overlays, sticky regions or scroll position hide it.
WCAG 2.2 includes Focus Visible and related focus criteria. A static screenshot is insufficient because focus can become obscured only after scrolling, opening a dialog or inserting dynamic content.
The examination records the concrete task, user group, system version, device or input method and the selected assessment criterion before interpreting the result. An observation on one path is not silently generalised to all users, components or product states. Technical and ergonomic findings are kept separate from a legal conformity assessment, and untested contexts remain outside the conclusion.
4. Inspect role, accessible name and semantic state
Visual appearance and accessible semantics can differ. A control that looks like a button may have the wrong role, no accessible name or a state that is not updated for assistive technology.
Inspect role, name and states such as selected, expanded, disabled or invalid together with the actual behaviour. Additional ARIA attributes do not compensate for broken keyboard logic.
The examination records the concrete task, user group, system version, device or input method and the selected assessment criterion before interpreting the result. An observation on one path is not silently generalised to all users, components or product states. Technical and ergonomic findings are kept separate from a legal conformity assessment, and untested contexts remain outside the conclusion.
5. Examine dynamic focus movement and loss
Dialogs, menus, deleted list items and asynchronous updates can move or destroy focus. Test opening, operation and closing as a complete sequence rather than checking only the initial state.
After a dialog closes, returning focus to a meaningful location can be necessary for orientation. If a focused node is removed, record where focus moves and whether the user can continue predictably.
The examination records the concrete task, user group, system version, device or input method and the selected assessment criterion before interpreting the result. An observation on one path is not silently generalised to all users, components or product states. Technical and ergonomic findings are kept separate from a legal conformity assessment, and untested contexts remain outside the conclusion.
6. Limit the statement to platform and scope
State which browser, platform, components and paths were examined. Native desktop or mobile applications may use other platform mechanisms and standards.
Passing keyboard and focus checks does not establish complete accessibility. Contrast, alternatives, language, zoom and other criteria can remain outside the chosen scope and should not be implied by the result.
The examination records the concrete task, user group, system version, device or input method and the selected assessment criterion before interpreting the result. An observation on one path is not silently generalised to all users, components or product states. Technical and ergonomic findings are kept separate from a legal conformity assessment, and untested contexts remain outside the conclusion.
Examination checklist
- Are the relevant task paths defined?
- Can every required function be reached and activated by keyboard?
- Is focus order predictable and documented?
- Is focus visible and not unexpectedly obscured?
- Do role, accessible name and state match actual behaviour?
- Are dialog and dynamic focus transitions tested?
- Is the conclusion limited to the tested components and platform?
Constructed example
A modal dialog can be opened from the keyboard and all fields are reachable. When it closes, however, focus is lost to the document body rather than returning to the triggering control. The report records the successful in-dialog operation and the separate focus-management defect without extrapolating to unrelated components.
The example is entirely constructed and does not describe a real engagement, client matter or historical case.
Sources and technical basis
- Web accessibility standardW3C — Web Content Accessibility Guidelines (WCAG) 2.2. Testable accessibility success criteria for web content. Open source.
- WAI-ARIA practiceW3C WAI — Developing a Keyboard Interface. Authoring-practice guidance for predictable keyboard and focus behaviour. Open source.
- WCAG 2.2 guidanceW3C WAI — Understanding SC 2.4.7 Focus Visible. Technical explanation of visible keyboard focus. Open source.
- Methodological basisSources & Methodology documents source hierarchy, counter-hypothesis control and statement boundaries for the English knowledge base.
Further reading
Critical review and methodological limitation
Keyboard and focus findings depend on the tested browser, component implementation and state sequence. Dynamic behaviour can expose defects that are invisible in static DOM inspection.
Semantic correctness and operability should be examined together. A technically valid ARIA attribute is not sufficient when the corresponding keyboard interaction, focus behaviour or state transition does not match the asserted semantics.
Translation and methodological scope
This English article is based on the reviewed German V1 source article. The translation preserves the technical meaning, methodological distinctions, source status and stated limitations. It does not strengthen technical findings into legal conclusions and does not treat technical references as proof of compliance or suitability for a specific system.
Author's technical literature and publications
The following works provide additional technical and methodological context. They do not replace required primary sources, standards, manufacturer documentation or other independent specialist sources. Unpublished manuscripts, drafts and teaching materials are deliberately not presented here as public sources.
UX, Software Ergonomics & Accessibility
Technical and methodological examination of usability, context of use, interaction quality and accessible operation.
Explore this assessment service