<h2>Helpful tips</h2>
<ol>
<li>For help enabling the <a href="https://www.figma.com/file/mp4RG0u7wecgHdCSzeydHJ/Dell-Accessibility-Annotation-Kit?type=design&node-id=0-1&t=OCBBGtv3AumVuS80-0">Accessibility Annotation Kit</a> library in Figma, refer to our <a href="/getting-started/figma">Getting Started with Figma</a> guide. </li>
<li>Place each type of annotation components in their own named layer within the document, where they can be turned off or on individually for maximum understandability. This will also help you maintain organized layers. </li>
<li>For maximum clarity, you may find it helpful to group all these layers together, with a title of “Accessibility Annotations” or similar. </li>
<li>Discuss your annotations with your team as early as possible. If necessary, point them to this page to make sure they understand their purpose. Consider adding a legend in your document if it helps create understanding and alignment. </li>
</ol>
<h2>Managing components</h2>
Components are listed in the Assets panel. Click any component and drag it from the panel onto your canvas. Some components are more customizable than others. <a href="/components/button/">Buttons</a>, for example, contain kinds, options, and states that can be modified. You can find this information in each component’s documentation. Visit Figma’s documentation to learn more about how to add components to your designs.
<h2>Integrating styles</h2>
All of the foundational styles for <a href="/foundations/color/">colors</a>, <a href="/foundations/typography/">typography</a>, <a href="/foundations/elevation/">elevation</a>, and <a href="/foundations/grid/">grid</a> will fully integrate into Figma when you enable the DDS v2 libraries. You can access library styles in the Properties panel by selecting the style you want to update. Visit <a href="https://help.figma.com/hc/en-us/sections/4403928368535-Styles">Figma’s Style documentation</a> to learn how to work with styles on your canvas.
<h2>Reviewing updates</h2>
You may see a notification that prompts you to review or dismiss component updates. Carefully review the updates before accepting them—they may break your layout or design, and you will not be able to undo those changes. Select Review from the notification and choose the updates you would like to apply. Visit Figma’s documentation to learn how to review and accept updates from libraries.
<h2>Resources</h2>
<details data-name='card-collection' data-cards='[{"image":{"url":"","alt":""},"link":{"label":"Review in Figma","path":"https://www.figma.com/file/mp4RG0u7wecgHdCSzeydHJ/Dell-Accessibility-Annotation-Kit?type=design&node-id=211-765&mode=design&t=m5VgWT8rEZY6o7ED-0","type":"External"},"title":"Accessibility annotation kit","description":"View the accessibility annotation kit***s sticker sheet in Figma.","icon":"figma"},{"image":{"url":"","alt":""},"link":{"label":"Review WCAG 2.2 techniques","path":"https://www.w3.org/WAI/WCAG22/Techniques/","type":"External"},"title":"Techniques for ARIA landmarks","description":"Read techniques provided by WCAG 2.2 to properly use landmarks to identify regions of a page.","icon":"metadata"}]' data-NumberOfColumns='3' data-NumberOfColumnsMedium='2' data-NumberOfColumnsSmall='1'></details>

## Tab stops for keyboard

Tab stops refers to the order that a user can cycle through every interactive element on a webpage by pressing their keyboard tab key. Annotating them ensures that anyone without a mouse can still navigate through the page’s functionality in a consistent, logical manner.

### How to use tab stops

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.

<details data-name='image-block' data-images='[{"alt":"Simplified Latitude 5530 laptop page excerpt showing all interactive elements annotated with tab stop components, numbered in the vertical visual order.","caption":"","url":"https://dds.dell.com/site/production/45/a9/Ay11_Tab_Stop_9feceb2d80.png"}]' data-numberofcolumns='1'></details>

### Why you should annotate them

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.

### Tips

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](https://webaim.org/techniques/keyboard/).

## Headings

Annotating headings in your design makes clear what is and isn’t a heading, regardless of styling. It also makes clear what the HTML heading level should be, even if you’ve used a different heading level in your design for better visual hierarchy.

### How to use heading labels

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](/components/accordion/) and [modals](/components/modal/).

