Skip to content

Commit fb37518

Browse files
committed
Fix Acrolinx issue
1 parent 55201db commit fb37518

8 files changed

+19
-19
lines changed

learn-pr/cela-accessibility/accessibility-design-specs-with-annotations/2-overview-of-accessibility-annotation.yml

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -2,7 +2,7 @@
22
uid: learn.cela-accessibility.accessibility-design-specs-with-annotations.overview-of-accessibility-annotation
33
title: Overview of accessibility annotation
44
metadata:
5-
title: Overview of accessibility annotation
5+
title: Overview of Accessibility Annotation
66
description: This unit is a part of the accessibility design specs with annotations module.
77
ms.date: 02/14/2025
88
author: erzelman

learn-pr/cela-accessibility/accessibility-design-specs-with-annotations/3-annotations-for-keyboard-ascreen-reader-navigation.yml

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -1,6 +1,6 @@
11
### YamlMime:ModuleUnit
22
uid: learn.cela-accessibility.accessibility-design-specs-with-annotations.annotations-for-keyboard-ascreen-reader-navigation
3-
title: Annotations for Keyboard and Screen Reader Navigation
3+
title: Annotations for keyboard and screen reader navigation
44
metadata:
55
title: Annotations for Keyboard and Screen Reader Navigation
66
description: This unit is a part of the accessibility design specs with annotations module.

learn-pr/cela-accessibility/accessibility-design-specs-with-annotations/4-design-for-color-contrast-requirements.yml

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -1,6 +1,6 @@
11
### YamlMime:ModuleUnit
22
uid: learn.cela-accessibility.accessibility-design-specs-with-annotations.design-for-color-contrast-requirements
3-
title: Design for Color Contrast requirements
3+
title: Design for color contrast requirements
44
metadata:
55
title: Design for Color Contrast requirements
66
description: This unit is a part of the accessibility design specs with annotations module.

learn-pr/cela-accessibility/accessibility-design-specs-with-annotations/5-knowledge-check.yml

Lines changed: 4 additions & 4 deletions
Original file line numberDiff line numberDiff line change
@@ -1,6 +1,6 @@
11
### YamlMime:ModuleUnit
22
uid: learn.cela-accessibility.accessibility-design-specs-with-annotations.knowledge-check
3-
title: Knowledge Check
3+
title: Knowledge check
44
metadata:
55
title: Knowledge Check
66
description: This is the knowledge check for the accessibility design specs with annotations module.
@@ -16,16 +16,16 @@ quiz:
1616
choices:
1717
- content: To make designs look more colorful
1818
isCorrect: false
19-
explanation: Incorrect. While enhancing visual appeal, providing information about the design process, and documenting the process are important, accessibility annotations specifically focus on making the design accessible to everyone.
19+
explanation: Incorrect. It's important to enhance visual appeal, provide information about the design process, and document the process. However, accessibility annotations specifically focus on making the design accessible to everyone.
2020
- content: To ensure designs can be used by all users, including those with disabilities
2121
isCorrect: true
2222
explanation: Correct. The primary purpose of annotating design mockups for accessibility is to ensure that designs are usable by all users, including those with disabilities.
2323
- content: To provide additional information about the design process
2424
isCorrect: false
25-
explanation: Incorrect. While enhancing visual appeal, providing information about the design process, and documenting the process are important, accessibility annotations specifically focus on making the design accessible to everyone.
25+
explanation: Incorrect. It's important to enhance visual appeal, provide information about the design process, and document the process. However, accessibility annotations specifically focus on making the design accessible to everyone.
2626
- content: To document the design process
2727
isCorrect: false
28-
explanation: Incorrect. While enhancing visual appeal, providing information about the design process, and documenting the process are important, accessibility annotations specifically focus on making the design accessible to everyone.
28+
explanation: Incorrect. It's important to enhance visual appeal, provide information about the design process, and document the process. However, accessibility annotations specifically focus on making the design accessible to everyone.
2929

3030
- content: Which of the following is a critical consideration when implementing keyboard navigation in designs?
3131
choices:

learn-pr/cela-accessibility/accessibility-design-specs-with-annotations/includes/2-overview-of-accessibility-annotation.md

Lines changed: 5 additions & 5 deletions
Original file line numberDiff line numberDiff line change
@@ -12,7 +12,7 @@ Familiarizing yourself with key terms is essential for effectively implementing
1212

