Annotating Designs for Focus

Contents

Why Do We Care About Focus?

Good user experience design makes web pages obvious and easy to use. This includes all users– not just users without disabilities.

Many (if not most) users without disabilities are not even aware of what focus means. Since the invention of the graphical user interface, most people without disabilities just use a mouse, finger, or pointing device to find and select the element that they want. Users with disabilities often need to interact with the user interface differently. For instance, blind users may use a screen reader and people with mobility impairments may use their keyboard instead of a pointing device to first select the element that they wish to interact with and then interact with it. “Focus” means selecting a control but not invoking that control. By selecting a control, blind users can learn about and identify that control before invoking it. And providing a clear visual indication of focus is critical to users with mobility and dexterity limitations so they will know which controls they are about to activate.

Don’t Browsers Indicate Focus Automatically?

By default, most modern browsers will show focus automatically and thus meet WCAG. While you may be tempted to think that you can ignore how focus appears, there are a few problems with simply relying on the browser. First, don’t ignore focus because you will have no control over how that focus will appear in the browser. Second, if you don’t specify how focus should appear, there’s a good chance that a developer will reuse an existing component that doesn’t reveal focus– and your designs will fail WCAG. Third, but of somewhat lesser concern, the default indication of focus in browsers can be faint and you may want to make your designs a bit more user-friendly for your customers with disabilities.

If you want to rely on the browser defaults, however, that’s permissible in WCAG but you should still include an annotation to reinforce that point. For instance, the following annotation can be attached to wireframes to simply indicate that links and buttons should display the standard browser focus appearance and provides an example of this default appearance in Chrome.

Screenshot described in accompanying text

How to Annotate Designs to Indicate Focus

So now you’re excited to make sure that focus is indicated in your designs. How do you go about doing it? Just as an architect would never dream of giving a set of blueprints without careful annotations and notes explaining graphical details, UX designers should provide annotations to indicate how focus should appear in their designs.

Probably the easiest way to do this is to break the design down into sections or components and then illustrate how focus should appear in each section or component. Often, you may want to include the other states (such as “hover”, “selected”, or “inactive”) for each section or component.

A Working Example of Annotating Focus

For instance, here is the first screen of the desktop view of a medium-fidelity wireframe in Figma for a hypothetical online store.

Annotating Focus with Larger Components or Groups of Components

In this example, when the user hovers over a menu item, the UX designer would like menu item text to display an underline– and so it makes perfect sense to provide the same visual effect when the menu item receives focus, as shown in the annotation below.

Screenshot of wireframe annotation described in accompanying text.

Then, when a menu is activated, the UX designer would like the menu content to “push” the announcement down below it instead of obscuring the announcement. And to clarify which element is selected, the designer wants the other menu items to dim. This is shown in the annotation below.


Annotating Focus with Individual Components

In the last example, we showed menu items that changed as a group. Most of the time, however, UI elements don’t change appearance when a different component changes state. In that case, these smaller items can be quickly addressed in a table. For instance, the following screenshot shows the different states of each the shopping cart controls, the “back” control for popular items, the user account control, and link text that appears on the page. This information is arranged in a table so business owners, developers, and testers can rapidly understand how the UI elements should appear in final designs. And by neatly summarizing this information in a table, we do not have to create dozens of separate wireframes indicating how each element should appear when it receives focus.

Important Points to Remember

As you create annotations to indicate focus in your wireframes, keep the following important points in mind:

  • Remember Color Contrast. If you are going to indicate focus, remember that your focus indicator should provide a contrast ratio of at least 3:1 (1.4.11.1 Non-Text Contrast). In the example in the screenshot immediately above, that would include the dark indicator bar under the shopping basket and account icons and the blue boxes around the arrow icon and the link text. A useful tool to have in your toolbox is the free Colour Contrast Analyser, which lets you easily check contrast for graphics and icons.
  • Don’t Rely on Color Alone. While it may be tempting to change the color of an icon or a link when it receives focus, this would violate 1.4.1.1 Use of Color. While the examples in the last screenshot used a blue box around text links and the arrow icon, it is the presence (or absence) of the box– and not the color of the box– that enables it to pass 1.4.1.1 Use of Color. If we indicated focus just by changing the arrow into a blue arrow or by making the text and underlining of the link blue, that would violate 1.4.1.1 Use of Color.