Partager via

Introduction to Web Accessibility

  • Article
  • Accessibility in General
  • How Accessibility Works
  • Web Accessibility
  • Designing for Accessibility
  • WAI-ARIA
  • Text Scaling
  • Colors
    • Table with Color and Text
    • Table with Color and Image
    • HTML
  • Tab Order
  • Content Insertion
  • Conclusion

This article introduces the Developing Accessible Web Applications series, and provides an overview of web accessibility. 

Accessibility in General

In the world of computer applications, accessibility is about making applications usable by people with disabilities. These disabilities can range from an inability to detect differences in color, to repetitive stress injuries that make using a mouse difficult.

Some people have mobility limitations that require a special input device instead of the keyboard and mouse. Others are visually impaired and require screen reader software that reads aloud to the user what is on the screen. The goal of web accessibility is to provide "equivalent functionality for every user," regardless of their disability. All functions of your applications must be available for all users.

With so many people using computers both at home and at work, far more people with varying degrees of disabilities rely on computers to accomplish important tasks. As a result, various standards and regulations have been implemented to help ensure that these users have equal access to software and web applications.

According to a 2003 Forrester study commissioned by Microsoft, 57% of working-age adult computer users can benefit from changes made to improve the accessibility of computer applications, and 44% use some form of accessible technology. These changes range from relatively minor modifications to the user interface, such as large fonts or high contrast settings for those with visual impairments, to enabling keyboard navigation for those unable to use a mouse. And the changes include full replacements for the interaction model, such as a screen reader where application content is read to the user, and voice recognition where commands are spoken by the user to the computer.

There are also market considerations, as some government organizations, including the United States federal government, are required to purchase the most accessible application in a category. And an application that is the most widely accessible will be able to be used by the greatest number of people. In the case of internal company applications, those that are accessible from the beginning will be usable by all employees without subsequent modifications.

The following two reports show findings from the 2003 Forrester study:

How Accessibility Works

Assistive technology adds capabilities that the computer doesn't usually have. For example, a visually impaired user might employ assistive technology such as a screen reader and voice recognition, rather than directly using the application with the mouse and screen.

For applications on Microsoft platforms such as Windows or Windows Internet Explorer, and on the web, the assistive technology interacts with Microsoft UI Automation, Microsoft Active Accessibility, an application-specific object model such as the Document Object Model (DOM) in Internet Explorer, or some combination of these.

For Windows developers, UI Automation and Microsoft Active Accessibility provide an API to which they can write, to assign the appropriate accessibility properties and events. For web developers, certain HTML elements are mapped to Microsoft Active Accessibility and UI Automation objects, so in selecting those HTML elements, the developer can make use of the accessibility properties and events built in to those elements.

In both cases, the developer usually needs to be concerned only with ensuring that the API is correctly written to (or that the appropriate element is specified), in order for the application to be accessible, and need not be concerned with the wide variety of types of assistive technology in use ( see Figure 1).  

Figure 1: Architecture of Accessibility APIs and assistive technology on Windows: the browser interprets HTML and Accessible Rich Internet Applications (ARIA) information, and exposes it to the same platform Accessibility API used by Windows applications.

Figure 2:  Windows Accessibility Technical Overview:  applications expose information to the Accessibility API, which is consumed by assistive technology products and exposed to the user

Web Accessibility

In recent years, the Internet and corporate intranets have proven themselves to be extremely important application platforms. Rather than deploy applications to multiple desktop computers running multiple operating systems, organizations can write one version of an application in HTML and make it available from a single server to anyone with connectivity and a browser.

Developing accessibility for traditional Classic Windows applications typically involves using a specific accessibility API such as Microsoft Active Accessibility or UI Automation, to write additional code to create applications like "magnifying glass." This application programmatically enlarges screen contents so that the screen is easier to read for people with sight limitations. The developer had to do "extra" work to make the application accessible, but also had great control over the accessibility information that the application exposed.

For example, the developer might write a custom control using Windows GDI+, and assign to that control an appropriate role for assistive technology to use, such as a slider, a tree, or something else. Developers might also specify any custom events that they wanted the control to engage.

There was some complexity in writing an accessible control, but also great discretion and flexibility in how that control was exposed. In addition, standard controls that ship with Windows have these assistive technologies implemented, so that developers who use any of the wide variety of common controls, get built-in accessibility, and the API values can be set by changing the ARIA values.