<details data-name='image-block' data-images='[{"alt":"Simple APEX Cloud Services page, showing all headings annotated with their level. The one H1, one H2 and three H3 instances form a vertical hierarchy.","caption":"","url":"https://dds.dell.com/site/production/9f/2a/Ay11_Heading_ca6755843c.png"}]' data-numberofcolumns='1'></details>

### Why you should annotate them

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.

### Tips

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. 

## Accessible names and descriptions

Elements like standalone icons, important images, and custom UI controls require additional names or descriptions (often as alt text) for screen readers. Annotating these ensure users will understand what they mean, or how they work, even if they can’t see them.

### How to use this component

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>.

<details data-name='image-block' data-images='[{"alt":"Annotated simple page example. A meaningful image is described, but a decorative icon is not. The cart and location menu have extra screen reader description.","caption":"","url":"https://dds.dell.com/site/production/91/c2/Ay11_Accesible_Names_bb377ec92f.png"}]' data-numberofcolumns='1'></details>

### Why you should annotate accessible names

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>.

### Tips

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 fewer. 
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”). 

## Buttons versus links

It’s crucial for accessibility to make clear what is a [button](/components/button/) and what is a [link](/components/link/) in your designs. That’s not just because they have different purposes, but also because screen reader users hear their role (type) announced and will interact with each differently via keyboard.

### How to use button and link labels

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.

<details data-name='image-block' data-images='[{"alt":"Stylized example portion of a product page, with all links and buttons within the page annotated separately.","caption":"","url":"https://dds.dell.com/site/production/91/8e/Ay11_Bvs_L_d2cf2bb46b.png"}]' data-numberofcolumns='1'></details>

### Why you should annotate them

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).

### Tips

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](/components/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](/components/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](/patterns/form/) submit button that takes the user to another page (such as a checkout button). 

## Landmarks

Annotating landmark regions—common areas of a page, each with their own special kind of content—greatly helps screen reader users by giving them an easy way to understand and navigate content on the page. Note that annotating landmarks, while helpful, is optional for designers.

<details data-name='image-block' data-images='[{"alt":"Simplified full webpage with all landmarks annotated, including Banner, Search, Navigation, Main for the main content, and Content info for the footer.","caption":"","url":"https://dds.dell.com/site/production/c8/a0/Ay11_Landmarks_08a11c3d62.png"}]' data-numberofcolumns='1'></details>

### How to use landmarks

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”).

### Tips

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:

| Landmark (ARIA) | HTML equivalent | When to use it | Supports multiple instances? |
| --------------- | --------------- | ------------------------------------------------------------------------------------------------------------------ | ---------------------------------------------------------------------------------------------------------------------- |
| Main | *main* | The main content area in a document. | **No**, should only be used once per page. |
| Banner | *header* | A global site header. Usually the company logo and name, search, and global navigation. | **No**, should only be used once per page. |
| Contentinfo | *footer* | The footer, containing [navigation links](/components/link/?tab=Design#usage), copyright, and privacy information. | **No**, should only be used once per page. |
| Navigation | *nav* | Identifies a group of links used for navigating through a website. | **Yes**, but each instance should have a unique identifying label. |
| Form | *form* | Identifies a group of elements that combine to create a [form](/patterns/form/). | **Yes**, but each instance should have a unique identifying label. |
| Complementary | *aside* | Identifies a supporting section that relates to the main content, but can stand alone when separated. | **Yes**, but each instance should have a unique identifying label. |
| Search | n/a | Identifies the page’s search functionality, such as a search bar. | **Yes**, but each instance should have a unique identifying label unless duplicate searches perform the same function. |
| Region | n/a | Identifies significant content when none of the other landmark roles are appropriate. | **Yes**, but each instance should have a unique identifying label, even if there is only one instance. |

Annotation Kit

The Accessibility Annotation Kit enables designers to indicate accessibility-related specs and behavior consistently for handoff. It also contains tips and guidelines to help designers consider accessibility earlier in the product lifecycle.
