Designer

Introduction

Some users navigate user interfaces only with the keyboard or other hardware devices, such as joysticks, trackballs, or switches. They may have disabilities that make using a mouse difficult or impossible, or they may prefer keyboard navigation for its efficiency and convenience. Keyboard navigation enables these users to move the focus from one element to another on the screen and to interact with elements using only the keyboard. When designing new interfaces, it is important to consider the order of focus movement, provide clear indications of the focus state, and ensure that all elements are keyboard-accessible.

Screen readers are software programs that convert text and other elements on the screen into speech or braille output. Users who are blind, have low vision, or cognitive impairments may use them to access screen content. They also interact with the computer using the keyboard or other devices. Good visual design aids sighted users in understanding the meaning and hierarchy of content; screen reader users rely on the markup and metadata in the code, which the screen reader software recognizes, to comprehend and navigate the UI.

On iOS and Android, users can also navigate the UI using screen readers and other assistive technologies. Instead of keyboard keys, they employ swipe gestures to move the focus from one element to another. Interactive elements are activated by double-tapping on them.

Because the order of elements, metadata, and keyboard interactions are not visible in the design, we need a method to communicate them to engineers. This is where accessibility annotations come into play.

Accessibility should be considered from the beginning of the design process, as this helps create inclusive designs, prevents major changes later on, and accelerates the review process by the accessibility team. All designs should still undergo an accessibility review before they are finalized.

Annotation components

The Acorn Design System provides a set of components for creating accessibility annotations in an easy and consistent way. You can find these components in the File Presentation Library in Figma or use the ones already placed in the UX Project Template.

The components consist of the annotation itself, which can be placed on top of the design, and the annotation information, which is placed on either side of the design. Annotations and annotation information are associated with each other by a number or letter. More on that below.

There are four types of annotations: Tab navigation (purple), arrow-key navigation (green), notes (orange), and presentational (gray). All four types are used on desktop, while mobile only uses notes (orange) and presentational (gray) annotations.

To annotate your design, you can put it in a frame, lock the design layer, and then put the annotations on top of it.

How to use the annotations

There are some differences in how to use the annotations on desktop and mobile. The differences are limited to what elements are annotated, which types of annotations are used and how they are numbered.

Annotation types

Desktop

Elements that users can interact with — such as buttons, links, text fields, or other controls — should be annotated with either a tab navigation or arrow-key navigation annotation. The primary way for keyboard users to navigate through a UI is by using the tab key, while arrow keys play a secondary role, usually for navigating within an element that has been focused with the tab key first.

Looking at form control elements, such as text fields, radio buttons, checkboxes, dropdowns, and so on, users can focus them using the tab key and then use the arrow keys to interact with them, e.g., to select a radio button or checkbox, or to select an option in a dropdown. In this case, the form control element would be annotated with a purple tab navigation annotation. There is no need to annotate arrow-key navigation for form controls, as the patterns are already well established.

Another example is lists, where users can navigate to the first item in the list using the tab key and then use the arrow keys to navigate through the list. In this case, the list items would be annotated with a green arrow-key navigation annotation.

Although we don't annotate all elements in designs for Desktop, for instance, text is usually not annotated. Some non-interactive elements still need to be annotated, such as icons, images, headlines, and landmarks. These are annotated with an orange note annotation.

What are landmarks? Typically, user interfaces are designed in a way that sighted users can easily distinguish separate sections. For instance a navigation bar is usually visually distinct from the main content, or sections in a list separated from each other through spacing, borders, or the use of cards. Landmark annotations provide a way to mark these distinct sections explicitly for users of screen readers, which not only allows them to understand where they are in the UI but also to jump between them quickly. We often annotate navigation, main areas, headlines, or sections (such as cards) as landmarks.

Visual elements that don't have a text label, such as icons, images, and other elements that do not have text or are insufficient to describe the element, should have a note annotation that describes the element, providing a text alternative.

Some images or elements don't contain information relevant to understanding the content or accomplishing a task and should be marked with the gray presentational annotation so screen readers ignore them.

Mobile

