Accessibility Annotation Kit

Using the tab stop annotation component, label each and every interactive element on your page in the sequential order that a user should be taken when pressing tab. Do not label anything that isn’t interactive. Edit the number for each instance to indicate that element’s position within the order.

When keyboard tab stops in a design aren’t properly established or communicated in advance, it can lead to serious accessibility issues, including:

• Missing tab stops (keyboard-inaccessible elements or functionality) that prevent users from properly finding information or completing critical tasks.
• Random or nonsensically ordered tab stops, leading to keyboard users being jumped around the page in a confusing way.

1. Number every interactive page element, including links, buttons, and form controls. Don’t label anything which is noninteractive, such as regular text.
   
   
2. The tab order should generally follow the visual (reading) order: left to right and top to bottom.
   
   
3. If a group of interactive elements is repeated in another page or view, its tab order should be the same every time.
   
   
4. For pages with a lot of complex interactivity, focus on moving the user logically through the page.

Read more about tab order and accessibility on WebAIM’s introduction to keyboard accessibility.

Label each and every heading on your page with the correct level using the heading annotation component. Make sure to also label any that are within temporarily hidden content, such as accordions and modals.

Misused or mislabeled headings can cause the following accessibility issues:

• Headings inadequately describing the content beneath, increasing confusion and cognitive load.
• Heading text not properly coded as a heading, making it invisible to users who are blind.
• Poorly organized and out of order headings that fail to make sense to users with a screen reader.

1. Annotate the heading’s level based on its function in your design rather than its name as designated in the font ramp, as these will not always match (this applies to DDS v2 or another Design System UI kit).
   
   
2. Make sure there is only one H1 heading, and that it describes the page as a whole.
   
   
3. Label the heading levels so they descend sequentially in importance after the H1. Don’t skip levels.
   
   
4. All headings with the same importance should be marked at the same level.
   
   
5. All headings should be descriptive. If a heading doesn’t describe the content that follows it, don’t annotate it as a heading.
   
   
6. Check that each heading on the page begins differently than the others. Each one should be both unique and brief.

Use the accessible name component to label any important elements in your design where information would be missing for someone who couldn’t see it. For each instance, edit the text to indicate what the user should hear for that element. If an element should specifically be hidden from screen readers and not announced, set the announced property to <no>.

Inadequate accessible descriptions can lead to the following accessibility issues:

• Pages and screens losing critical information for nonsighted users, such as diagrams or photos becoming invisible or meaningless.
• Poorly or overly described elements, clutter the page with poor quality information, disrespecting screen reader users since they have no way to avoid listening to them.

Noncritical visual elements (such as decorative patterns or filler images) should be hidden from screen readers by simply changing the annotation’s announced property to <no>.

1. All meaningful images should have an accessible description added.
   
   
2. All decorative images should be marked as hidden (set announced to <no>).
   
   
3. If an icon or image has the equivalent meaning in text alongside, mark it as hidden (set announced to <no>). For example, a cart icon placed next to the word “cart” can be hidden.
   
   
4. Photos and illustrations should be described literally. For icons, describe its meaning or purpose rather than a literal description when shown in that context.
   
   
5. Write plainly. Avoid using humor, metaphors, or clichés.
   
   
6. Limit the description to 140 characters or less.
   
   
7. If adding a description to an element that already contains text, make sure that the existing visible text forms the first part of the description.
   
   
8. For (nonstandard) controls, the accessible description should indicate any functionality that the user needs to understand (such as “Close this window” as opposed to “close” or “close icon”).

Label every button and link in your design with the button versus link component. For each instance, select the appropriate type to annotate it as either a button or link.

Put simply, annotating these makes it clear for your engineers which should be which.

Mixing up buttons and links can lead to the following accessibility issues:

• Buttons or links used in place of each other, leading to confusion for users who are blind and or who have a cognitive difficulty, who expect buttons and links to function in specific ways.
• An element coded incorrectly causes critical problems for sighted people using voice control software (such as telling their software to “click a button” and getting no response due to it being a link).

Elements should be selected based on functionality first. Whether something is a link or a button depends on what happens when it’s triggered:

1. A link takes a user to another place, such as another page (or place on the same page). It can also open a link in a new window.
   
   
2. A button performs a scripted action, such as opening a modal, or manipulating content on the page (such as opening or closing an accordion).
   
   
3. The only exception is a form submit button that takes the user to another page (such as a checkout button).

When possible, use the landmark component to mark each specific area of the page. You can resize the component as necessary to enclose it. For each instance, use the landmark option to select the appropriate landmark type. If selecting the region variant or using duplicate landmarks within a page (see tips below), enter a specific name after the label (such as “example”).

When selecting landmarks, try to keep the total number low and make sure all content on the page is enclosed by a landmark if possible. To understand when or why to use or reuse a landmark on a page, please see the following table: