Learn web development

HTML: 为可访问性提供一个良好的基础

这篇翻译不完整。请帮忙从英语翻译这篇文章

在网页开发的过程中,用正确的HTML标签来表达正确的意图,可以提升网页的可访问性。这篇文章将会详细介绍如何最大化地提升网页的可访问性。

前提: 有一定的HTML基础(可参阅 HTML入门),理解什么是可访问性
目标: 了解可访问性为网页带来的好处和如何在网页中进行实现。

HTML 和 可访问性

在学习HTML的过程当中,经常可以看到这样一个主题:HTML语义化的重要性。意思是指我们应尽可能地用正确的HTML标签来表达正确的意图。

你可能在想,为什么语义化对于一个网页来说如此重要。总的来说,正确的语义化可使Css和javaScript更为便利地操作网页的样式和行为。例如,一个用来操作视频播放的按钮可以写成这样一种形式:

<div>Play video</div>

接下来你将看到一种更好的写法,它使用了正确的HTML标签,看上去更加合理:

<button>Play video</button>

<button>标签不仅提供了按钮的样式(虽然有时会重新编写样式),还提供了键盘的可访问性,如:使用tab键更换按钮,使用回车键点击按钮。

如果你在项目的一开始就使用HTML语义化,不仅不会花更多的时间,而且又有以下的可访问性优点:

  1. 更便于开发 — 如上所述,你可以使HTML更易于理解,并且可以毫不费力的获得一些功能。
  2. 更适配移动端 — 语义化的HTML文件比非语义化的HTML文件更加轻便,并且更易于响应式开发。
  3. 更便于SEO优化 — 比起使用非语义化的<div>标签,搜索引擎更加重视在“标题、链接等”里面的关键字,使用语义化可使网页更容易被用户搜索到。

让我们来继续学习HTML语义化实现细则。

注意:在本地计算机上设置屏幕阅读器是一个不错的主意,因此您可以对下面显示的示例进行一些测试。更多内容请查阅 Screenreaders guide

良好的语义

上面我们讨论了语义化的重要性以及为什么我们要使用正确的HTML标签来表达正确的意图。语义化是我们不可忽视的一部分,因为它往往决定了网页的可访问性。

在网络上,事实上人们用HTML标签做一些非常奇怪的事情。人们滥用一些即将废弃或已经废弃的标签。不管在什么情况下,我们都应该将这些错误的代码改正过来。

话虽如此,但是有些情况我们往往不能摆脱错误的标签,例如一个网页是从服务端的框架生成的,或者网页上存在第三方的内容(如广告),这些都是我们所不能控制的。

我们的目标并不是“全有或全无”,实际上,你所做的每一个改进都可以提升网页的可访问性。

文本内容

对于屏幕阅读器用户来讲,最佳辅助功能之一是拥有标题,段落,列表等内容的良好结构。一个好的语义示例可能如下所示:

<h1>My heading</h1>

<p>This is the first section of my document.</p>

<p>I'll add another paragraph here too.</p>

<ol>
  <li>Here is</li>
  <li>a list for</li>
  <li>you to read</li>
</ol>

<h2>My subheading</h2>

<p>This is the first subsection of my document. I'd love people to be able to find this content!</p>

<h2>My 2nd subheading</h2>

<p>This is the second subsection of my content. I think is more interesting than the last one.</p>

我们已经准备了一个更长的文本版本,供您试用于屏幕阅读器(请查看 good-semantics.html)。如果您尝试在此过程中导航,您将看到这非常容易导航:

  1. 屏幕阅读器会在您浏览内容时读取每个标题,通知您标题是什么,段落是什么等。
  2. 它在每个元素之后停止,让你以任何适合你的速度前进。
  3. 你可以在许多屏幕阅读器中跳到下一个/上一个标题。
  4. 你还可以在许多屏幕阅读器中显示所有标题的列表,使您可以像使用便利的目录一样使用它们以查找特定内容。

人们有时会使用表现性 HTML 和换行符来编写标题,段落等,如下所示:

<font size="7">My heading</font>
<br><br>
This is the first section of my document.
<br><br>
I'll add another paragraph here too.
<br><br>
1. Here is
<br><br>
2. a list for
<br><br>
3. you to read
<br><br>
<font size="5">My subheading</font>
<br><br>
This is the first subsection of my document. I'd love people to be able to find this content!
<br><br>
<font size="5">My 2nd subheading</font>
<br><br>
This is the second subsection of my content. I think is more interesting than the last one.