All elements in a UI, interactive or not, should be annotated with an orange note annotation. Because screen reader users navigate the UI using swipe gestures, we try to group elements and reduce the number of individually focusable elements so users don't have to swipe through too many elements to get to the one they want.

Some images or elements don't contain information relevant to understanding the content or accomplishing a task and should be marked with the gray presentational annotation so screen readers ignore them.

Focus order and annotation numbering

Desktop

On desktop, we differentiate between the order in which the focus moves from one element to another using the tab or arrow keys and the order in which the screen reader reads the elements. The focus order presents a subset of the screen reader order, as not all elements are focusable.

We annotate the focus order explicitly. Use numbers starting with 1 for tab navigation, and for arrow-key navigation, use letters. Because arrow key navigations are nested within tab navigations, the letters are always prefixed by the focus number of the tab navigation. For example, a list that is the 3rd focusable element on the page would be annotated with a tab navigation annotation with the number 3, and the list items would be annotated with arrow-key navigation annotations with the numbers 3A, 3B, 3C, etc. We recommend reusing the letters for items of the same type. For example, in a list with two buttons, the first button in each row would be annotated with 3A and the second with 3B.

Notes and presentational annotations are enumerated with letters without relation to the focus order.

Even though all elements (except those annotated as presentational) can be read by screen readers and thus also have an order in which they are read, we don't annotate this order on desktop. Instead, the order is assumed to be the reading English reading order, which is left-to-right and top-to-bottom. Suppose you, together with the accessibility team, come to the conclusion that the screen reader order should be different from the reading order. In that case, you can annotate it explicitly using a note.

Mobile

On mobile, we explicitly annotate the order in which the screen reader reads the elements. All annotations are numbered, starting with 1. Even though we explicitly annotate the order, we still want to follow the English reading order, which is left to right and top to bottom. You should only deviate from this pattern if you have a good reason to do so and should discuss it with the accessibility team.

Writing annotation information

The annotation information consists of the reference number or letter corresponding to the annotation, name, role, and further notes. Notes are optional and can be used to provide any additional information not covered by the name and role you think is important for the developer to know. The accessibility team usually supplements additional information here, too.

The name is what the screen reader reads when the element is focused. By default, this is pre-filled with "[use on-screen string]", indicating that the name should be the same as the text visible on the screen. This is the case for most buttons, links, and other elements that have text labels. Elements like icon buttons, images, and other elements that don't have a text label should have a name that describes the element to provide a text alternative. The name can also differ from the visible text if the visible text is not descriptive enough. For example, a button that says "More" should have a name that describes what happens when the button is activated, such as "Show more results".

The role describes the semantic meaning of the element, which the screen reader also reads. The role is usually the same as the type of element and, by extension, easy to determine, such as "Button", "Link", "Input", "Checkbox", "Radio button", and so on. Yet, it can also refer to custom components such as toggle switches, that are already part of the design system. If you are unsure about the role of an element, you can reach out to the Acorn or accessibility team for help. The section for custom components below provides more information on how to annotate them.

On desktop, the annotation information note field should provide information on which arrow keys are used to navigate to the next or previous element. On complicated pages with many annotations, such as Firefox View, it can make sense to separate interactive and non-interactive elements into different columns to make the annotations easier to read.

Landmarks are annotated with a role that describes the landmark type, such as "main", "navigation", "section", "form", and so on. The name field can be omitted for them. Landmarks that should be annotated (if present in the design) are headlines along with their level (e.g., headline 2), "navigation" (for the main navigation), "main" (for the main content of the page), "search" (for the search field), and "section" or "article" (for sections of the page, mainly in the form of cards).

 

Designing custom components

User interfaces usually consist of standard components already part of the design system, like buttons, links, images, and so on. Other times you use components that are not standard but already have been implemented in the code and undergone an accessibility review, like the toggle switch.

Sometimes, however, you might find that a custom component would be the best solution for a particular design problem. In that case, you need to design the component and then annotate it for accessibility. More often than not, the component might look very different from the standard components but functionally can be treated the same way. For example, if you design a custom component where users can select how many slices of a pizza they want, you can try to find a standard component that is similar in function, such as a slider, and then annotate it as such.

If you want to create a custom component, reach out to the Acorn team and the accessibility team for help.