Finding reference

Keyboard navigation accessibility issue

Retained automated accessibility evidence showed interactive elements, focus behavior, or keyboard-related signals that may require keyboard accessibility review. Review the evidence context, methodology, common causes, and reviewer questions for this CertScore finding.

Selected finding

Keyboard navigation accessibility issue

MediumGood evidenceDirect observationAccessibilitySeen on ~3% of scanned top sites

Benchmark frequency is directional market context only. It is not a compliance benchmark, legal conclusion, or severity score. Rare findings may be top-ranked only when retained evidence is strong; common findings may remain medium when evidence is automated or context-dependent. Rarity is not severity, and prevalence is not compliance risk.

Observed

Retained automated accessibility evidence showed interactive elements, focus behavior, or keyboard-related signals that may require keyboard accessibility review.

Why this matters

Keyboard access is essential for people who use keyboards, switch devices, voice input, screen readers, or other assistive technologies to navigate and operate web interfaces. For review teams, the signal can help identify custom controls, focus states, focus order, or interaction patterns that may need keyboard-operability review.

Detection methodology

CertScore retains representative automated accessibility evidence for keyboard-related checks, including the rule identifier, affected selector or element reference, page URL, impact label when available, and WCAG-oriented references. The finding is surfaced when retained evidence indicates that an interactive element, focus behavior, focus visibility, focus order, or custom control may require keyboard accessibility review. CertScore treats automated keyboard-navigation results as review signals. The scanner does not infer full WCAG conformance or non-conformance from a single automated rule result. Reviewers should consider whether the element can receive focus, whether it can be operated by keyboard, whether focus is visible and ordered logically, whether custom controls expose expected semantics, and whether user-triggered states, modals, menus, carousels, or overlays were included in the scan scope.

Confidence semantics: Good when representative automated keyboard-related evidence includes rule ID, selector or element reference, page context, impact label, and WCAG-oriented references; stronger when retained evidence also includes focus-state context, interaction-state context, repeated examples across components, or enough detail for manual keyboard-path verification. Manual review is still needed for keyboard operability, focus order, focus visibility, keyboard traps, and remediation quality.

Top-finding calibrationWhat must be retained to surface, top-rank, demote, or suppress this finding.

Minimum to surface

  • Automated keyboard/focus rule with selector, page, and WCAG reference.

High confidence requires

  • Keyboard path, focus, and interaction state context.

Top ranking requires

  • Trap.
  • Primary navigation blocked.
  • Form submit blocked.
  • Repeated component.

Demote or suppress when

  • Selector only.
  • Inactive, hidden, or decorative element.

These rules describe ranking calibration for already-projected findings. They do not create findings from raw signals.

Example evidence

Keyboard navigation example

  • rule=keyboard
  • artifact=keyboard_001
  • role=finding_supporting_artifact
  • url=https://example.com/navigation
  • selector=[data-example-component="nav-menu"] button[aria-expanded]
  • impact=serious
  • wcag_refs=2.1.1 Keyboard; 2.4.7 Focus Visible; 4.1.2 Name, Role, Value
  • element_type=custom_control
  • detected_signal=keyboard_or_focus_review_needed
  • interaction_state=collapsed [manual_review_recommended]
  • review_caveat=manual review should confirm keyboard operation, focus visibility, focus order, expanded/collapsed behavior, and escape/close behavior where relevant

Review context

  • component=nav_menu
  • possible_source=custom_control_or_focus_management
  • states_to_review=default, focus, expanded, collapsed, open, closed, modal, overlay
  • keyboard_paths_to_review=Tab, Shift+Tab, Enter, Space, Escape, Arrow keys where applicable
  • manual_keyboard_review_needed=true

What should not count by itself

  • selector=.nav-button [insufficient_without_rule_and_page_context]
  • tabindex_present [audit_only_without_keyboard_path_review]
  • custom_component=Menu [audit_only_without_affected_element]
  • focus_style_hidden [requires_focus_visibility_context_review]
View redacted sample JSON
Redacted sample JSON
{
  "findingId": "keyboard_navigation_accessibility_issue",
  "label": "Keyboard navigation accessibility issue",
  "category": "Accessibility",
  "criticality": "medium",
  "evidenceConfidence": "good",
  "directVsInferred": "direct_observation",
  "evidence": {
    "summary": "Retained automated accessibility evidence showed interactive elements, focus behavior, or keyboard-related signals that may require keyboard accessibility review.",
    "examples": [
      {
        "title": "Keyboard navigation example",
        "lines": [
          "rule=keyboard",
          "artifact=keyboard_001",
          "role=finding_supporting_artifact",
          "url=https://example.com/navigation",
          "selector=[data-example-component=\"nav-menu\"] button[aria-expanded]",
          "impact=serious",
          "wcag_refs=2.1.1 Keyboard; 2.4.7 Focus Visible; 4.1.2 Name, Role, Value",
          "element_type=custom_control",
          "detected_signal=keyboard_or_focus_review_needed",
          "interaction_state=collapsed [manual_review_recommended]",
          "review_caveat=manual review should confirm keyboard operation, focus visibility, focus order, expanded/collapsed behavior, and escape/close behavior where relevant"
        ]
      },
      {
        "title": "Review context",
        "lines": [
          "component=nav_menu",
          "possible_source=custom_control_or_focus_management",
          "states_to_review=default, focus, expanded, collapsed, open, closed, modal, overlay",
          "keyboard_paths_to_review=Tab, Shift+Tab, Enter, Space, Escape, Arrow keys where applicable",
          "manual_keyboard_review_needed=true"
        ]
      },
      {
        "title": "What should not count by itself",
        "lines": [
          "selector=.nav-button [insufficient_without_rule_and_page_context]",
          "tabindex_present [audit_only_without_keyboard_path_review]",
          "custom_component=Menu [audit_only_without_affected_element]",
          "focus_style_hidden [requires_focus_visibility_context_review]"
        ]
      }
    ]
  }
}

Regulatory review context

Accessibility: keyboard operability and focus

Retained automated accessibility evidence showed keyboard, focus, interaction, or custom-control signals that may be relevant to WCAG-oriented accessibility review. Applicability depends on the affected element, interaction state, keyboard path, focus behavior, component behavior, organization type, jurisdiction, and manual accessibility review.

WCAG 2.1.1 KeyboardWCAG 2.1.2 No Keyboard TrapWCAG 2.4.3 Focus OrderWCAG 2.4.7 Focus VisibleWCAG 2.4.11 Focus Not ObscuredWCAG 4.1.2 Name, Role, ValueMore context in reference notes
View applicability notes

Legal and regulatory frameworks

  • WCAG 2.1.1 Keyboard (A)Functionality cannot be operated through a keyboard interface.
  • WCAG 2.1.2 No Keyboard Trap (A)Keyboard focus can enter a component but cannot leave it using keyboard controls.
  • WCAG 2.4.3 Focus Order (A)Focus order does not preserve meaning or operability.
  • WCAG 2.4.7 Focus Visible (AA)Keyboard focus indicator is not visible or is visually suppressed.
  • WCAG 2.4.11 Focus Not Obscured (AA)Focused components are hidden or obscured by sticky headers, overlays, cookie banners, or modals.
  • WCAG 4.1.2 Name, Role, Value (A)Custom controls may require name, role, state, or value review to support keyboard and assistive-technology interaction.

Jurisdictional contexts

  • ADA Title II web/mobile accessibility reviewState or local government web content or mobile apps may be in scope depending on organization context, service context, and manual review.
  • ADA Title III public accommodation accessibility reviewA business open to the public provides goods, services, or communications through the website.
  • Section 508 ICT accessibility reviewFederal agency ICT, federal web content, or federal procurement/vendor review may be in scope depending on organization context, procurement context, and manual review.
  • EN 301 549 / EU accessibility reviewEU public-sector, procurement, Web Accessibility Directive, or European Accessibility Act service context may be in scope depending on organization context, service context, and manual review.
  • UK public-sector accessibility reviewUK public-sector website or mobile app may be in scope depending on organization context, service context, and manual review.

WCAG references are technical review references. Legal obligations and incorporated versions may vary by jurisdiction and organization type, including WCAG 2.0, 2.1, 2.2, EN 301 549, ADA Title II, Section 508, EU Web Accessibility Directive / European Accessibility Act, and UK public-sector accessibility rules. This finding does not determine legal status or WCAG conformance. Review the retained selector, element role, keyboard operability, focus visibility, focus order, interaction state, component behavior, page context, organization type, jurisdiction, and manual accessibility findings.

Evidence standard

Strong

  • Representative automated keyboard-related evidence includes rule ID, affected selector or element reference, page URL, impact label, and WCAG-oriented reference.
  • Retained evidence gives enough context to review whether the affected element is an interactive control, custom widget, menu, modal, carousel, form control, link, or focusable region.
  • Evidence indicates the affected element is meaningful and user-operable, not a decorative or inactive element.
  • Repeated examples across templates, components, menus, modals, custom controls, or responsive states may strengthen confidence when retained.
  • Strong evidence does not require full manual keyboard path replay unless that is explicitly retained; keyboard operability, traps, and focus order remain manual review considerations.

Good

  • Representative automated keyboard-related evidence includes rule ID, selector or element reference, page URL, impact label, and WCAG-oriented references.
  • The retained example is enough for a reviewer to locate the affected element and verify keyboard operability, focus visibility, or focus order manually.
  • The evidence is likely a keyboard-navigation issue, but interaction state, keyboard path, focus management, modal/menu behavior, and user-triggered states may require manual review.

