Finding reference

Focus management issue

Retained automated accessibility evidence showed focus movement, modal, overlay, dynamic-view, or keyboard-focus signals that may require focus-management review. Review the evidence context, methodology, common causes, and reviewer questions for this CertScore finding.

Selected finding

Focus management issue

MediumGood evidenceDirect observationAccessibilityFormal top-finding density pending calibration

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 focus movement, modal, overlay, dynamic-view, or keyboard-focus signals that may require focus-management review.

Why this matters

This observation can help reviewers decide whether the site behavior deserves deeper privacy, accessibility, consent, or consumer-protection review in context.

Detection methodology

CertScore retains representative automated accessibility evidence for focus movement, focus containment, focus restoration, dynamic views, modals, overlays, menus, consent prompts, and keyboard-focus behavior where available. The finding is surfaced when retained evidence indicates focus may move unpredictably, become trapped, fail to enter or leave an active region, or be obscured during an interaction state. CertScore treats automated focus-management evidence as a review signal. The scanner does not infer full WCAG conformance or non-conformance from a single automated result. Reviewers should confirm keyboard-only operation, screen-reader context, modal lifecycle, focus restoration, visible focus, background inertness, and user-triggered states.

Confidence semantics: Good when representative automated focus-management evidence includes rule ID or signal type, selector or element reference, page context, and interaction-state detail; stronger when retained evidence includes modal lifecycle, focus restoration, focus containment, background inertness, repeated components, or enough detail for manual keyboard replay. Manual review is still needed for assistive-technology behavior, user impact, and remediation quality.

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

Minimum to surface

  • Automated focus-management or keyboard-focus evidence with selector, page, and interaction context.

High confidence requires

  • Open/close or dynamic-state context.
  • Focus target or trap context.
  • Affected component role.

Top ranking requires

  • Modal, overlay, consent prompt, checkout, login, or primary navigation flow impact.

Demote or suppress when

  • Generic focus style issue.
  • Selector only.
  • No dynamic interaction state.
  • Decorative or hidden element.

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

Example evidence

Focus management example

  • rule=focus-management
  • artifact=focus_001
  • role=finding_supporting_artifact
  • url=https://example.com/app
  • selector=[data-example-component="dialog"]
  • impact=serious
  • wcag_refs=2.4.3 Focus Order; 2.4.7 Focus Visible; 4.1.2 Name, Role, Value
  • element_type=modal_or_overlay
  • interaction_state=open [manual_review_recommended]
  • detected_signal=focus_not_moved_or_restored
  • review_caveat=manual review should confirm focus lifecycle, background inertness, keyboard trap risk, and screen-reader context

Review context

  • component=dialog_or_drawer
  • states_to_review=open, close, escape, tab, shift_tab, route_change, validation_error
  • possible_source=component_focus_lifecycle
  • manual_keyboard_review_needed=true

What should not count by itself

  • selector=.modal [insufficient_without_interaction_state]
  • focus_outline_removed [audit_only_without_user_path_context]
  • component_name=Dialog [audit_only_without_focus_artifact]
  • visual_claim [requires_keyboard_review]
View redacted sample JSON
Redacted sample JSON
{
  "findingId": "focus_management_issue",
  "label": "Focus management issue",
  "category": "Accessibility",
  "criticality": "medium",
  "evidenceConfidence": "good",
  "directVsInferred": "direct_observation",
  "evidence": {
    "summary": "Retained automated accessibility evidence showed focus movement, modal, overlay, dynamic-view, or keyboard-focus signals that may require focus-management review.",
    "examples": [
      {
        "title": "Focus management example",
        "lines": [
          "rule=focus-management",
          "artifact=focus_001",
          "role=finding_supporting_artifact",
          "url=https://example.com/app",
          "selector=[data-example-component=\"dialog\"]",
          "impact=serious",
          "wcag_refs=2.4.3 Focus Order; 2.4.7 Focus Visible; 4.1.2 Name, Role, Value",
          "element_type=modal_or_overlay",
          "interaction_state=open [manual_review_recommended]",
          "detected_signal=focus_not_moved_or_restored",
          "review_caveat=manual review should confirm focus lifecycle, background inertness, keyboard trap risk, and screen-reader context"
        ]
      },
      {
        "title": "Review context",
        "lines": [
          "component=dialog_or_drawer",
          "states_to_review=open, close, escape, tab, shift_tab, route_change, validation_error",
          "possible_source=component_focus_lifecycle",
          "manual_keyboard_review_needed=true"
        ]
      },
      {
        "title": "What should not count by itself",
        "lines": [
          "selector=.modal [insufficient_without_interaction_state]",
          "focus_outline_removed [audit_only_without_user_path_context]",
          "component_name=Dialog [audit_only_without_focus_artifact]",
          "visual_claim [requires_keyboard_review]"
        ]
      }
    ]
  }
}