By using HTML web applications, the situation is different. With a Classic Windows application the developer has read/write access to the controls, but with HTML, the built-in controls, such as form elements and links, are read-only.

For example, if an HTML developer wants to implement a form with a text box and a button, the developer might use the existing HTML forms controls, in this case the input type=text and the input type=button, or button. The developer can certainly create a custom "textbox" and "button" using other elements, such as the generic div container, adding to it Cascading Style Sheets (CSS) and script to make it look and act like a textbox. But, because the accessibility of controls in HTML is read-only, there has been no way to have this custom "textbox" expose itself to assistive technology as an actual input type=text, and assistive technology users might not know that there was supposed to be a textbox.

This use of the correct control is referred to as Semantic HTML. Semantic HTML, roles, and names are discussed in much more detail in the Semantic HTML – Role and Name article.

The new ARIA technology from the World Wide Web Consortium (W3C) addresses this issue by specifying a set of attributes that can be added to HTML elements to modify the Accessibility API. However, this technology is quite new, and organizations who are still using older browsers may not be able to take advantage of it. The Introduction to ARIA article discusses this technology in general, and the Introduction to ARIA article discusses ways to use ARIA while still providing accessibility for browsers and assistive technology that do not support ARIA.

Figure 3: Web Accessibility Technical Overview: The browser maps values from HTML and ARIA to the Accessibility API. ARIA makes use of that information in the same way as it does for a Windows application, exposing it to the end user.

Designing for Accessibility

Because HTML is read-only, it is critical to use existing, native HTML control elements where possible. For example, use a button element rather than a div made to look and act like a button with CSS and script modifications. This ensures backward compatibility where ARIA is not available, such as early browsers.

For a couple of examples, see the Semantic HTML samples. Microsoft recommends that designs are reviewed with both designers and developers very early in the process, to identify designs that cannot be implemented in semantic HTML alone, and either modify the designs or budget time to add ARIA. For information about how to combine this process with ARIA implementation, see the Accessibility and Legacy Browsers article.

WAI-ARIA

To circumvent the limitations of native HTML controls, for some time there has been an industry effort to extend HTML so that developers can build applications that have custom controls and are accessible to assistive technology users. WAI-ARIA is a W3C recommendation that provides such extensions in the form of roles and attributes that are understood by accessibility agents.

For example, with WAI-ARIA a developer can mark a control as a tree, and it will be exposed as a tree control to assistive technology by WAI-ARIA-capable browsers. Other WAI-ARIA roles include sliders and menus.

WAI-ARIA is an excellent effort to provide native HTML elements with accessibility, but it isn't backward-compatible. Web browsers that are not WAI-ARIA-aware, such as Internet Explorer prior to version 8, simply ignore the WAI-ARIA information. Earlier versions of assistive technology also do not expose WAI-ARIA information.

Because of this backward-compatibility problem, organizations with significant numbers of older browsers and assistive technology products in their deployed base, will not be able to use a "pure" WAI-ARIA approach to web accessibility. In order to be accessible to older browsers and assistive technology, web applications still need to be built using semantic HTML.

And, it is always better to use the built-in functionality rather than building your own, if you can. The controls that are part of the browser are very thoroughly specified and tested, and work in cases you may not cover in your custom control. This is particularly important when dealing with assistive technology products, because there are so many of them, and most developers don't have the resources, time, or experience to effectively test with all of them.

Our recommendation is to build your web applications using semantic HTML and layer WAI-ARIA roles and attributes on top of the HTML. In this manner, users of older browsers and assistive technology will get the best accessibility, and users of newer versions will get an even richer experience.

For more information about WAI-ARIA and this "progressive enhancement" approach to building web applications, see Accessibility and Legacy Browsers, and Introduction to ARIA, as well as the set of related samples.

Text Scaling

Prior to the broad adoption of zoom as the means for browsers to increase text size (as well as the size of all other elements, such as images), using Internet Explorer's View > Text Size was the primary way that a user could increase the font size in an HTML document (other than system Large Fonts or High Contrast settings). There were two common problems with this.

Fonts specified in absolute CSS units such as "px", did not change size. If you develop for an environment that includes older browsers such as Microsoft Internet Explorer 6, be sure to specify font size in a relative unit. Microsoft recommends using percentage - "%".

