开发人员的无障碍功能指南

From mediawiki.org
This page is a translated version of the page Accessibility guide for developers and the translation is 19% complete.
Languages:

无障碍对我们的用户而言是很重要的功能。通过考虑一些基本的想法和规则，我们可以改进页面的无障碍功能。 实现无障碍功能是困难的。因为没有固定的和普遍接受的技术标准来适用于所有用户。 本页面并未列出或讨论MediaWiki中特定的无障碍功能问题。 它试图重注在技术选择和「该做」与「不该做」上，以防止出现无障碍问题。

就开发方面來說，我认为这应该是我们的比賽规则手册：

  • 尝试賦予用户（這指的是所有的用户）能力
  • 尝试儘可能解决无障碍功能的问题，但並非是不惜代价
  • 我们应该使用渐进增强的方法而不是從容退化的方法。
  • 实现在技术上已很健全的事情

如何達到无障碍

有些你应该记住的重要概念。

衡量无障碍功能的多种方式

无障碍功能涉及很多方面，请考虑以下几点：

  • 事情應該是要可以能被了解的：這指的是從文本性、视觉性、逻辑性、和复杂性。
  • 一些用户需要屏幕阅读器来进行交互，但同样常见的还有：更高的对比度的放大镜、文本转语音引擎、自定义 CSS 设置、或特殊类型的键盘/输入设备。
  • 它必需是可以達到的；这包括同情心、可负担性、位置、语言、硬件等。

总之，无障碍功能不仅仅是键盘无障碍，或者仅仅是屏幕阅读器无障碍。 我们经常关注这两个功能，因为它们在传统上很容易被忽视。 但是这些问题也是可以解决的，并且通常为其他类型的改进提供基础。

一些无障碍问题往往是产品设计、战略选择、目标受众等方面的问题。 由于这些领域在普遍适用于MediaWiki生态系统中更难以落实为书面规则，因此它们超出了本文档的范围。

键盘导航

我们称之为键盘导航，但它的真正含义是：不要依赖指示设备（触控、鼠标）。

  • 键盘导航是关于使用键盘操纵聚焦和执行操作動作。
  • 可分页的元素是可聚焦的，但并非所有可聚焦的元素都可分页。
  • 用鼠标可以做的一切都应该可以用键盘来做。
  • 屏幕阅读器可以使用键盘导航信息来提升他们的用户体验。

屏幕阅读器

  • A screen reader uses a different 'cursor', which usually walks the logical structure of the DOM.
  • The focus tends to follow the screen reader cursor and vice versa, but they are not the same
    • You can keep track of the focused element by setting a live expression in Chrome [1]
  • A screen reader uses the 'accessibility' APIs, which you could consider to be an input/output 'view' on top of the normal DOM.
  • ARIA are DOM annotations that enhance or manipulate how the DOM logic is transformed into the accessibility APIs. 這並不是HTML或JavaScript的適當替代方案。 Keyboard navigation is simply achieved by logical DOM orderǃ For more on ARIA see w3.org explanation and MDN explanation.
  • A screen reader is not limited to navigating by the logical DOM structure, it's just the default.
    • A screen reader can read what is under the mouse pointer for instance
    • VoiceOver for iOS uses a screen cursor that is manipulated by thumb positioning and gestures on the touch screen.
    • Most screen reader software has additional navigation modes, where you can list and navigate by landmark areas, an auto-generated Table of Contents, or even user defined 'bookmarks' inside a page.
  • From the above point of multiple navigation methods, follows: There is a beginning and an end, but also left, right, top and bottom. You should not rely on these in your communication too much, but you don't need to fully deny their existence either. Do not confuse the visual capabilities of the user with spatial awareness that the screen reader might be able to convey to the user. Example:
    1. a long sentence [image] the above image shows... Still acceptable
    2. a long sentence [image][image] the left image shows, the right image shows... Still acceptable
    3. a long sentence [image][image] the right image shows, the left image shows... Not acceptable
    4. a long sentence [image][image] the above image shows... Not acceptable
    5. a long sentence [image][image][image] the left image shows, the right image shows... Not acceptable
    6. a long sentence [image][image] something totally different. the left image shows, the right image shows... Definitely not acceptable

