Please note that we will be conducting scheduled maintenance on October 16th, 2025 between 8:00pm EST and 9:00pm EST. During this time AMP will be temporarily unavailable.

  • Media Type Web > Focus Control
  • State Active
  • Advisory No

A well-defined (highly visible) visual indication of keyboard focus needs to be provided for each active element. This position on a screen where an action or keyboard input will take place is referred to as the "focus". Providing a visual indication of the focus allows someone who is viewing the screen to determine what action to take based on what element has focus. This is particularly necessary for keyboard-only users who do not use the mouse and cannot simply click to place focus where they think it should be. The user must rely on the visual indication of focus to determine where an action will occur or determine what keystrokes to perform to move focus to the desired field. If this focus is not indicated the user will be unclear as to where the current execution focus is located and may enter incorrect information, accidentally submit a form without knowledge of what occurred, or spend extra time trying to determine where the keyboard input focus is.

Compliant Example

<head> ...
<style type="text/css">
.aClass:hover, .aClass:active, .aClass:focus{
  outline-style:solid;
  outline-width:3px;
  outline-color:#bbb;
}
</style> ... </head>
...
<a class="aClass" href="http://www.ssbbartgroup.com"> SSB BART
Group</a>
...

Non-Compliant Example

<head> ...
<style type="text/css">
a {
  outline: none;
}
</style> ... </head>
...
<a href="http://www.ssbbartgroup.com"> SSB BART Group</a>
...

Developers should ensure that visible keyboard focus is provided to all elements. Typically the browser will provide keyboard focus using a dotted rectangle for all standard HTML elements such as input, select, textarea, anchor, and area. When scripting is used to set focus to other elements coupled with the tabIndex attribute or when the CSS outline property is set to none developers must ensure that visual focus is added by using color with border or other visual attributes.

Developers must avoid the use of the "outline:none" CSS property for anchors and other actionable elements. The "outline:none" declaration removes the default focus rectangle from focused elements within the browser. If any custom "outline" CSS properties are used, provide a visual (or highlighted) focus rectangle around the object when it is focused so it can be seen by sighted keyboard-only users or users with low vision. Style properties like "outline-style", "outline-color" and "outline-width" should provide good color contrast, width and styles that can be seen easily when the object has keyboard focus.

For all elements that receive keyboard focus, it is recommended but not required to ensure that the visual keyboard focus also have sufficient contrast between the focus rectangle and the background color of the element. A contrast checker can be used to verify the level of color contrast is sufficient. A recommended but not required ratio of 3:1 is generally seen as sufficient.

One method to provide a visual indication of visual focus is to use the same visual changes on an actionable item when the keyboard is focused on the item as when the mouse hovers over the item. This can be done via CSS and will allow visual focus with a very small amount of effort.

Organization Standards

  • § 508-1194.21 Software Applications and Operating Systems
    • (c) On-screen & programmatic indication of focus
  • § 508-1194.21 VHA Testing Checklist - Software Applications and Operating Systems
    • (c) On-screen & programmatic indication of focus
      • (c.2) Is keyboard focus indicated visually?
  • § 508-1194.22 Web Sites and Applications
    • (l) Ensure scripts are accessible
  • § 508-1194.31 Functional performance criteria
    • (b) Ensure access for low vision users
    • (f) Ensure users with mobility impairments can use application
  • 47 CFR 14. Advanced Communication Services
    • 47 CFR 14.21 Performance Objectives
      • (b) Accessible
        • (b)(1) Input, control, and mechanical functions shall be locatable, identifiable, and operable
          • (b)(1)(ii) Operable with low vision without relying on audio
          • (b)(1)(v) Operable with limited manual dexterity
  • Baseline Tests for Software & Web Accessibility (v2.0.2 2017)
    • 2. Focus (visible)
  • DHS - Section 508 Compliance Test Process for Application (v 4.0)
    • 1.1 Keyboard Access
      • 1.1 E. At any time, there is no visual indication of the current focus (loss of focus)
  • Section 508 and 255 (Revised 2017)
    • Chapter 3: Functional Performance Criteria
      • 302.2 With Limited Vision
      • 302.7 With Limited Manipulation
      • 302.8 With Limited Reach and Strength
  • WCAG 1.0 Priority 1
    • 08.1 Ensure programmatic elements such as scripts and applets are accessible
  • WCAG 1.0 Priority 2
    • 08.1 - Programmatic elements should be directly accessible
  • WCAG 2.0 Level AA
    • 2.4.7 Focus Visible

Other Mapped Standards

  • BITV 2.0 (Priority I)
    • 2.4.7 Sichtbarer Fokus
  • HHS HTML 508 Checklist (2019)
    • Section C: Keyboard Navigation
      • C2 When tabbing through the page, do all elements have a clear visual indication that they have focus?
  • WCAG 2.0 Level A & AA Baseline
    • 2 Focus Visible
  • WCAG 2.1 Level A & AA Baseline
    • 2. Focus Visible
  • WCAG 2.1 Level AA
    • 2.4.7 Focus Visible
  • WCAG 2.2 Level A & AA Baseline (beta)
    • 2. Focus Visible
  • WCAG 2.2 Level A (Draft May 21, 2021)
    • 2.4.7 Focus Visible

  • Severity

    2-High (red)
    in range of 4-Low to 1-Critical

  • Noticeability

    5 ()
    in range of 1 to 10

  • Tractability

    5 ()
    in range of 1 to 10