Audit-only

  • Contextual keyboard or focus signals exist, but retained evidence lacks enough detail to confirm the affected interactive element, state, keyboard path, or user impact.
  • Custom control, menu, modal, carousel, overlay, or focusable element patterns appear suspicious, but no retained automated artifact identifies a specific affected element.
  • The issue may involve user-triggered states, authenticated flows, dynamic content, shadow DOM, canvas, iframes, or responsive navigation where automated evidence is incomplete.

Insufficient

  • Selector alone without rule ID, page context, or keyboard-related evidence.
  • Generic custom component or div-button signal without retained affected element and keyboard-related artifact.
  • Visual impression, screenshot, or user report without retained automated evidence or manual keyboard verification.
  • Treating decorative, inactive, hidden, or unreachable elements as finding-supporting evidence without context review.
  • Claims about WCAG status or legal status based only on automated evidence without manual context review.

Evidence levels explain how CertScore treats retained accessibility artifacts. They are not legal conclusions.

Common causes

  • Custom controls are built with non-semantic elements without full keyboard behavior.
  • Focus styles are removed, hidden, clipped, or too subtle.
  • Menus, modals, overlays, carousels, or accordions do not manage focus predictably.
  • Keyboard handlers support mouse clicks but not Enter, Space, Escape, or arrow-key behavior where expected.
  • Responsive navigation or user-triggered states are not tested with keyboard-only workflows.

Recommended review questions

  • Which selector, component, page, and interaction state triggered the keyboard-related evidence?
  • Is the affected element a native control, custom control, menu, modal, overlay, carousel, form field, link, or focusable region?
  • Can the element receive focus and be operated with the keyboard alone?
  • Is focus visible, logical, and not obscured across default, hover, focus, active, expanded, collapsed, open, closed, and disabled states?
  • Are expected keys supported, such as Tab, Shift+Tab, Enter, Space, Escape, and arrow keys where applicable?
  • Does focus move predictably into and out of menus, modals, overlays, carousels, and dynamic content?
  • Could there be a keyboard trap or unreachable control in user-triggered states not covered by the automated scan?
  • Is the issue isolated, or repeated across components, templates, responsive navigation, menus, or modals?
  • Should manual keyboard and assistive-technology review confirm operability, focus order, user impact, and remediation quality?

Limitations and cautions

  • This finding is an automated accessibility review signal, not a legal conclusion, certification, or determination of WCAG conformance or non-conformance.
  • Automated keyboard-related checks can identify many focus, semantics, and keyboard-risk signals, but they may not fully test keyboard paths, focus order, keyboard traps, modal behavior, menu behavior, carousel behavior, authenticated flows, or user-triggered states.
  • Automated evidence may miss or misread dynamic content, shadow DOM, iframes, canvas, responsive navigation, overlays, and script-driven focus management.
  • Automated evidence may not determine whether an element is fully operable by keyboard or whether the focus order is logical for users.
  • Manual keyboard review is needed to confirm operability, focus visibility, focus order, keyboard traps, expected key behavior, user impact, and remediation quality.
  • Remediation should be verified across default, focus, active, expanded, collapsed, open, closed, disabled, modal, overlay, and responsive states where relevant.
  • CertScore retains representative evidence for review and may not list every repeated instance across a template or component library.
  • Findings should be evaluated with implementation context and applicable accessibility requirements before operational or legal reliance.
  • Automated findings may contain errors and should be reviewed with the retained evidence.
  • Not detected means not observed in the scan scope; it is not proof of absence.
  • Findings are runtime evidence and public-surface observations for review, not legal conclusions.

Related reading

Reference notes

  • CertScore uses findings, evidence, signals, and observations consistently: signals are raw runtime or page-surface events, evidence is retained support, observations are interpreted evidence context, and findings are promoted review items.
  • Findings are runtime evidence and public-surface observations for review. Observed signals may surface possible concerns, but review is recommended before operational or legal reliance.
  • Finding reference content is reviewed periodically and updated when material guidance changes. CertScore monitors guidance families such as EDPB consent and ePrivacy materials, ICO cookie guidance, CNIL tracker recommendations, FTC privacy and dark-pattern materials, and relevant accessibility guidance where applicable.
  • Automated accessibility evidence can support WCAG-oriented review, but manual review is needed to confirm context, applicable success criterion, user impact, exception status, assistive-technology behavior, keyboard behavior, and remediation quality.
  • ADA Title II, ADA Title III, Section 508, EN 301 549, and UK public-sector accessibility contexts may be relevant depending on organization type, procurement context, jurisdiction, and manual review.
  • Prevalence labels use the Tranco top 1-2500 calibration set, an approximately 2,505-scan directional calibration set.