如果你使用屏幕阅读器试用更长内容的版本(请查阅 bad-semantics.html),你不会有一个很好的经验 — 屏幕阅读器没有任何东西可以用作路标,所以你无法检索有用的目录,整个页面被看作一个巨大的块,所以它只是一次读出所有的内容。

除了可访问性之外,还有其他一些问题 - 使用CSS设计内容的风格更难,或者使用JavaScript来操作它比较困难,因为没有可用作选择器的元素。

使用通俗易懂的语言

你使用的语言也会影响可访问性。一般来说,你应该使用不太复杂的清晰语言,不要使用不必要的行话或俚语。这不仅有利于有认知或其他残疾的人;它有利于那些没有用母语写作的读者,年轻人...事实上是每个人!除此之外,你应该尽量避免使用没有被屏幕阅读器清楚读出的语言和字符。例如:

  • 如果可以避免的话,不要用破折号。写 5 到 7 ,来替代 5-7。
  • 展开缩写 — 写 January,来替代 Jan 。
  • 展开首字母缩略词,至少一次或两次。 首先编写 HTML,而不是写超文本标记语言或HTML。

Page layouts

In the bad old days, people used to create page layouts using HTML tables — using different table cells to contain the header, footer, side bar, main content column, etc. This is not a good idea because a screenreader will likely give out confusing readouts, especially if the layout is complex and has many nested tables.

Try our example table-layout.html example, which looks something like this:

<table width="1200">
      <!-- main heading row -->
      <tr id="heading">
        <td colspan="6">

          <h1 align="center">Header</h1>

        </td>
      </tr>
      <!-- nav menu row  -->
      <tr id="nav" bgcolor="#ffffff">
        <td width="200">
          <a href="#" align="center">Home</a>
        </td>
        <td width="200">
          <a href="#" align="center">Our team</a>
        </td>
        <td width="200">
          <a href="#" align="center">Projects</a>
        </td>
        <td width="200">
          <a href="#" align="center">Contact</a>
        </td>
        <td width="300">
          <form width="300">
            <input type="search" name="q" placeholder="Search query" width="300">
          </form>
        </td>
        <td width="100">
          <button width="100">Go!</button>
        </td>
      </tr>
      <!-- spacer row -->
      <tr id="spacer" height="10">
        <td>

        </td>
      </tr>
      <!-- main content and aside row -->
      <tr id="main">
        <td id="content" colspan="4" bgcolor="#ffffff">

          <!-- main content goes here -->
        </td>
        <td id="aside" colspan="2" bgcolor="#ff80ff" valign="top">
          <h2>Related</h2>

          <!-- aside content goes here -->

        </td>
      </tr>
      <!-- spacer row -->
      <tr id="spacer" height="10">
        <td>

        </td>
      </tr>
      <!-- footer row -->
      <tr id="footer" bgcolor="#ffffff">
        <td colspan="6">
          <p>©Copyright 2050 by nobody. All rights reversed.</p>
        </td>
      </tr>
    </table>

