Annotations for keyboard and screen reader navigation

  • 20 minutes

Annotations for keyboard accessibility help designers communicate how users can navigate and interact with their designs using a keyboard. Here are some common annotations using the A11y Focus Order Plugin and Fluent Accessibility Design Toolkit:

Focus order

Indicate the sequence in which interactive elements should receive focus when navigating with the tab key. This helps ensure a logical and intuitive flow for keyboard users.

  • Use the focus order indicators to show the intended ordering of elements when being navigated using a keyboard.

    Screenshot of WishCart application with wish cart, delivering to New Delhi, Search field, choose language for shopping, hello sign in accounts &lists, returns &orders and Cart defined as custom component, Search in all category Drop-down list as parent component and 'All categories', 'Devices' & 'fashion' as its child components. Each section has numerical labels indicating the focus order.

    Screenshot of the Teach Access homepage, with focus order accessibility annotations on two sections labeled Who We're and What is the accessibility Skills Gap? Each section has numerical labels indicating the focus order.

Name, role, and state

It's crucial that all user interface components, including but not limited to form elements, links, and components generated by scripts, have names, and roles that can be programmatically determined. This ensures that assistive technologies can interpret and interact with these elements effectively. Furthermore, has to states, properties, and values which can be set by users are also programmatically settled. This allows users to have a seamless experience while interacting with our interface. Additionally, we need to ensure that any changes to these items aren't field to user agents, including assistive technologies, so that users are always aware of the current state and can interact with the interface accordingly.

For the library components, "Name" will be same as per the design and same will be announced by the screen reader. Role will auto populate and then select or define properties either by selecting via provided checkboxes or mention in the edit field. If need to include any custom keyboard shortcuts that we can add, and all these another properties show up under Developer notes section. For custom components we need to do everything, selecting correct control type, review all the flows, set relevant properties, shortcuts. So before using custom components ask, do I need it? Is there any component that serves the purpose. If not, then use it and ensure covers all flows and edge cases.

Screenshot of specs for Keyboard and screen reader annotations: A widget dialog specification table with four labeled sections. The table includes screen reader labels, components, and developer notes. Label 1 point to Category with a dropdown component. Label 2 highlights Show widget selector with a checkbox component. Label 3 points to Widget selector with a custom widget link. Label four indicates Save with a button marked as optional. Developer notes mention properties and keyboard shortcuts.

When we have multiple components with the same visual name than we should override the visual name. Why should we do this? We have different navigation for buttons, links. When a screen reader user runs with the respective navigation, it will just announce the name and no more context is visible on the UI. For for example, In this image it announces Create, Create, Browse when user navigates with button navigation. You can provide more context using Aria override or another way that includes the visible name of the control.

Screenshot of example shown in below image is where two components have same visual name as 'create' which is incorrect as it announces Create for both and browse for 3rd button when user navigates with button navigation and will create confusion and doesn't describe the purpose of each button.

Screenshot of example shown in below image is where two 'create' buttons are there, but we have added another text in an Aria-Label override that includes the visible name of the control such as Create a new hire onboarding, Create urgent collaboration template & Browse other template respectively which describes the purpose of each button.

States are critical only if they're illustrating a flow or a specific condition where that particular state is critical, like cases where in a flow something is disabled, marking out that as disabled is a good practice.

Screenshot of example of accessibility for Name, Role, and state of input field and buttons. Element #1: Name -User name, Role – Input. Element #2: Name – Password, Role – Input. Element #3: Name – Forgot Password, Role – Link. Element #4: Name – Login, Role- Button, State – Disabled. Element #5: Name – Remember Me, Role – Checkbox, State – Not checked.

Shortcut keys

Highlight Add any keyboard shortcuts that aren't standard rather a customize one and can be used to perform actions within the design.

Screenshot of example of accessibility annotations for shortcut keys, with the shortcuts Ctrl+Shift+M=Mute, Ctrl+Shift+E=Share Content, and Ctrl+Shift+H=Leave Meeting Ctrl + + = Zoom In, Ctrl + O = Open document or file, Ctrl + - = Zoom Out, and Ctrl + W = Close window or document.

Screenshot of example of accessibility annotations for keyboard interactions and shortcuts, with the text Bold button = Ctrl+B, Italic button = Ctrl+I, and Underline button = Ctrl+U.

Headings

Use headings to make it easy to jump through your designs. These are the titles and subtitles of a web page that can be navigated like a tree structure using hierarchy.

  1. There can be only one H1 on the page.

  2. There can be any number of H2s, H3s, and H4s.

  3. Heading levels must follow an order. You can't jump from H2 to H4 without a subsequent H3.

    Screenshot of Microsoft Teams chat application interface with two labeled annotations. The interface shows multiple conversations with timestamps, and a chat window on the right displays messages. Label 1 point to the left panel (H1) displaying a list of contacts and chat history. Label 2 highlights the top right section, which contains search and menu options (H2).

    Screenshot of a row of five circular icons, each labeled with a different heading level: h1, h2, h3, h4, and h5. These icons represent different header annotations used for screen reader navigation.

Landmarks

Landmarks can be useful additions when defining entire screen experiences on the web. These are containers or regions that can be used to quickly navigate apps, sites across different regions such as main, search, header, or footer etc. We have various landmarks such as Banner, Navigation, Main, Search, and few others.

  1. If you have just one landmark, make that the main landmark so you can provide a skip link to go directly to the content via keyboard.

  2. Search is another critical landmark. And then Navigation landmark.

  3. Most of the times Headings are going to be sufficient. If you want to make it more diverse and accessible when having long pages/websites that are chunked out with regions and rectangles then define landmarks. Less landmarks are better.

  4. There can only be one banner landmark, which is usually the header of the page.

    Screenshot of Microsoft Teams chat application interface with four labeled annotations. The interface includes multiple chat messages with timestamps. Annotation 1 point to the right panel, titled Main, showing a conversation. Annotation 2 highlights the navigation panel. Annotation 3 points to the banner. Annotation four points to the search bar at the top.

    Screenshot of a diagram showing different screen reader landmarks annotations with labels and values. It includes boxes labeled Main, Search, Navigation, Banner, Region, Complementary, Content info, and Form. Each landmark box has Label: Value so designers can input their respective label and value. The boxes are outlined in different styles, such as solid or dashed lines.

Alerts, error message, live region

Alerts/Error message/Live region Notifies user of completion, any change on UI any errors. They're used to let screen reader users know when a long-running process has succeeded, a task has failed, or something has happened without user input. Ensure that visual messages are read out in an intelligible and equitable manner without stealing focus.

Screenshot of a desktop notification from Microsoft Teams showing an error message. The message reads, Couldn't send message in chat with Kat, Kayo, Babak, and four another people.

Screenshot of error messages from the Form requesting users to fill out the field of information before continuing. The accessibility annotations make note of error stating that It's an Empty State Error Message, and to Enter your name to fix the error.

Screenshot of a search bar on Teach Access's Donate page displays the name Microsoft entered as a query. A pop-up notification appears, informing users that Microsoft offers a matching gift program.

Focus management

Ensure that focus is managed correctly, especially when modal dialogs or menus are opened or closed then focus lands back to component from where it was triggered. This helps users navigate through the content efficiently by ensuring focus management is predictable and understandable

Alternative text

Provide alternative text for images, icons, and other nontext content. This allows screen readers to describe these elements to users who can't see them. Be sure to follow best practices when writing alt text.

Resources