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: hub/apps/design/accessibility/accessibility-in-the-store.md
+1-1Lines changed: 1 addition & 1 deletion
Original file line number
Diff line number
Diff line change
@@ -39,7 +39,7 @@ You should declare your app as accessible if you built and tested it for accessi
39
39
40
40
See the [Accessibility checklist](accessibility-checklist.md) for a review of these procedures and links to resources that will help you accomplish them.
Copy file name to clipboardExpand all lines: hub/apps/design/accessibility/accessibility-overview.md
+36-36Lines changed: 36 additions & 36 deletions
Original file line number
Diff line number
Diff line change
@@ -15,9 +15,9 @@ This article is an overview of the concepts and technologies related to accessib
15
15
16
16
17
17
18
-
<spanid="Accessibility_and_your_app"/>
19
-
<spanid="accessibility_and_your_app"/>
20
-
<spanid="ACCESSIBILITY_AND_YOUR_APP"/>
18
+
<spanid="Accessibility_and_your_app"></span>
19
+
<spanid="accessibility_and_your_app"></span>
20
+
<spanid="ACCESSIBILITY_AND_YOUR_APP"></span>
21
21
22
22
## Accessibility and your app
23
23
@@ -31,17 +31,17 @@ Controls for XAML provide built-in keyboard support and support for assistive te
31
31
32
32
In addition, data binding, style, and template features make it easy to implement support for dynamic changes to display settings and text for alternative UIs.
33
33
34
-
<spanid="UI_Automation"/>
35
-
<spanid="ui_automation"/>
36
-
<spanid="UI_AUTOMATION"/>
34
+
<spanid="UI_Automation"></span>
35
+
<spanid="ui_automation"></span>
36
+
<spanid="UI_AUTOMATION"></span>
37
37
38
38
## UI Automation
39
39
40
40
Accessibility support comes primarily from the integrated support for the Microsoft UI Automation framework. That support is provided through base classes and the built-in behavior of the class implementation for control types, and an interface representation of the UI Automation provider API. Each control class uses the UI Automation concepts of automation peers and automation patterns that report the control's role and content to UI Automation clients. The app is treated as a top-level window by UI Automation, and through the UI Automation framework all the accessibility-relevant content within that app window is available to a UI Automation client. For more info about UI Automation, see [UI Automation Overview](/windows/desktop/WinAuto/uiauto-uiautomationoverview).
41
41
42
-
<spanid="Assistive_technology"/>
43
-
<spanid="assistive_technology"/>
44
-
<spanid="ASSISTIVE_TECHNOLOGY"/>
42
+
<spanid="Assistive_technology"></span>
43
+
<spanid="assistive_technology"></span>
44
+
<spanid="ASSISTIVE_TECHNOLOGY"></span>
45
45
46
46
## Assistive technology
47
47
@@ -59,9 +59,9 @@ Apps that have good keyboard and screen reader support usually work well with va
59
59
60
60
Some of the options that you can use for testing basic accessibility scenarios with assistive technologies are listed in [Accessibility testing](accessibility-testing.md).
## Screen reader support and basic accessibility information
67
67
@@ -73,27 +73,27 @@ The most important information that a screen reader or any other assistive techn
73
73
74
74
There are several other automation properties available (including the keyboard properties described in the next section). However, not all screen readers support all automation properties. In general, you should set all appropriate automation properties and test to provide the widest possible support for screen readers.
75
75
76
-
<spanid="Keyboard_support"/>
77
-
<spanid="keyboard_support"/>
78
-
<spanid="KEYBOARD_SUPPORT"/>
76
+
<spanid="Keyboard_support"></span>
77
+
<spanid="keyboard_support"></span>
78
+
<spanid="KEYBOARD_SUPPORT"></span>
79
79
80
80
## Keyboard support
81
81
82
82
To provide good keyboard support, you must ensure that every part of your application can be used with a keyboard. If your app uses mostly the standard controls and doesn't use any custom controls, you are most of the way there already. The basic XAML control model provides built-in keyboard support including tab navigation, text input, and control-specific support. The elements that serve as layout containers (such as panels) use the layout order to establish a default tab order. That order is often the correct tab order to use for an accessible representation of the UI. If you use [**ListBox**](/uwp/api/Windows.UI.Xaml.Controls.ListBox) and [**GridView**](/uwp/api/Windows.UI.Xaml.Controls.GridView) controls to display data, they provide built-in arrow-key navigation. Or if you use a [**Button**](/uwp/api/Windows.UI.Xaml.Controls.Button) control, it already handles the Spacebar or Enter keys for button activation.
83
83
84
84
For more info about all the aspects of keyboard support, including tab order and key-based activation or navigation, see [Keyboard accessibility](keyboard-accessibility.md).
85
85
86
-
<spanid="Media_and_captioning"/>
87
-
<spanid="media_and_captioning"/>
88
-
<spanid="MEDIA_AND_CAPTIONING"/>
86
+
<spanid="Media_and_captioning"></span>
87
+
<spanid="media_and_captioning"></span>
88
+
<spanid="MEDIA_AND_CAPTIONING"></span>
89
89
90
90
## Media and captioning
91
91
92
92
You typically display audiovisual media through a [**MediaElement**](/uwp/api/Windows.UI.Xaml.Controls.MediaElement) object. You can use **MediaElement** APIs to control the media playback. For accessibility purposes, provide controls that enable users to play, pause, and stop the media as needed. Sometimes, media includes additional components that are intended for accessibility, such as captioning or alternative audio tracks that include narrative descriptions.
93
93
94
-
<spanid="Accessible_text"/>
95
-
<spanid="accessible_text"/>
96
-
<spanid="ACCESSIBLE_TEXT"/>
94
+
<spanid="Accessible_text"></span>
95
+
<spanid="accessible_text"></span>
96
+
<spanid="ACCESSIBLE_TEXT"></span>
97
97
98
98
## Accessible text
99
99
@@ -103,17 +103,17 @@ Three main aspects of text are relevant to accessibility:
103
103
* Many users have sight limitations that make it difficult for them to read text unless it has adequate contrast against the background. How this impacts the user is not intuitive for app designers who do not have that sight limitation. For example, for color-blind users, poor color choices in the design can prevent some users from being able to read the text. Accessibility recommendations that were originally made for web content define standards for contrast that can avoid these problems in apps as well. For more info, see [Accessible text requirements](accessible-text-requirements.md).
104
104
* Many users have difficulty reading text that is simply too small. You can prevent this issue by making the text in your app's UI reasonably large in the first place. However, that's challenging for apps that display large quantities of text, or text interspersed with other visual elements. In such cases, make sure that the app correctly interacts with the system features that can scale up the display, so that any text in apps scales up along with it. (Some users change dpi values as an accessibility option. That option is available from **Make things on the screen larger** in **Ease of Access**, which redirects to a **Control Panel** UI for **Appearance and Personalization** / **Display**.)
105
105
106
-
<spanid="Supporting_high-contrast_themes"/>
107
-
<spanid="supporting_high-contrast_themes"/>
108
-
<spanid="SUPPORTING_HIGH-CONTRAST_THEMES"/>
106
+
<spanid="Supporting_high-contrast_themes"></span>
107
+
<spanid="supporting_high-contrast_themes"></span>
108
+
<spanid="SUPPORTING_HIGH-CONTRAST_THEMES"></span>
109
109
110
110
## Supporting high-contrast themes
111
111
112
112
UI controls use a visual representation that is defined as part of a XAML resource dictionary of themes. One or more of these themes is specifically used when the system is set for high contrast. When the user switches to high contrast, by looking up the appropriate theme from a resource dictionary dynamically, all your UI controls will use an appropriate high-contrast theme too. Just make sure that you haven't disabled the themes by specifying an explicit style or using another styling technique that prevents the high-contrast themes from loading and overriding your style changes. For more info, see [High-contrast themes](high-contrast-themes.md).
## Assistive technology support in custom controls
188
188
189
189
When you create a custom control, we recommend that you also implement or extend one or more [**AutomationPeer**](/uwp/api/Windows.UI.Xaml.Automation.Peers.AutomationPeer) subclasses to provide accessibility support. In some cases, so long as you use the same peer class as was used by the base control class, the automation support for your derived class is adequate at a basic level. However, you should test this, and implementing a peer is still recommended as a best practice so that the peer can correctly report the class name of your new control class. Implementing a custom automation peer has a few steps involved. For more info, see [Custom automation peers](custom-automation-peers.md).
Copy file name to clipboardExpand all lines: hub/apps/design/accessibility/accessible-text-requirements.md
+18-18Lines changed: 18 additions & 18 deletions
Original file line number
Diff line number
Diff line change
@@ -16,8 +16,8 @@ ms.localizationpriority: medium
16
16
17
17
This topic describes best practices for accessibility of text in an app, by assuring that colors and backgrounds satisfy the necessary contrast ratio. This topic also discusses the Microsoft UI Automation roles that text elements in a Universal Windows Platform (UWP) app can have, and best practices for text in graphics.
18
18
19
-
<spanid="contrast_rations"/>
20
-
<spanid="CONTRAST_RATIONS"/>
19
+
<spanid="contrast_rations"></span>
20
+
<spanid="CONTRAST_RATIONS"></span>
21
21
22
22
## Contrast ratios
23
23
Although users always have the option to switch to a high-contrast mode, your app design for text should regard that option as a last resort. A much better practice is to make sure that your app text meets certain established guidelines for the level of contrast between text and its background. Evaluation of the level of contrast is based on deterministic techniques that do not consider color hue. For example, if you have red text on a green background, that text might not be readable to someone with a color blindness impairment. Checking and correcting the contrast ratio can prevent these types of accessibility issues.
@@ -33,9 +33,9 @@ Use color contrast tools to verify that the visible text contrast ratio is accep
33
33
> [!NOTE]
34
34
> Some of the tools listed by Techniques for WCAG 2.0 G18 can't be used interactively with a UWP app. You may need to enter foreground and background color values manually in the tool, or make screen captures of app UI and then run the contrast ratio tool over the screen capture image.
35
35
36
-
<spanid="Text_element_roles"/>
37
-
<spanid="text_element_roles"/>
38
-
<spanid="TEXT_ELEMENT_ROLES"/>
36
+
<spanid="Text_element_roles"></span>
37
+
<spanid="text_element_roles"></span>
38
+
<spanid="TEXT_ELEMENT_ROLES"></span>
39
39
40
40
## Text element roles
41
41
A UWP app can use these default elements (commonly called *text elements* or *textedit controls*):
@@ -49,9 +49,9 @@ When a control reports that is has a role of [**Edit**](/uwp/api/Windows.UI.Xaml
49
49
50
50
In the text models for XAML, there are two elements that are primarily used for static text, [**TextBlock**](/uwp/api/Windows.UI.Xaml.Controls.TextBlock) and [**RichTextBlock**](/uwp/api/Windows.UI.Xaml.Controls.RichTextBlock). Neither of these are a [**Control**](/uwp/api/Windows.UI.Xaml.Controls.Control) subclass, and as such neither of them are keyboard-focusable or can appear in the tab order. But that does not mean that assistive technologies can't or won't read them. Screen readers are typically designed to support multiple modes of reading the content in an app, including a dedicated reading mode or navigation patterns that go beyond focus and the tab order, like a "virtual cursor". So don't put your static text into focusable containers just so that tab order gets the user there. Assistive technology users expect that anything in the tab order is interactive, and if they encounter static text there, that is more confusing than helpful. You should test this out yourself with Narrator to get a sense of the user experience with your app when using a screen reader to examine your app's static text.
51
51
52
-
<spanid="Auto-suggest_accessibility"/>
53
-
<spanid="auto-suggest_accessibility"/>
54
-
<spanid="AUTO-SUGGEST_ACCESSIBILITY"/>
52
+
<spanid="Auto-suggest_accessibility"></span>
53
+
<spanid="auto-suggest_accessibility"></span>
54
+
<spanid="AUTO-SUGGEST_ACCESSIBILITY"></span>
55
55
56
56
## Auto-suggest accessibility
57
57
When a user types into an entry field and a list of potential suggestions appears, this type of scenario is called auto-suggest. This is common in the **To:** line of a mail field, the Cortana search box in Windows, the URL entry field in Microsoft Edge, the location entry field in the Weather app, and so on. If you are using a XAML [**AutosuggestBox**](/uwp/api/windows.ui.xaml.controls.autosuggestbox) or the HTML intrinsic controls, then this experience is already hooked up for you by default. To make this experience accessible the entry field and the list must be associated. This is explained in the [Implementing auto-suggest](#implementing_auto-suggest) section.
@@ -67,9 +67,9 @@ Narrator has been updated to make this type of experience accessible with a spec
To make this experience accessible the entry field and the list must be associated in the UIA tree. This association is done with the [UIA_ControllerForPropertyId](/windows/win32/winauto/uiauto-automation-element-propids) property in desktop apps or the [ControlledPeers](/uwp/api/windows.ui.xaml.automation.automationproperties.getcontrolledpeers) property in UWP apps.
@@ -104,17 +104,17 @@ If you are using the intrinsic controls in HTML, then the UIA implementation has
104
104
105
105
If you are creating your own controls, you must set up your own ARIA controls, which are explained in the W3C standards.
106
106
107
-
<spanid="Text_in_graphics"/>
108
-
<spanid="text_in_graphics"/>
109
-
<spanid="TEXT_IN_GRAPHICS"/>
107
+
<spanid="Text_in_graphics"></span>
108
+
<spanid="text_in_graphics"></span>
109
+
<spanid="TEXT_IN_GRAPHICS"></span>
110
110
111
111
## Text in graphics
112
112
113
113
Whenever possible, avoid including text in a graphic. For example, any text that you include in the image source file that is displayed in the app as an [**Image**](/uwp/api/Windows.UI.Xaml.Controls.Image) element is not automatically accessible or readable by assistive technologies. If you must use text in graphics, make sure that the [**AutomationProperties.Name**](/dotnet/api/system.windows.automation.automationproperties.name) value that you provide as the equivalent of "alt text" includes that text or a summary of the text's meaning. Similar considerations apply if you are creating text characters from vectors as part of a [**Path**](/uwp/api/Windows.UI.Xaml.Shapes.Path), or by using [**Glyphs**](/uwp/api/Windows.UI.Xaml.Documents.Glyphs).
114
114
115
-
<spanid="Text_font_size"/>
116
-
<spanid="text_font_size"/>
117
-
<spanid="TEXT_FONT_SIZE"/>
115
+
<spanid="Text_font_size"></span>
116
+
<spanid="text_font_size"></span>
117
+
<spanid="TEXT_FONT_SIZE"></span>
118
118
119
119
## Text font size and scale
120
120
@@ -173,7 +173,7 @@ These types have an **IsTextScaleFactorEnabled** property:
0 commit comments