1313
- **Accelerator Keys:** These keyboard shortcuts allow users to quickly perform common tasks without using a mouse. For example, pressing **Ctrl** + **C** copies text, and **Ctrl** + **V** pastes it. These shortcuts help users work more efficiently by saving time.
1414

15-
**Screen Reader Navigation with Keyboard:** Screen reader users navigate content using arrow keys to understand and read all the elements on the page. They also use tab key to move through interactive elements. Additionally, users often utilize screen reader specific keyboard shortcuts built into the screen reader, i.e., to jump between different components. For example, pressing the "H" key allows them to quickly navigate to headings, "T" allows to access the table, "D" key is used to navigate between landmarks.
15+
**Screen Reader Navigation with Keyboard:** Screen reader users navigate content using arrow keys to understand and read all the elements on the page. They also use tab key to move through interactive elements. Additionally, users often utilize screen reader specific keyboard shortcuts built into the screen reader, i.e., to jump between different components. For example, pressing the "H" key allows them to quickly navigate to headings, "T" allows users to access the table, "D" key is used to navigate between landmarks.
1616

1717
- **Sequential Navigation**: This feature allows you to move through the elements in a website or app one by one in a specific and logical order. Keyboard and screen reader users can navigate from one element to the next. For for example, with a screen reader, user can navigate between content such as moving from a heading to a paragraph or from one link to another. Ensuring a logical and meaningful order is crucial for accessibility. Read only text should never get a tab stop.
1818

@@ -34,15 +34,15 @@ Familiarizing yourself with key terms is essential for effectively implementing
3434
- **Windows Contrast Themes**: Windows contrast themes refer to the theme settings that use color combinations where text and important UI elements are presented with a significant difference in color and brightness from their background. Strongly contrasting colors can make it quicker and easier to read for people with low vision from your PC. Users can select respective themes by select Start button à SettingsàAccessibilityàContrast themes.
3535

3636

37-
- **Resize**: This term refers to changing the size of elements on a screen, which may include increasing or decreasing the size of text, images, and other content to enhance readability and accessibility. Resize is particularly important for users with visual impairments, as they often require larger text or elements to interact with content effectively.
37+
- **Resize**: This term refers to changing the size of elements on a screen, which may include increasing or decreasing the size of text, images, and other content to enhance readability and accessibility. Resize is particularly important for users with vision disabilities, as they often require larger text or elements to interact with content effectively.
3838

3939
- **Reflow**: This is the process of rearranging content to fit the screen size and orientation. During reflow, the layout adjusts dynamically to maintain readability and usability, eliminating the need for horizontal scrolling. This is especially crucial for mobile devices and ensures users can access content comfortably in one direction. Except for parts of the content which require two-dimensional layout for usage or meaning. Examples of content which requires two-dimensional layout are images required for understanding (such as maps and diagrams), video, games, presentations, data tables (not individual cells), and interfaces where it's necessary to keep toolbars in view while manipulating content.
4040

4141
You can avoid many accessibility issues by planning for them during the design phase. Use helpful tips and tools, like plugins and templates, to save time when adding accessibility details to your designs in Figma. This unit will show you how to include accessibility features in your design process.
4242

4343
## Annotation principles:
4444

45-
Our core accessibility principles are making UI understandable, efficient, and habituating for users. These principles are based on three Tenets. Let's learn more on these three Tenets which help designing an experience that an assistive technology user love.
45+
Our core accessibility principles are making UI understandable, efficient, and habituating for users. These principles are based on three Tenets. Let's learn more on these three Tenets which help designing an experience that an assistive technology users love.
4646

4747
1. Understandable: I know what I can do
4848

@@ -66,7 +66,7 @@ Habituating: Users can't help but learn habits. And habits are developed automat
6666

6767
- Not repeating visible names of elements: You don't have to define a label for a control that already has a visible label, like a button, or a check box. it's going to be read out. So often in the spec, you'll just go ahead and say visible name, and that way the engineer knows not to add an explicit label.
6868

69-
- Focus on adding annotations when essential: We should annotations when it's essential for for example, starting focus, lost focus that is, deleted item, zero states, Focus in and out of dialogs, frames, iFrames, popovers, Skip nav link, cluster of components for example. Should this be a grid or a list.
69+
- Focus on adding annotations when essential: We should annotations when it's essential for for example, starting focus, lost focus that is, deleted item, zero states, Focus in and out of dialogs, frames, iFrames, pop-overs, Skip nav link, cluster of components for example. Should this be a grid or a list.
7070

