Universal Design for the Web

Universally designed web pages are compatible with a wide range of technologies, including multiple computer platforms, web browsers, and assistive technologies. They can be read as easily on a cell phone as a large computer display, and are easily interpreted by text-to-speech software.

Universally designed web media contain captions that convey content as effectively to viewers in a noisy airport as in a quiet computer lab. Captioned videos offer the added benefit of sharing their text-based content with internet search engines.

Design Best Practices

Perhaps the most critical element of accessible web design is the principle of separating content (document structure) from its visual presentation. A well-built web publication is thus a combination of HyperText Markup Language (HTML) tags that define the structure and function of page elements, and Cascading Style Sheet (CSS) rules that control the appearance of those elements. See web articles Separate Content and Presentation and Creating Semantic Structure for a more complete discussion of this principle.

Keep the following tips in mind as you create web content:

  1. HTML tags define document structure.
    • Examples of structural markup include headings <h1> to <h6>; paragraphs <p>; logical divisions <div>; lists <ul><ol><dl>; images <img>, table cells and headers <td> and <th>, etc.
    • Tags are also called “markup,” from the name HyperText MarkupLanguage (HTML).
  2. Cascading Style Sheets (CSS) control the appearance and behavior of page elements.
    • Here’s a simple example of a CSS rule that sets all level 1 headers to red: h1 {color: red;}
    • A more complex rule might set the location of a block of content (contained in a <div> tag with an ID of “content”) to the top left corner of the screen: #content {position: absolute; left: 0px; top: 0px;}
  3. Avoid outdated or “deprecated” tags like <font> and <b>, which confuse structure with presentation.
  4. Wrap sections of content in <div> tags (div stands for “division”), which can be assigned an ID and/or class. CSS rules can then be written for these IDs and classes to control their appearance.
  5. Practice a “structure-first” approach to web design in which structural markup takes place before visual formatting. A structural focus ensures that web pages can be understood when styles are turned off. Well structured web pages are more flexible for both users and designers.
  6. Migrate to HTML5 for greater device interoperability. HTML5 takes accessibility into account.

Under Development

JavaScript

Client-side scripting can add tremendous functionality and interactivity to your web pages. Remember, however, that not everyone can take advantage of JavaScript’s added features. For example, many handheld devices do not support JavaScript, and there will always be some users who prefer to turn it off.

Keep in mind the following considerations when adding JavaScript features to your web pages:

  1. Web pages should still function when JavaScript is turned off. Think of JavaScript behaviors as “icing on the cake”—nice, but not required to use the page. Add <noscript> tags to tell users what they’re missing if JavaScript isn’t available. For example: <script type=”text/javascript”>   document.write(“This page was last updated ” + showDate() + “. “); </script><noscript>   <p>Page modification date displays here when JavaScript is enabled.</p></noscript>
  2. Always test JavaScript elements to make sure they behave as expected when navigating with a keyboard and a screen reader. JavaScript can cause your site to be completely inaccessible, so it is critical to continue checking accessibility of these elements as you go.

Some functionality used in Web sites is not available to some users with disabilities, especially people who rely on screen readers and people who cannot use a mouse. WAI-ARIA, the Accessible Rich Internet Applications Suite, is a W3C protocol designed to make Web applications and content more accessible for people with disabilities. Using ARIA with dynamic content, such as sliders, tree menus, or other scripted controls that use AJAX and related technologies, can improve the accessibility of a site.

Summary of Rules for ARIA Use in HTML
  • If you can use a native HTML element [HTML51] or attribute with the semantics and behavior you require already built in, instead of re-purposing an element and adding an ARIA role, state or property to make it accessible, then do so.
  • Do not change native semantics, unless you really have to.
  • All Interactive ARIA controls must be usable with the keyboard.
  • Do not use role=”presentation” or aria-hidden=”true” on a visible focusable element.
  • All interactive elements must have an accessible name.

Review these Notes on using ARIA for an understanding of the rules, as well as the W3C Working Draft from September 29, 2017 on ARIA use in HTML for detailed information.  Note that the above documents are a work in progress and subject to change.  You can view a list of all W3C standards and drafts relating to WAI-ARIA, which includes completed recommendations and the most current working drafts.

WAI-ARIA Tools

Under development

The term “color contrast” describes the differences in brightness and color between elements in a photograph or, more importantly for our purposes, text and a colored backgrounds.

Because color contrast is essential to the readability of documents, slide presentations, and websites, it is a key component of universal design. Some of your readers (an estimated 4% of the population) will have low vision. Others (approximately 8.5% of the population) will have some form of color blindness (also known as color vision deficiency), meaning they may have difficulty distinguishing red from green, or yellow from blue. Use the following techniques to help make your publications accessible to everyone:

  • Choose a color scheme that provides high contrast between the text and the background. If you have a dark background, the text should be light, and vice versa. (Black and white provide maximum contrast.)
  • Use larger text and simple (not ornate) fonts.
  • Use a contrast checking tool (online or downloadable) to determine whether your color selections are legible by a wide range of users. We recommend the Colour Contrast Analyser by the Paciello Group.
  • If you are building a webpage, check it with a color blindness simulation tool. Avoid the following color combinations as they are difficult to read, especially for individuals with color vision deficiency:
    • Green and red (or related colors)
    • Blue and yellow (or related colors)
  • Don’t rely on color as the sole means of conveying information. For example, don’t use color as your only method of indicating heading levels.
  • Text can be difficult to read on photographic or gradient backgrounds. Set text against a solid background when possible.