Regulatory review context

Accessibility: focus management and keyboard context

Retained automated accessibility evidence showed focus movement, focus containment, focus restoration, dynamic-view, modal, overlay, or keyboard-focus signals that may be relevant to WCAG-oriented accessibility review. Applicability depends on the affected component, interaction state, keyboard path, focus behavior, organization type, jurisdiction, and manual accessibility review.

WCAG 2.1.2 No Keyboard TrapWCAG 2.4.3 Focus OrderWCAG 2.4.7 Focus VisibleWCAG 2.4.11 Focus Not ObscuredADA Title II web/mobile accessibility reviewADA Title III public accommodation accessibility reviewMore context in reference notes
View applicability notes

Legal and regulatory frameworks

  • 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 movement does not preserve meaning or operability when dialogs, overlays, dynamic content, or route changes occur.
  • 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.

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, component role, focus lifecycle, focus visibility, focus order, keyboard trap risk, interaction state, page context, organization type, jurisdiction, and manual accessibility findings.

Evidence standard

Strong

  • Representative automated focus-management evidence includes rule ID, affected selector or element reference, page URL, impact label, and interaction-state context.
  • Retained evidence gives enough context to review focus movement, containment, restoration, visibility, background inertness, or active surface behavior.
  • Evidence indicates the affected element or component is meaningful and user-operable, such as a modal, menu, overlay, consent prompt, form step, or dynamic route change.
  • Repeated examples across components, templates, modals, menus, consent prompts, or responsive states may strengthen confidence when retained.
  • Strong evidence does not replace manual keyboard and assistive-technology review for user impact and remediation quality.

Good

  • Representative focus-management evidence includes selector or element reference, page URL, impact label, and enough interaction detail for reviewer inspection.
  • The retained example is enough for a reviewer to replay the focus behavior manually.
  • The evidence is likely a focus-management issue, but focus lifecycle, screen-reader context, dynamic states, and user impact may require manual review.

Audit-only

  • Contextual focus signals exist, but retained evidence lacks enough detail to confirm the affected component, state, or focus path.
  • A modal, menu, overlay, or consent prompt pattern appears suspicious, but no retained automated artifact identifies the focus behavior.
  • 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 focus-related evidence.
  • Generic custom component signal without retained affected element and interaction state.
  • 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

  • Modal, menu, drawer, or consent-prompt components do not move focus into the active surface when opened.
  • Focus is not restored to the triggering control when a dynamic view closes.
  • Background page content remains reachable while an overlay is active.
  • Keyboard focus is hidden, clipped, or obscured by sticky headers, dialogs, or transitions.
  • Dynamic route changes, validation errors, or multi-step forms do not announce or focus the new context.

Recommended review questions

  • Which selector, component, page, and interaction state triggered the focus-management evidence?
  • Is the affected surface a modal, overlay, menu, drawer, consent prompt, dynamic route change, validation message, or multi-step form?
  • Where should focus move when the surface opens, updates, or closes?
  • Is focus visible, logical, and not obscured across default, open, close, error, expanded, collapsed, and responsive states?
  • Can keyboard users enter the active region, operate controls, and return to the triggering context?
  • Is background page content removed from the tab order while modal or blocking content is active?
  • Could focus become trapped, lost, skipped, or moved to an unexpected location?
  • Is the issue isolated, or repeated across components, templates, dialogs, menus, consent surfaces, or responsive navigation?
  • Should manual keyboard and assistive-technology review confirm focus lifecycle, announcements, 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 focus checks can identify many focus-management risks, but they may not fully test every keyboard path, assistive-technology announcement, modal lifecycle, or user-triggered state.
  • Automated evidence may miss or misread dynamic content, shadow DOM, iframes, responsive navigation, animation timing, and authenticated flows.
  • Manual review is needed to confirm focus order, focus restoration, background inertness, keyboard trapping, visible focus, user impact, and remediation quality.
  • Remediation should be verified across open, close, escape, tab, shift-tab, route-change, validation-error, and responsive states where relevant.
  • CertScore retains representative evidence for review and may not list every repeated instance across a component library or template.
  • 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.