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-accessibility-annotation.yml
Copy file name to clipboardExpand all lines: learn-pr/cela-accessibility/accessibility-design-specs-with-annotations/3-annotations-for-keyboard-screen-reader-navigation.yml
Copy file name to clipboardExpand all lines: learn-pr/cela-accessibility/accessibility-design-specs-with-annotations/5-knowledge-check.yml
+1-1Lines changed: 1 addition & 1 deletion
Original file line number
Diff line number
Diff line change
@@ -47,7 +47,7 @@ quiz:
47
47
- content: By providing visual cues for navigation
48
48
isCorrect: false
49
49
explanation: Incorrect. While visual cues and layout information are important, screen reader annotations primarily help users understand the purpose and interaction of elements, enabling better accessibility.
50
-
- content: By conveying information about the type, purpose and specific capabilities of each instance of controls of a page.
50
+
- content: By conveying information about the type, purpose and specific capabilities of each instance of controls of a page
51
51
isCorrect: true
52
52
explanation: Correct. Screen reader annotations are crucial for conveying information about how to interact with elements. These annotations ensure that screen reader users can understand the function of different elements, like buttons and links, so they can navigate and interact effectively.
53
53
- content: By informing users about the layout and design
Copy file name to clipboardExpand all lines: learn-pr/cela-accessibility/accessibility-design-specs-with-annotations/includes/2-overview-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
@@ -44,11 +44,11 @@ You can avoid many accessibility issues by planning for them during the design p
44
44
45
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
-
1. Understandable: I know what I can do
47
+
- Understandable: I know what I can do
48
48
49
-
1. Efficient: I take fewer steps and process less information
49
+
- Efficient: I take fewer steps and process less information
50
50
51
-
1. Habituating: I quickly achieve command
51
+
- Habituating: I quickly achieve command
52
52
53
53
Understandable: **When a UI has already been learned it's understood**. The user is aware of the actions they can take because they have already been exposed to the concepts. When a UI is understandable, the user is aware of the actions they can take because the UI contains **concepts that are learned quickly**. For example, on a website if a task is time bound, and it has timer displaying in the top then it should be announced to the assistive technology users so that they'll not miss this information. We should decide what should be the right interval to avoid making announcements too verbose.
54
54
@@ -84,7 +84,7 @@ Parent Component – A **parent component** refers to a component that contains
84
84
85
85
Child Component - A **child component** refers to an individual element that is nested inside a **parent component.**
The plug-in will create a table that has all the components listed out and they're here in the table shown below in the image. A diamond shaped thing is a library component which is an established library with some minor tweaks that are good to use and populate details automatically. Custom Components denoted as circle, are a composite of certain controls and need to set up many properties for them. And then if necessary custom components can have a parent and have children. For example, grid is a parent and grid item are a child component. Another example is that radio groups are parents and radio button are a child component.
90
90
@@ -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/plugin-ui.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/plugin-ui.png":::
Copy file name to clipboardExpand all lines: learn-pr/cela-accessibility/accessibility-design-specs-with-annotations/includes/3-annotations-for-keyboard-screen-reader-navigation.md
+3-3Lines changed: 3 additions & 3 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -4,7 +4,7 @@ Annotations for keyboard accessibility help designers communicate how users can
4
4
5
5
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.
6
6
7
-
1. Use the focus order indicators to show the intended ordering of elements when being navigated using a keyboard.
7
+
- Use the focus order indicators to show the intended ordering of elements when being navigated using a keyboard.
8
8
9
9
:::image type="content" source="../media/focus-order-accessibility-annotation-wishcart-application.png" alt-text="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." lightbox="../media/focus-order-accessibility-annotation-wishcart-application.png":::
10
10
@@ -20,9 +20,9 @@ For the library components, "Name" will be same as per the design and same will
20
20
21
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
-
:::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":::
23
+
:::image type="content" source="../media/keyboard-same.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/keyboard-same.png":::
24
24
25
-
:::image type="content" source="../media/keyboardandscreenreader-annotationswithmultiplecontrolswithdifferentnamewidgetdialogspecs.png" alt-text="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." lightbox="../media/keyboardandscreenreader-annotationswithmultiplecontrolswithdifferentnamewidgetdialogspecs.png":::
25
+
:::image type="content" source="../media/keyboard-diff.png" alt-text="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." lightbox="../media/keyboard-diff.png":::
26
26
27
27
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.
0 commit comments