You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: learn-pr/cela-accessibility/accessibility-design-specs-with-annotations/2-overview-of-accessibility-annotation.yml
Copy file name to clipboardExpand all lines: learn-pr/cela-accessibility/accessibility-design-specs-with-annotations/3-annotations-for-keyboard-ascreen-reader-navigation.yml
Copy file name to clipboardExpand all lines: learn-pr/cela-accessibility/accessibility-design-specs-with-annotations/4-design-for-color-contrast-requirements.yml
description: This is the knowledge check for the accessibility design specs with annotations module.
@@ -16,16 +16,16 @@ quiz:
16
16
choices:
17
17
- content: To make designs look more colorful
18
18
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.
20
20
- content: To ensure designs can be used by all users, including those with disabilities
21
21
isCorrect: true
22
22
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.
23
23
- content: To provide additional information about the design process
24
24
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.
26
26
- content: To document the design process
27
27
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.
29
29
30
30
- content: Which of the following is a critical consideration when implementing keyboard navigation in designs?
Copy file name to clipboardExpand all lines: learn-pr/cela-accessibility/accessibility-design-specs-with-annotations/includes/2-overview-of-accessibility-annotation.md
+5-5Lines changed: 5 additions & 5 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -12,7 +12,7 @@ Familiarizing yourself with key terms is essential for effectively implementing
12
12
13
13
-**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.
14
14
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.
16
16
17
17
-**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.
18
18
@@ -34,15 +34,15 @@ Familiarizing yourself with key terms is essential for effectively implementing
34
34
-**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.
35
35
36
36
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.
38
38
39
39
-**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.
40
40
41
41
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.
42
42
43
43
## Annotation principles:
44
44
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.
46
46
47
47
1. Understandable: I know what I can do
48
48
@@ -66,7 +66,7 @@ Habituating: Users can't help but learn habits. And habits are developed automat
66
66
67
67
- 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.
68
68
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.
70
70
71
71
- Ensure reflow readiness. Pro tip: Auto layouts are best to design for reflow.
72
72
@@ -94,4 +94,4 @@ When we start the spec, name and focus order will be on the top when editing the
94
94
95
95
:::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":::
96
96
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":::
Copy file name to clipboardExpand all lines: learn-pr/cela-accessibility/accessibility-design-specs-with-annotations/includes/3-annotations-for-keyboard-ascreen-reader-navigation.md
+4-4Lines changed: 4 additions & 4 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -12,13 +12,13 @@ Indicate the sequence in which interactive elements should receive focus when na
12
12
13
13
#### Name, role, and state
14
14
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.
16
16
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.
18
18
19
19
:::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":::
20
20
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.
22
22
23
23
:::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":::
24
24
@@ -32,7 +32,7 @@ States are critical only if they're illustrating a flow or a specific condition
32
32
33
33
Highlight Add any keyboard shortcuts that aren't standard rather a customize one and can be used to perform actions within the design.
34
34
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":::
36
36
37
37
:::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":::
0 commit comments