开发指引

There are several standards around accessibility and honestly, almost all of them, although sound on identifying issues, still have significant problems when it comes to technical solutions (They have a high ratio of 'ugly workarounds'). This has been cause of much controversy in the communities. As such, we should identify uncontroversial stuff that we should simply always (or never) do and why. It's much easier to reach certain goals if we separate the uncontroversial stuff from the controversial stuff.

始终使用或提供

Proper semantic HTML element
Use HTML elements for their intended purpose. For example:
  • Use ‎<button> and not ‎<div> or ‎<span> or ‎<a> with a click handler
  • If you feel the need to bold something, consider if it is not more appropriate to use a header or a strong element
Logical heading structure
All pages should always have a logical and consistent heading structure. Headings are one of the primary navigation tools used by screen reader users.
  1. There should be no gaps in the nesting of the heading levels. (So no H2->H4.)
  2. Headings should be descriptive
  3. Headings should be unique within their own level. (There should not be two H3s with the same content under the same H2 section)
  4. There should be separation between navigation and content
alt attribute for images with meaningful values
If an image is decorative, use an explicit empty value for the alt attribute; even better, turn it into a CSS background image.
the image alt usually takes precedence over the title attribute of images and even over the title attribute of links that wrap an image.
title attribute for links
These are usually shown as the tooltips
Only use titles if they differ from the link text.
Most link titles are not actually spoken by screen readers, unless the reader has been explicitly configured this way.
lang, dir and hreflang attributes
Using lang and hreflang enables selecting a proper voice in screen readers, picks the right spelling correction in browsers etc.
Sufficient contrast
Always check your colors for sufficient contrast. For text, a higher contrast is needed for smaller text (due to anti-aliasing).
Focus for keyboard navigation
Do not remove outline from focusable elements unless you define your own outline for the :focus state.
  • Don't use outline: 0 otherwise.
  • If you define any pseudo class, like :hover or :active, please also define a :focus style.
Keyboard navigation
Interactive elements of a page should be navigable by keyboard. Please make sure tab key navigation is enabled in your browser and allows you to control each interactive element without making use of a pointing device.
  1. Use tabIndex: 0 to make elements keyboard accessible, which are not keyboard accessible implicitly (Anything but ‎<a>, ‎<area>, ‎<button>, ‎<input>, ‎<object>, ‎<select>, ‎<textarea>).
    1. In this case also add a keydown handler responding to Enter (keyCode 13) and space (keyCode 32).
  2. Use tabindex: -1 to remove elements from accessibility. (use this on links that are labels for the action inside an ‎<li>...‎</li> for instance)
  3. Elements that are implicitly keyboard accessible will forward enter/space keydown to the click handler
Dialogs etc.

When not taking good care of accessibility, dialogs are some of the most inaccessible elements for screen reader and keyboard users. Spend some time on this.

  • The element that opens the dialog should have aria-haspopup
  • The dialog itself should have role=[dialog | alertdialog | tooltip]
  • The dialog should be inserted in DOM order,[1] or aria owns/controls needs to specify this relation between opening element and dialog
  • When opening the dialog, remember last focused element and shift focus to the first focusable tabbable element inside the dialog
  • When the dialog is modal, make it impossible to interact with the rest of the page
    • Capture clicks outside the dialog and ignore them or let them dismiss the dialog
    • Make sure you cannot tab to links or input elements outside of dialog
    • Make elements outside of the dialog unreachable for screen reader, by using aria-hidden
  • Make sure there is a close mode (Esc key and a focusable close button with a descriptive title)
  • Closing should return the (keyboard) focus to the original focus point that you stored when you opened the dialog. For screen readers to return to the same point, be sure to specify the right owner of the dialog, if you have not inserted the dialog in DOM order.
  • Read up: Aria modals, Aria modal dialog, ARIA nonmodal dialog, ARIA tooltips.
WCAG 2.1 guidelines
Follow wherever possible
And its accompanying documents:

不要做的

  • There is common advice to use left: -1000px to push something (often the labels of icon buttons) out of the viewport for visual users and still have it in the accessibility DOM. text-indent: -9999px is variant of this. This is BAD advice.
    • This breaks our RTL rendering in several browsers. Specifically in rtl mode it creates a large canvas left of the viewport and scrollbars, much as +1000px would create in ltr mode. (If needed, top: -1000px is preferred over left: -1000px to avoid this).
    • VoiceOver on mobile is unable to use this text as a fallback, since it is a 'positional' screen reader. You cannot move your finger over this text and thus the text will not be read either. (aria-label is often the better choice).
    • Lastly, this enlarges the render surface needed to calculate the final webpage and this can impact performance [2] on mobile devices.
    • Insightful overview of 'hide text offscreen' tricks are given by Jonathan Snook.
  • Things should not be repeated often. If you have a 100 links on a page that can open a dialog, then don't add 100 labels to those 100 links telling the user that it can be used to open a dialog. Telling a user how to use/what to do with the interface is a good thing, doing it consistently is simply annoying. Find a different way to explain it once (an aria-live=polite might be an idea in this case ?).
  • <a href="#">Hide</a> with an onclick handler. VO reads such JS as "internal link Hide". Use a proper button, or <a role="button" tabindex="0">Hide</a>, with 'Space' and 'Enter' key handlers in the onclick. But no href attribute.
  • Do not nest interactive functionality inside another interactive element (links or buttons inside links). This confuses screen readers.

避免

Unicode symbols
Most assistive technologies are not good with symbols. Therefore, try to avoid characters such as ↑, →‎ or more complex characters, because many screen reader won't understand them. If they are required, try to wrap with a span element with the title attribute, so that the title attribute can communicate the implicit meaning within the context to the reader.
Small fonts
Legibility is preferred. If you make something so small that it is hard to read, do you even need it to begin with? Also avoid small fonts with low or mediocre contrast values (even if they fall inside the WCAG guidelines, small sizes require more explicit contrast then large sizes, especially with anti aliasing enabled).
Unusually large fonts
If you make text much larger than normal, it can become similarly hard to read (unless it's very short). This applies mostly to body text, or anything that takes up more than a couple lines. But the larger the text is, the more lines it will take up.
tabIndex > 0
DOM order is preferred wherever possible. DOM order provides context for the actions.
Workaround
Traditionally, accomplishing 'full' accessibility has required a lot of workarounds for html itself, the browsers and even specific screenreader software. However these workarounds often come with side effects, make use of bugs or unspecified behavior and inevitably create technical debt.
MediaWiki, because of the users it seeks to serve, the amount of code, it's (lack) of funding, etc tends to prefer future proof code over code that easily breaks. As such it generally avoids workarounds even if that might sometimes limit the accessibility we can deliver. Decisions on this are often influenced by the relative audience of the feature in MediaWiki. If something is ubiquitous for all users a workaround is more warrented than if the feature affected is only used by a tiny part of the audience (for instance, reading a page vs modifying the configuration of the installation).

考虑

  • ARIA Roles
    • If a div or span behaves like an actual button use role="button". also role="dialog" and role="alert"
    • Be careful with roles. For instance, don't add role="button" to a ‎<th> element, since the ‎<th> element has an implicit role="columnheader", which will be overwritten. Instead use nested elements. Similarly for ‎<li> which has an implicit role="listitem"
    • If a button creates a popupdialog, use aria-haspopup.
    • Use aria-labelled-by for contexts where this is not fully logical by itself (so everywhere except for labels in forms and headers in tables).
  • Avoid tables for layout purposes and test on smaller screen widths.
  • hide stuff: https://www.tpgi.com/html5-accessibility-chops-hidden-and-aria-hidden/
  • skip/jump to links

參見

參考資料

  1. ↑ See DOM order at w3.org and Style order Property at w3schools.org
Retrieved from "https://www.mediawiki.org/w/index.php?title=Accessibility_guide_for_developers/zh&oldid=6335307"