Verifying Contrast – Solid Backgrounds

How do you know which colors will have enough contrast to be universally readable? One approach, of course, is to play it safe and stick to black and white, which are the default colors in applications like Microsoft Word. But color is an important—some would say essential—design element of slide presentations and the Web. So, which colors are best?

When text is placed against a solid color background, we recommend you use the Colour Contrast Analyser (CCA) by the Paciello Group to determine whether the contrast ratio passes the WCAG 2.0 standards. This free tool helps you “determine the legibility of text and the contrast of visual elements” using color contrast criteria established in the Web Content Accessibility Guidelines (WCAG) 2.0. The tool also simulates certain visual conditions, including dichromatic color-blindness and cataracts, to demonstrate how your web content appears to people with less than 20/20 vision. Use the CCA eyedropper tool to select foreground and background colors. The results display immediately below.

In the following example, we’ve run the CCA on a website designed with orange headings, gray text, and blue link text.

website with poor contrast between headings and background

For this website, the CCA reports insufficient contrast between orange text and the white background. You would want to select a darker orange color from the drop-down color palette.

Colour Contrast Analyser, showing insufficient contrast between orange headings and white background

When we check the gray text against white background, the CCA shows mixed results. This color combination passes at the "AA" standard, but not the more stringent "AAA" standard, which is the goal for most university and public websites. A darker gray would be better.

Colour Contrast Analyser showing mixed results with gray text on white background

Finally, we test the blue link text against the white background. This combination of colors fails both the “AA” and “AAA” standards for normal text sizes, as well as the “AAA” test for larger sizes. It passes only the “AA” standard for large text. A darker blue is required for universal readability.

Colour Contrast Analyser showing failure with blue colored link text on a white background

Verifying Contrast – Photo or Gradient Backgrounds

The Paciello Group's Colour Contrast Analyser and the WAVE Tool both assume that text is placed against a solid background. They cannot always account for text placed on gradient backgrounds or images. In Chrome, you can use the Color Contrast Analyzer Extension, which evaluates a page exactly as it appears in the browser.

This tool repaints the page so that you can see the edges of the text, and discover which text fades into the background. If there is an item that is not outlined, then the item does not have sufficient contrast. The example below shows a before and after view of the extension. In the 'after' view, only the text that is outlined in white has sufficient contrast. You can see that the white text fades into the lighter areas of the background photo.

Image with faded text before using the colour contrast analyser extensionImage with faded text after using the colour contrast analyser extension.

Zoom capability ensures that visually rendered text can be scaled successfully so that it can be read directly by people with mild visual disabilities or low vision such as seniors, without requiring the use of assistive technology such as a screen magnifier. Users may use Ctrl + to zoom in on content, so it is important to design and test your content to ensure that it is still readable and there is no loss of content or functionality at 200% magnification.

  • Provide large fonts by default
  • Ensure that text containers resize when the text resizes
  • Use relative measurements
  • Specify the size of text containers using em units or percentages (CSS)
  • Use percentage, named font sizes, or em units for font sizes (CSS)
  • Set column widths so that lines can average 80 characters or less when the browser is resized (CSS)
  • Scale form elements which contain text (CSS)
  • Calculate size and position in a way that scales with text size (Scripting)
  • Provide sufficient inter-line and inter-column spacing
  • Use server-side scripts to resize images of text
  • Scale form elements which contain text (CSS)

Avoid

  • Scaling font sizes smaller than the user-agent default
  • Justified text
  • The use of text in raster images. If you cannot avoid this, ensure that text in raster images is at least 18pt

Captioning provides a synchronized text transcript of the audio for any type of multimedia so that the information can be read as well as heard. This alternate method of delivery is vital for including those with hearing impairments, but it is also beneficial for other users, such as those learning the language used in the video.

Captions can be combined into a video transcript. Because the transcript is searchable, users can locate a specific points in the video, and search engines will bring more traffic to your site.

For details on available captioning solutions, see Captioning Videos.

  1. Use tables for tabular data only, not as a framework for page layout.
  2. Keep tables as simple as possible, and try to avoid nesting tables inside one another.
  3. Add captions to tables using the <caption> tag. A caption will typically provide an adequate summary of the table’s contents. Complex tables may need a more detailed explanation using the <table> tag’s “summary” attribute.
  4. In the header row of the table, replace <td> (table data) tags with <th>(table header) tags to indicate the special function of those cells as column labels.

For a form to be accessible, it should be usable by people who use a screen reader or a keyboard to navigate.

  1. A user should be able to complete a form using only a keyboard, including interacting with dialog boxes
  2. Form fields should be labeled descriptively
  3. Tab order should be logical
Web Forms

Online forms can be made more navigable by organizing related elements using the <fieldset> and <legend> tags. It is also important to clarify the relationship between labels and form elements using the <label> tag and its for attribute.

Consider the following when working with forms:

  1. Make sure form elements can be navigated from the keyboard. The Tab key should move focus sequentially through the form.
  2. Add labels to form elements, and use the <label> tag’s for attribute to point to the ID of the associated form element.
    • The for attribute keeps labels and form elements linked, regardless of where they appear on the page.
      • Example using the form <input> element: <label for="emailfield">Your email address:</label><input name="email" type="text" id="emailfield" size="45" maxlength="60"/>
    • Screen reader users typically use the TAB key to jump through form fields. Associated form labels are read for each field when the user navigates to it. Be sure to include cues within associated labels, as the screen reader will skip any non-label text.
  3. Group related form elements using a combination of <fieldset> and <legend> tags, which facilitate both visual comprehension and tabbing navigation for non-visual users.
  4. No matter how well you design your forms, some users may not be able to use them. Always provide a contact number or address for requesting a paper copy.

Common Accessibility Issues

Two links on a page should not go to the same location, especially if they are adjacent. Screen readers and keyboard users would need to hear or tab through the same link twice, which wastes time and may cause confusion about whether the links are different.

Instead of having separate links for an image and its text caption, put both image and text inside a single link, and give the image an empty alt attribute (alt=””) so screen readers will not hear redundant text.

<a href=”https://source.colostate.edu/“><img src=”source.jpg” alt=””><br>Source</a> 

For more information visit the Web Accessibility Best Practices  site and the Nielsen Norman Group article on duplicate links. 

For those who cannot or prefer not to use a mouse, web sites normally can be operated with a keyboard alone (eg, users can tab between focusable elements like menus, links, and form fields).  Though browsers typically display a visible border around the element that currently has keyboard focus, sometimes it is difficult for users to tell where they are on a page.  Therefore, if you wish to improve upon the browser’s default focus indicator, you can use the :focus selector in CSS.  For example:

a:hover, a:active, a:focus { background-color: #004C23; color: #ffffff; }

Consider contrast when selecting the color of the focus indicator so that it is clearly visible on all backgrounds.

For more information, please see WCAG 2.0 Success Criterion 2.4.7 Focus Visible (Level AA).

Reading order is important to consider for content that isn't linear. It applies to the more heavily visual layouts such as websites and PowerPoint presentations, as well as to PDF documents with columns, images, or forms. Setting the reading order allows text-to-speech or screen reading software to read the information in a logical order. It also ensures that links and form fields can be tabbed through sequentially for users who navigate with a keyboard or screen reader.

Tab Order

A web page should be navigable using only the Tab and Enter keys. Some users prefer to navigate using just the keyboard, while others may need to navigate your site without the use of a mouse.

To facilitate keyboard navigation, set the tab order of links and form elements so that each can be accessed in a logical, sequential order using tabindex = number.

See W3C form specifications under Tabbing Navigation for more information.

Many websites include navigational menus at or near the top of every page, above the main content.  While a sighted user can look past this navigation, a screen reader user and those navigating by keyboard need a mechanism to do so.  Skip navigation or “skip to main content” links target the HTML element containing the page’s main content and enable users to efficiently skip redundant menus.  These links are implemented by including a named anchor in front of top-level navigation, as shown below:

<!doctype html>

<html lang=”en”>

<head>…</head>

<body>

<a href=’#content’>Skip over navigation</a>

<nav>…</nav>

<div id=”content”>…</div>

</body>

</html>

Often these skip navigation links are visibly hidden using CSS, but are made visible on :focus so it only appears once users press the tab key.

For more information, please see WCAG 2.0 Success Criterion 2.4.1 Bypass Blocks (Level A) or WebAIM: “Skip Navigation”

Media Player Controls Should Be Keyboard Accessible, Screen Reader Compatible

When embedding video or audio on a web page, it is important to check to see if the media player itself is accessible. The media player controls should be keyboard operable and made known to those using screen readers.

Keyboard Accessibility

Media player controls should receive focus using the Tab key and arrow keys. Depending on the control, the media player should be operated using the Enter key, space bar, and arrow keys. Check for the following to determine keyboard accessibility:

  • The Enter key or space bar activates the Play/Pause control.
  • The arrow keys, usually up and down arrow keys, manipulate the Volume control.
  • The arrow keys, usually left and right keys, manipulate the Forward and Rewind controls.
  • Depending on their design, other controls like Captions and Full Screen are activated by the keyboard.

Screen Reader Accessibility

For screen reader accessibility, the characteristics of each media player control must be stated by the screen reader. These characteristics are:

  • Name (“Play,” “Fast Forward”)
  • State (“selected,” “expanded”)
  • Role (“button,” “list”)
  • Value (“75%” for volume)