Sdílet prostřednictvím

Practices to avoid for accessible apps (HTML)

  • Článek

[This article is for Windows 8.x and Windows Phone 8.x developers writing Windows Runtime apps. If you’re developing for Windows 10, see the latest documentation]

Looking for the C#/VB/C++/XAML version of this topic? See Practices to avoid for accessible apps (XAML).

Avoid the following practices if you want your Windows Runtime app using JavaScript to be accessible.

  • Avoid building custom UI elements if you can use standard HTML tags or the controls included with the Windows Runtime framework. Building a custom UI element, typically by using the div tag, requires more work for accessibility. Standard HTML tags and Windows Runtime controls are accessible by default, and you might only need to set a control's accessible name to make it fully accessible.
  • Don't put static text or other non-interactive elements into the tab order (for example, by setting the tabIndex attribute greater than 0 for an element that is not interactive). Having non-interactive elements in the tab order is against keyboard accessibility guidelines because it decreases efficiency of keyboard navigation. Text-only elements in the tab order can confuse users who expect only interactive elements in the tab order (buttons, check boxes, text input fields, combo boxes, lists, and so on).
  • Don’t set the role attribute to an arbitrary value because that does not take advantage of the accessibility support that is built into the Windows Runtime platform. Setting an element's role attribute to a valid (non-abstract) Web Accessibility Initiative - Accessible Rich Internet Applications (WAI-ARIA) role value is the best way to enable the platform to correctly represent the element to screen readers and other assistive technology tools.
  • Avoid using custom Cascading Style Sheets (CSS) absolute positioning of UI elements. Whenever possible, lay out UI elements in document or logical order to ensure that screen readers can read the UI elements in the correct order. If the visible order of UI elements can diverge from the document or logical order, use the aria-flowto an x-ms-aria-flowfrom attributes to define the correct reading order.
  • Don’t use color as the only way to convey information. Users who are color blind cannot receive information that is conveyed only through color, such as a color status indicator. Include other visual cues, preferably text, to ensure that information is accessible.
  • Don’t automatically refresh an entire page. If you need to automatically refresh page content, update only certain areas of the page, and mark the areas as live regions.
  • Don’t use UI elements that flash more than three times per second. Flashing elements can cause some people to have seizures. It is best to avoid using UI elements that flash.
  • Don’t change user context or activate functionality automatically. Context or activation changes should occur only when the user takes a direct action on a UI element that has focus. Changes in user context include changing focus, displaying new content, and navigating to a different page. Making context changes without involving the user can be disorienting for users who have disabilities. The exceptions to this requirement include displaying submenus, validating forms, displaying help text in another control, and changing context in response to an asynchronous event.

Accessibility for Windows Runtime apps using JavaScript and HTML