7171
- Ensure reflow readiness. Pro tip: Auto layouts are best to design for reflow.
7272

@@ -94,4 +94,4 @@ When we start the spec, name and focus order will be on the top when editing the
9494

9595
:::image type="content" source="../media/annotation-type-figma-types.png" alt-text="Screenshot of showing different types of controls. One with circle shaped and label 1 is a custom image. The controls with circle shape followed by arrow with label 2 is parent control. Right arrow with 'A' and 'B' label as child. The component labeled as three,4 & 5 are library components with diamond shape." lightbox="../media/annotation-type-figma-types.png":::
9696

97-
:::image type="content" source="../media/pluginui.png" alt-text="Screenshot of When editing the component itself in the component UI, you notice that the name and focus order of the component are positioned at the top. Directly beneath this, you find the control type. Any notes you may have will be displayed in the edit box and will appear in the third column at the top.Moving down, properties are listed below the notes section. Some components have specific properties, and these will be represented by checkboxes for easy selection. Additionally, any custom keyboard shortcuts can be configured in the section below the properties. This is where you can input shortcuts such as 'Alt' and specify the desired action. If a shortcut involves multiple key presses, you can use the plus sign to add another keyboard press. It's important to note that these are custom keyboard shortcuts and aren't typically included within the component itself. Common keys like Enter and Space, which is natural parts of most components, don't need to be specified." lightbox="../media/pluginui.png":::
97+
:::image type="content" source="../media/pluginui.png" alt-text="Screenshot of When editing the component itself in the component UI, you notice that the name and focus order of the component are positioned at the top. Directly beneath this, you find the control type. Any notes you may have will be displayed in the edit box and will appear in the third column at the top. Moving down, properties are listed below the notes section. Some components have specific properties, and these will be represented by checkboxes for easy selection. Additionally, any custom keyboard shortcuts can be configured in the section below the properties. This is where you can input shortcuts such as 'Alt' and specify the desired action. If a shortcut involves multiple key presses, you can use the plus sign to add another keyboard press. It's important to note that these are custom keyboard shortcuts and aren't typically included within the component itself. Common keys like Enter and Space, which is natural parts of most components, don't need to be specified." lightbox="../media/pluginui.png":::

learn-pr/cela-accessibility/accessibility-design-specs-with-annotations/includes/3-annotations-for-keyboard-ascreen-reader-navigation.md

Lines changed: 4 additions & 4 deletions
Original file line numberDiff line numberDiff line change
@@ -12,13 +12,13 @@ Indicate the sequence in which interactive elements should receive focus when na
1212

1313
#### Name, role, and state
1414

15-
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 fied to user agents, including assistive technologies, so that users are always aware of the current state and can interact with the interface accordingly.
15+
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.
1616

17-
For the library components, "Name" will be same as per the design and same will be announce 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.
17+
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.
1818

1919
:::image type="content" source="../media/screen-reader-annotations-widget-dialog-specs.png" alt-text="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." lightbox="../media/screen-reader-annotations-widget-dialog-specs.png":::
2020

21-
When we have multiple components with the same visual name then we should override the visual name. Why should we do this? We have different navigations 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.
21+
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.
2222

2323
:::image type="content" source="../media/keyboardandscreenreader-annotationswithmultiplecontrolswithsamenamewidgetdialogspecs.png" alt-text="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." lightbox="../media/keyboardandscreenreader-annotationswithmultiplecontrolswithsamenamewidgetdialogspecs.png":::
2424

@@ -32,7 +32,7 @@ States are critical only if they're illustrating a flow or a specific condition
3232

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

35-
:::image type="content" source="../media/shortcut-keys-accessibility-annotation.png" alt-text="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." lightbox="../media/shortcut-keys-accessibility-annotation.png":::
35+
:::image type="content" source="../media/shortcut-keys-accessibility-annotation.png" alt-text="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." lightbox="../media/shortcut-keys-accessibility-annotation.png":::
3636

3737
:::image type="content" source="../media/keyboard-interactions-accessibility-annotations.png" alt-text="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." lightbox="../media/keyboard-interactions-accessibility-annotations.png":::
3838

0 commit comments

Comments
 (0)