Visible focus


When focused, all actionable and focusable elements must have a visible state change.


Visible focus helps all users track where they are within the content. Sighted keyboard and switch device users track progress as they navigate focusable elements, similar to using a remote control with a TV interface. Touch users also receive confirmation that an element is interactive.

Visible focus states happen when hover, focus or touch interactions occur. Do not depend on a browser's default visible states for hover, focus, or touch, as they may not work with the design. Do not inadvertently remove any default visible states for hover, focus, or touch unless providing an alternative. The visible focus state for all three interactions may look the same.

Hover, focus and touch states should not be used to convey information that is not available elsewhere.


iOS provides visible state change for elements when input is provided by the onscreen keyboard.

Focus for other actionable and focusable elements is provided by Voice Over via assistive technology.

Accessibility focus is determined by the property which is provided for all subclasses of UIView. Ensure that objects do not override the visual focus indication or set the accessibilityFrame property to nil.

iOS example

// gbutton is a simulated button to provide accessible touch to a graph. It has already been initialized as a UIAccessibilityElement
gbutton.accessibilityLabel = NSLocalizedString(@"1st quarter results", @"Button title");
gbutton.accessiiblityTraits = UIAccessibilityTraitButton;
gbutton.accessiiblityFrame = CGRectMake(x, y, w, h); // We set the accessibilityFrame here so we know where the object is and can draw a focus rectangle around it.                        
// gbutton is a simulated button to provide accessible touch to a graph. It has already been initialized as a UIAccessibilityElement, button title not translateable
gbutton.accessibilityLabel = @"1st quarter results";
gbutton.accessiblityTraits = UIAccessibilityTraitButton;
gbutton.accessiiblityFrame = nil;                        


Developers should provide a visible indication when an element has focus. This is done by default for standard elements but for custom elements that have their own style sheets the focus style must be set in the style sheet when state_focused="true".

Android example

// A custom element that is drawn differently when it has focus via the stylesheet
<CustomButton android:layout_height="wrap_content" android:layout_width="wrap_content" android:background="@drawable/my_button"></CustomButton>

// the my_button.xml file in res/drawable
<selector xmlns:android="">
    <item android:state_focused="true" android:drawable="@android:drawable/btn_default_focused"></item>
    <item android:drawable="@drawable/btn_default_my"></item>
//A custom element that is only drawn one way
<CustomButton android:layout_height="wrap_content" android:layout_width="wrap_content" android:background="@drawable/my_button"></CustomButton>

//the my_button.xml file in res/drawable
<selector xmlns:android="">
    <item android:drawable="@drawable/btn_default_my">


By default, standard HTML elements have a visual focus indicator provided by the browser. Therefore all links and focusable elements must not have their outline suppressed via CSS changes with the :focus pseudo class or the outline property unless a custom focus is provided. If using a custom focus give elements the same visible focus on :focus as on :hover and provide visible focus for form fields.

Note, mobile browsers don't have good support for the CSS pseudo property hover.

HTML example

<!-- example 1, no CSS property changes will automatically produce desired visual focus in supporting user agents-->
<a href="..."> Next </a>

<!-- example 2, use of the CSS outline property -->
<style type="text/css">
a {
 outline: black dotted thin;
<a href="..."> Next </a>                        
<style type="text/css">
a {
 outline: none;
<a href="..."> Next </a>                        



  1. Navigate through the active on-screen components.
  2. For each active element that receives focus:
    - Verify where the text input location is;
    - Verify that the focus location is indicated at all times and follows traversal of the user interface;
    - Verify that the focus indicator can be clearly distinguished from other on-screen elements.

The following is true:

  • The text input location is indicated;
  • When switching page tabs, the focused tab is indicated visually and announced by a screen reader;
  • The object, element, or control that has focus is indicated in a clear, visually distinguishable manner that meets the colour contrast requirements.