If you try to navigate this using a screenreader, it will probably tell you that there's a table to be looked at (although some screenreaders can guess the difference between table layouts and data tables). You'll then likely (depending on which screenreader you're using) have to go down into the table as an object and look at its features separately, then get out of the table again to carry on navigating the content.

Table layouts are a relic of the past — they made sense back when CSS support was not widespread in browsers, but they create confusion for screenreader users, as well as being bad for many other reasons (abuse of tables, arguably requires more markup, make designs more inflexible). Don't do it!

You can verify these claims by comparing your previous experience with a more modern website structure example, which could look something like this:

<header>
  <h1>Header</h1>
</header>

<nav>
  <!-- main navigation in here -->
</nav>

<!-- Here is our page's main content -->
<main>

  <!-- It contains an article -->
  <article>
    <h2>Article heading</h2>

    <!-- article content in here -->
  </article>

  <aside>
    <h2>Related</h2>

    <!-- aside content in here -->
  </aside>

</main>

<!-- And here is our main footer that is used across all the pages of our website -->

<footer>
  <!-- footer content in here -->
</footer>

If you try our more modern structure example with a screenreader, you'll see that the layout markup no longer gets in the way and confuses the content readout. It is also much leaner and smaller in terms of code size, which means easier to maintain code, and less bandwidth for the user to download (particularly prevalent for those on slow connections).

Another consideration when creating layouts is using HTML5 semantic elements as seen in the above example (see content sectioning) — you can create a layout using only nested <div> elements, but it is better to use appropriate sectioning elements to wrap your main navigation (<nav>), footer (<footer>), repeating content units (<article>), etc. These provide extra semantics for screenreaders (and other tools) to give user extra clues about the content they are navigating (see Screen Reader Support for new HTML5 Section Elements for an idea of what screen reader support is like).

Note: As well as your content having good semantics and an attractive layout, it should make logical sense in its source order — you can always place it where you want using CSS later on, but you should get the source order right to start with, so what screenreader users get read out to them will make sense.

UI controls

By UI controls, we mean the main parts of web documents that users interact with — most commonly buttons, links, and form controls. In this section we'll look at the basic accessibility concerns to be aware of when creating such controls. Later articles on WAI-ARIA and multimedia will look at other aspects of UI accessibility.

One key aspect to the accessibility of UI controls is that by default, browsers allow them to be manipulated by the keyboard. You can try this out using our native-keyboard-accessibility.html example (see the source code) — open this in a new tab, and try pressing the tab key; after a few presses, you should see the tab focus start to move through the different focusable elements; the focused elements are given a highlighted default style in every browser (it differs slightly between different browsers) so that you can tell what element is focused.

You can then press Enter/Return to follow a focused link or press a button (we've included some JavaScript to make the buttons alert a message), or start typing to enter text in a text input (other form elements have different controls, for example the <select> element can have its options displayed and cycled between using the up and down arrow keys).

Note: Different browsers may have different keyboard control options available. See Using native keyboard accessibility for more details.

You essentially get this behavior for free, just by using the appropriate elements, e.g.

<h1>Links</h1>

<p>This is a link to <a href="https://www.mozilla.org">Mozilla</a>.</p>

<p>Another link, to the <a href="https://developer.mozilla.org">Mozilla Developer Network</a>.</p>

<h2>Buttons</h2>

<p>
  <button data-message="This is from the first button">Click me!</button>
  <button data-message="This is from the second button">Click me too!</button>
  <button data-message="This is from the third button">And me!</button>
</p>

<h2>Form</h2>

<form>
  <div>
    <label for="name">Fill in your name:</label>
    <input type="text" id="name" name="name">
  </div>
  <div>
    <label for="age">Enter your age:</label>
    <input type="text" id="age" name="age">
  </div>
  <div>
    <label for="mood">Choose your mood:</label>
    <select id="mood" name="mood">
      <option>Happy</option>
      <option>Sad</option>
      <option>Angry</option>
      <option>Worried</option>
    </select>
  </div>
</form>

This means using links, buttons, form elements, and labels appropriately (including the <label> element for form controls).

However, it is again the case that people sometimes do strange things with HTML. For example, you sometimes see buttons marked up using <div>s, for example:

<div data-message="This is from the first button">Click me!</div>
<div data-message="This is from the second button">Click me too!</div>
<div data-message="This is from the third button">And me!</div>

But using such code is not advised — you immediately lose the native keyboard accessibility you would have had if you'd just used <button> elements, plus you don't get any of the default CSS styling that buttons get.

Building keyboard accessibility back in

Adding such advantages back in takes a bit of work (you can an example code in our fake-div-buttons.html example — also see the source code). Here we've given our fake <div> buttons the ability to be focused (including via tab) by giving each one the attribute tabindex="0":

<div data-message="This is from the first button" tabindex="0">Click me!</div>
<div data-message="This is from the second button" tabindex="0">Click me too!</div>
<div data-message="This is from the third button" tabindex="0">And me!</div>

Basically, the tabindex attribute is primarily intended to allow tabbable elements to have a custom tab order (specified in positive numerical order), instead of just being tabbed through in their default source order. This is nearly always a bad idea, as it can cause major confusion. Use it only if you really need to, for example if the layout shows things in a very different visual order to the source code, and you want to make things work more logically. There are two other options for tabindex:

  • tabindex="0" — as indicated above, this value allows elements that are not normally tabbable to become tabbable. This is the most useful value of tabindex.
  • tabindex="-1" — this allows not normally tabbable elements to receive focus programmatically, e.g. via JavaScript, or as the target of links. 

Whilst the above addition allows us to tab to the buttons, it does not allow us to activate them via the Enter/Return key. To do that, we had to add the following bit of JavaScript trickery:

document.onkeydown = function(e) {
  if(e.keyCode === 13) { // The Enter/Return key
    document.activeElement.onclick(e);
  }
};

Here we add a listener to the document object to detect when a button has been pressed on the keyboard. We check what button was pressed via the event object's keyCode property; if it is the keycode that matches Return/Enter, we run the function stored in the button's onclick handler using document.activeElement.onclick(). activeElement gives us the element that is currently focused on the page.

Note: You should bear in mind that this technique will only work if you set your original event handlers via event handler properties (e.g. onclick). addEventListener won't work.

This is a lot of extra hassle to build the functionality back in. And there's bound to be other problems with it. Better to just use the right element for the right job in the first place.

Meaningful text labels

UI control text labels are very useful to all users, but getting them right is particularly important to users with disabilities.

You should make sure that your button and link text labels are understandable and distinctive. Don't just use "Click here" for your labels, as screenreader users sometimes get up a list of buttons and form controls. The following screenshot shows our controls being listed by VoiceOver on Mac.

Make sure your labels make sense out of context, read on their own, as well as in the context of the paragraph they are in. For example, the following shows an example of good link text:

<p>Whales are really awesome creatures. <a href="whales.html">Find out more about whales</a>.</p>

but this is bad link text:

<p>Whales are really awesome creatures. To find more out about whales, <a href="whales.html">click here</a>.</p>

Note: You can find a lot more about link implementation and best practices in our Creating hyperlinks article. You can also see some good and bad examples at good-links.html and bad-links.html.

Form labels are also important, for giving you a clue what you need to enter into each form input. The following seems like a reasonable enough example:

Fill in your name: <input type="text" id="name" name="name">

However, this is not so useful for disabled users. There is nothing in the above example to associate the label unambiguously with the form input, and make it clear how to fill it in if you cannot see it. If you access this with some screenreaders, you'll may only be given a description along the lines of "edit text".

The following is a much better example:

<div>
  <label for="name">Fill in your name:</label>
  <input type="text" id="name" name="name">
</div>

With the code like this, the label will be clearly associated with the input; the description will be more like "Fill in your name: edit text".

As an added bonus, in most browsers associating a label with a form input means that you can click the label to select/activate the form element. This gives the input a bigger hit area, making it easier to select.

Note: you can see some good and bad form examples in good-form.html and bad-form.html.

Accessible data tables

A basic data table can be written with very simple markup, for example:

<table>
  <tr>
    <td>Name</td>
    <td>Age</td>
    <td>Gender</td>
  </tr>
  <tr>
    <td>Gabriel</td>
    <td>13</td>
    <td>Male</td>
  </tr>
  <tr>
    <td>Elva</td>
    <td>8</td>
    <td>Female</td>
  </tr>
  <tr>
    <td>Freida</td>
    <td>5</td>
    <td>Female</td>
  </tr>
</table>

But this has problems — there is no way for a screenreader user to associate rows or columns together as groupings of data. To do this you need to know what the header rows are, and if they are heading up rows, columns, etc. This can only be done visually for the above table (see bad-table.html and try the example out yourself).

Now have a look at our punk bands table example — you can see a few accessibility aids at work here:

  • Table headers are defined using <th> elements — you can also specify if they are headers for rows or columns using the scope attribute. This gives you complete groups of data that can be consumed by screen readers as single units.
  • The <caption> element and <table> summary attribute both do similar jobs — they act as alt text for a table, giving a screen reader user a useful quick summary of the table's contents. <caption> is generally preferred as it makes it's content accessible to sighted users too, who might also find it useful. You don't really need both.

Note: See our HTML table advanced features and accessibility article for some more details around accessible data tables.

Text alternatives

Whereas textual content is inherently accessible, the same cannot necessarily be said for multimedia content — image/video content cannot be seen by visually-impaired people, and audio content cannot be heard by hearing-impaired people. We'll cover video and audio content in detail in the Accessible multimedia article later on, but for this article we'll look accessibility for the humble <img> element.

We have a simple example written up, accessible-image.html, which features four copies of the same image:

<img src="dinosaur.png">

<img src="dinosaur.png"
     alt="A red Tyrannosaurus Rex: A two legged dinosaur standing upright like a human, with small arms, and a large head with lots of sharp teeth.">

<img src="dinosaur.png"
     alt="A red Tyrannosaurus Rex: A two legged dinosaur standing upright like a human, with small arms, and a large head with lots of sharp teeth."
     title="The Mozilla red dinosaur">


<img src="dinosaur.png" aria-labelledby="dino-label">

<p id="dino-label">The Mozilla red Tyrannosaurus Rex: A two legged dinosaur standing upright like a human, with small arms, and a large head with lots of sharp teeth.</p>

The first image, when viewed by a screen reader, doesn't really offer the user much help — VoiceOver for example reads out "/dinosaur.png, image". It reads out the filename to try to provide some help. In this example the user will at least know it is a dinosaur of some kind, but often files may be uploaded with machine generated file names (e.g. from a digital camera) and these file names would likely provide no context to the image's content.

Note: This is why you should never include text content inside an image — screen readers simply can't access it. There are other disadvantages too — you can't select it and copy/paste it. Just don't do it!

When a screen reader encounters the second image, it reads out the full alt attribute — "A red Tyrannosaurus Rex: A two legged dinosaur standing upright like a human, with small arms, and a large head with lots of sharp teeth.".

This highlights the importance of not only using meaningful file names in case so-called alt text is not available, but also making sure that alt text is provided in alt attributes wherever possible. Note that the contents of the alt attribute should always provide a direct representation of the image and what it conveys visually. Any personal knowledge or extra description shouldn't be included here, as it is not useful for people who have not come across the image before.

One thing to consider is whether your images have meaning inside your content, or whether they are purely for visual decoration, so have no meaning. If they are decorational, it is better to just include them in the page as CSS background images.

Note: Read Images in HTML and Responsive images for a lot more information about image implementation and best practices.

If you do want to provide extra contextual information, you should should put it in the text surrounding the image, or inside a title attribute, as shown above. In this case, most screenreaders will read out the alt text, the title attribute, and the filename. In addition, browsers display title text as tooltips when moused over.

Let's have another quick look at the fourth method:

<img src="dinosaur.png" aria-labelledby="dino-label">

<p id="dino-label">The Mozilla red Tyrannosaurus ... </p>

In this case, we are not using the alt attribute at all — instead, we have presented our description of the image as a regular text paragraph, given it an id, and then used the aria-labelledby attribute to refer to that id, which causes screenreaders to use that paragraph as the alt text/label for that image. This is especially useful if you want to use the same text as a label for multiple images — something that isn't possible with alt.

Note: aria-labelledby is part of the WAI-ARIA spec, which allows developers to add in extra semantics to their markup to improve screenreader accessibility whrere needed. To find out more about how it works, read our WAI-ARIA Basics article.

Other text alternative mechanisms

Images also have another mechanisms available for providing descriptive text. For example, there is a longdesc attribute that is meant to point to a separate web document containing an extended description of the image, for example:

<img src="dinosaur.png" longdesc="dino-info.html">

This sounds like a good idea, especially for infographics like big charts with lots of information on that could perhaps be represented as an accessible data table instead (see previous section). However, longdesc is not supported consistently by screenreaders, and the content is completely inaccessible to non-screenreader users. It is arguably much better to include the long description on the same page as the image, or link to it with a regular link.

HTML5 includes two new elements — <figure> and <figcaption> — which are supposed to associate a figure of some kind (it could be anything, not necessarily an image) with a figure caption:

<figure>
  <img src="dinosaur.png" alt="The Mozilla Tyrannosaurus">
  <figcaption>A red Tyrannosaurus Rex: A two legged dinosaur standing upright like a human, with small arms, and a large head with lots of sharp teeth.</figcaption>
</figure>

Unfortunately, most screenreaders don't seem to associate figure captions with their figures yet, but the element structure is useful for CSS styling, plus it provides a way to place a description of the image next to it in the source.

Empty alt attributes

<h3>
  <img src="article-icon.png" alt="">
  Tyrannosaurus Rex: the king of the dinosaurs
</h3>

There may be times where an image is included in a page's design, but its primary purpose is for visual decoration. You'll notice in the code example above that the image's alt attribute is empty — this is to make screen readers recognize the image, but not attempt to describe the image (instead they'd just say "image", or similar).

The reason to use an empty alt instead of not including it is because many screen readers announce the whole image URL if no alt is provided.  In the above example, the image is acting as a visual decoration to the heading its associated with. In cases like this, and in cases where an image is only decoration and has no content value, you should put an empty alt on your images. Another alternative is to use the aria role attribute role="presentation" — this also stops screens readers from reading out alternative text.

Note: if possible you should use CSS to display images that are only decoration.

Summary

You should now be well-versed in writing accessible HTML for most occasions. Our WAI-ARIA basics article will also fill in some gaps in this knowledge, but this article has taken care of the basics. Next up we'll explore CSS and JavaScript, and how accessibility is affected by their good or bad use.

 

In this module

 

文档标签和贡献者

 此页面的贡献者: zouyang1230, Junx
 最后编辑者: zouyang1230,