The other issue was that sometimes containers, such as div elements, had their height specified in pixels, so that when the font size increased with View > Text Size, the text within that element either would get cropped or would overflow. Microsoft recommends setting container dimensions in em units if you support older browsers.

Colors

There are two important considerations with colors, one for users unable to differentiate between colors ("color blindness"), and the other related to how the web application is displayed with various High Contrast mode settings. Any information that is conveyed by using color must also be conveyed by using text and additional graphic treatments, and there are two groups of users to consider here.

First, those who can see the screen but cannot see colors, and second those who cannot see the screen. For the first group, distinguish the colored object visually in some other way, such as bolding, outlining, positioning, adding icons, underlining, and so on, or by adding visible text explaining the meaning of the color change. For those who cannot see, add text, either visible or via an alt attribute on a colored image, or a title attribute (ToolTip) on colored text.

For a working sample, see the Colors Sample.

  

Table with Color and Text

Table with Color and Image

HTML

<h3>Table with colors and text</h3>
<table>
<caption>Item Information</caption>
<thead>
  <tr><th>Status</th><th>Number</th><th>Title</th></tr>
</thead>
<tbody>
  <tr class="open"><td>open</td><td>001</td><td>This is the first entry</td></tr>
  <tr class="closed"><td>closed</td><td>002</td><td>This is the second entry</td></tr>
  <tr class="pending"><td>pending</td><td>003</td><td>This is the third entry</td></tr>
  <tr class="closed"><td>closed</td><td>004</td><td>This is the fourth entry</td></tr>
</tbody>
</table>

<h3>Table with colors and IMG</h3>
<table>
<caption>Item Information</caption>
<thead>
  <tr><th>Status</th><th>Number</th><th>Title</th></tr>
</thead>
<tbody>
  <tr class="open"><td><img height="16" width="16" alt="open" src="Shared/open.gif" /></td>
    <td>001</td><td>This is the first entry</td></tr>
  <tr class="closed"><td><img height="16" width="16" alt="closed" src="Shared/closed.gif" /></td>
    <td>002</td><td>This is the second entry</td></tr>
  <tr class="pending"><td><img height="16" width="16" alt="pending" src="Shared/pending.gif" /></td>
    <td>003</td><td>This is the third entry</td></tr>
  <tr class="closed"><td><img height="16" width="16" alt="closed" src="Shared/closed.gif" /></td>
    <td>004</td><td>This is the fourth entry</td></tr>
</tbody>
</table>

If a background-color is specified the text color also needs to be specified, and vice-versa, as well as link colors. This is because there are some system color modes where CSS colors are not overridden, but non-specified colors are overridden. For example, if the background color is set to white and text color is not specified, with the system set to white on black high contrast, the user could end up with white text on a white background.

The High Contrast mode in Windows overrides most colors specified by the developer, and removes backgrounds, including the CSS background-image. Images that are meaningful, especially clickable images and icons, must be created using the img alt="" element, with an appropriate alt description.

Tab Order

There is a tendency, especially if the developer comes from a Windows-based programming background, to set tab index on all objects for which tab stops are desired. If semantic HTML is being used, this is generally unnecessary because most web page elements have tab positions in the page by default.

The more serious accessibility problem is that explicitly setting tab stops using the tabindex attribute, especially if using non-zero values to specify an order, can create a variety of unexpected behaviors. This may result in the tab order going from the initial elements then out to the browser shell, then back into the document to additional tab stops.

Content Insertion

Another serious problem can occur when HTML is inserted dynamically into the page, such as with delay-loaded menus or content loaded asynchronously in response to a user event. If the inserted HTML is not placed in the document at the point at which it visually appears, a keyboard user may have to tab through the entire document in order to get to the inserted content.

An example of content created and inserted into the page after it has loaded, is the Popup Dialog Sample. The dialog box is inserted into the empty div container element in the main page, and is created on-the-fly with JavaScript code only when the Options button is clicked. It is then deleted as soon as the dialog box closes.

For a working sample see the PopupDialog Sample.

Conclusion

In summary:

  • Use Semantic HTML (role)

  • Ensure relevant elements are named (name)

  • Specify sizes in relative units in CSS for legacy browsers

  • Specify matching colors in CSS

  • Let document structure define visual/tab order