wcag-2.4.7-focus-visible.txt

Skip to content WCAG 2.2 Understanding Docs Informative explanations, not required to meet WCAG About WCAG Understanding Docs - All Understanding Docs - Guideline: Navigable - Previous SC: Headings and Labels - Next SC: Location Page Contents - In Brief - Success Criterion - Intent - Benefits - Examples - Related Resources - Techniques - Key Terms - Test Rules Understanding SC 2.4.7 Focus Visible (Level AA) In Brief Goal Users know which element has keyboard focus. What to do Ensure each item receiving focus has a visible indicator. Why it's important Without a focus indicator, sighted keyboard users cannot operate the page. Success Criterion (SC) Any keyboard operable user interface has a mode of operation where the keyboard focus indicator is visible. Intent The purpose of this success criterion is to help a person know which element has the keyboard focus. “Mode of operation” accounts for user agents which may not always show a focus indicator, or only show the focus indicator when the keyboard is used. User agents may optimize when the focus indicator is shown, such as only showing it when a keyboard is used. Authors are responsible for providing at least one mode of operation where the focus is visible. In most cases there is only one mode of operation so this success criterion applies. The focus indicator must not be time limited, when the keyboard focus is shown it must remain. Note There may be situations where mouse/pointer users could also benefit from having a visible focus indicator, even though they did not set focus to an element using the keyboard. As a best practice, consider still providing an explicit focus indicator for these cases. Note that a keyboard focus indicator can take different forms. New in WCAG 2.2: While Focus Visible does not specify what that form is, 2.4.13 Focus Appearance (Level AAA) provides guidance on creating a consistent, visible indicator. Benefits - This success criterion helps anyone who relies on the keyboard to operate the page, by letting them visually determine the component on which keyboard operations will interact at any point in time. - People with attention limitations, short term memory limitations, or limitations in executive processes benefit by being able to discover where the focus is located. Examples - When text fields receive focus, a vertical bar is displayed in the field, indicating that the user can insert text, OR all of the text is highlighted, indicating that the user can type over the text. - When a user interface control receives focus, a visible border is displayed around it. Related Resources Resources are for information purposes only, no endorsement implied. - Styling form controls with CSS, revisited Techniques Each numbered item in this section represents a technique or combination of techniques that the Accessibility Guidelines Working Group deems sufficient for meeting this success criterion. A technique may go beyond the minimum requirement of the criterion. There may be other ways of meeting the criterion not covered by these techniques. For information on using other techniques, see Understanding Techniques for WCAG Success Criteria , particularly the "Other Techniques" section. Sufficient Techniques - G149: Using user interface components that are highlighted by the user agent when they receive focus - C15: Using CSS to change the presentation of a user interface component when it receives focus - G165: Using the default focus indicator for the platform so that high visibility default focus indicators will carry over - G195: Using an author-supplied, visible focus indicator - C40: Creating a two-color focus indicator to ensure sufficient contrast with all components - C45: Using CSS :focus-visible to provide keyboard focus indication - SCR31: Using script to change the background color or border of the element with focus Failures The following are common mistakes that are considered failures of this success criterion by the Accessibility Guidelines Working Group. - F55: Failure of Success Criteria 2.1.1, 2.4.7, 2.4.13, and 3.2.1 due to using script to remove focus when focus is received - F78: Failure of Success Criterion 1.4.11, 2.4.7 and 2.4.13 due to styling element outlines and borders in a way that removes or renders non-visible the visual focus indicator Key Terms focus indicator pixels that are changed to visually indicate when a user interface component is in a focused state state dynamic property expressing characteristics of a user interface component that may change in response to user action or automated processes States do not affect the nature of the component, but represent data associated with the component or user interaction possibilities. Examples include focus, hover, select, press, check, visited/unvisited, and expand/collapse. user interface component a part of the content that is perceived by users as a single control for a distinct function Note 1 Multiple user interface components may be implemented as a single programmatic element. "Components" here is not tied to programming techniques, but rather to what the user perceives as separate controls. Note 2 User interface components include form elements and links as well as components generated by scripts. Note 3 What is meant by "component" or "user interface component" here is also sometimes called "user interface element". Example An applet has a "control" that can be used to move through content by line or page or random access. Since each of these would need to have a name and be settable independently, they would each be a "user interface component." Test Rules The following are Test Rules for certain aspects of this Success Criterion. It is not necessary to use these particular Test Rules to check for conformance with WCAG, but they are defined and approved test methods. For information on using Test Rules, see Understanding Test Rules for WCAG Success Criteria . - Element in sequential focus order has visible focus Back to Top Help improve this page Please share your ideas, suggestions, or comments via email to the publicly-archived list public-agwg-comments@w3.org or via GitHub Email Fork & Edit on GitHub New GitHub Issue Date: Updated 17 September 2025. View this page's revision history. Developed by Accessibility Guidelines Working Group (AG WG) Participants (Co-Chairs: Adam Page, Alastair Campbell, Rachael Bradley Montgomery. W3C Staff Contact: Kevin White). The content was developed as part of the WAI-Core projects funded by U.S. Federal funds. The user interface was designed by the Education and Outreach Working Group ( EOWG ) with contributions from Shadi Abou-Zahra, Steve Lee, and Shawn Lawton Henry as part of the WAI-Guide project, co-funded by the European Commission. W3C Web Accessibility Initiative (WAI) Strategies, standards, resources to make the Web accessible to people with disabilities - Get News in Email - LinkedIn - Mastodon - YouTube - Home - Contact - Site map - Support WAI - News - Accessibility statement - All Translations - Resources for roles Copyright © 2026 World Wide Web Consortium . W3C ® liability , trademark and permissive license rules apply unless otherwise noted. See Permission to Use WAI Material . -