How to implement

Checklist

This checklist helps us identify potential accessibility issues affecting our websites or applications. It's broken down into three sections of decreasing importance: A, B and C. Please check and address these issues in the order in which they appear.

For more detail on accessibility standards, please see WCAG2.0 AA

• A - Critical issues that will cause serious problems and/or stop most users of assistive technology from using the site
• B - Issues that may cause problems or increased frustration for certain users
• C - Minor issues that will cause problems or frustration for a small number of users

It is important to note, while B and C are noted as less critical, they are still required to be truly 508 compliant. This checklist should be used as a reference for development and is not a substitute for compliance checks by a section 508 coordinator.

A - Critical

1. Site is keyboard accessible
   • All interactions can be accessed with a keyboard
2. Site is free of keyboard traps
   • The keyboard focus is never trapped in a loop
3. All form inputs have explicit labels
4. All relevant images use an img tag
5. All images have alt attributes
6. Multimedia is tagged
   • All multimedia has appropriate captioning and audio description
7. Text has sufficient color contrast
   • All text has a contrast ratio of 4.5:1 with the background

B - Less Critical

1. Site never loses focus
   • Focus is always visible when moving through the page with the keyboard
2. Tab order is logical
3. Form instructions are associated with inputs
4. Site doesn't timeout unexpectedly
   • Identify elements that may "timeout" and verify that the user can request more time
5. Tables are coded properly
   • Tables have proper headers and column attributes
6. Headings are nested properly
   • Heading elements are nested in a logical way

C - Minor

1. Frames are named
   • All frames have a name element
2. Flashing elements are compliant
   • Elements that flash on screen do so at a rate of less than 3hz
3. Language is set
   • The language for the page is set
   • The language for sections on the page that differ from the site language are set
4. CSS is not required to use the page
   • The page makes sense with or without CSS
5. Links are unique and contextual
   • All links can be understood taken alone, i.e 'Read more - about 508'
6. Page titles are descriptive
7. Required plugins are linked on the page

Keyboard Access

Keyboard access to a website is key to the usability of your site. All interactions and information that can be accessed with a mouse must be accessible with just a keyboard. This doesn't mean everyone who can't use a mouse will use a keyboard, but alternative AT inputs use keyboard-like inputs to navigate the web.

Testing

1. Identify all interactions on the page.
2. Using the tab, enter, and space bar, navigate the page and ensure each input/interaction can be triggered.
   • Ensure rollover / hover interactions (help text, etc.) can be triggered as well.
   • If the user cannot interact with something, or get the information another way, this is a failure.
3. Make sure the tab order of the page is logical and follows the visual order of elements on the page.
   • If the tab order is confusing, this is a failure.
4. Check that the focus is always visible when moving through the page with the tab key.
   • If you lose focus, on a hidden link or other object when simply tabbing through the page, this is a failure.
5. Make sure you can tab through the page and get back the address bar.
   • If you ever need your mouse to get back to an element, this is a failure.
6. Keyboard users must be able to easily use and dismiss modal dialog boxes, lightboxes, or other pop-ups.
   • Modal dialog boxes need to trap the keyboard. When a modal dialog box is triggered, the keyboard focus needs to immediately move to the first actionable element in the modal.
   • The keyboard cannot use the modal dialog box until it is dismissed. When a user moves the keyboard focus past the last element in the modal dialog box, it needs to loop to the beginning of the dialog box.
   • The keyboard user needs to be able to access all controls in the dialog box, especially the controls to dismiss the dialog.
   • If the keyboard user cannot do all of these things, this is a failure.
   • Ideally, the keyboard user should also be able to dismiss the modal dialog box with the Escape key.
7. If an interaction reveals hidden content.
   • Ensure the focus is moved to the revealed content.
   • If this does not happen, check for a programmatic description of the change.
8. Check for title tags providing information not on the screen.
   • Title attributes which can only be exposed by hovering the mouse over the element are a failure of keyboard access.
9. Check that the focus never goes to elements that won't be available to somebody using a mouse.
   • If the keyboard focus goes to an off-screen element that has been temporarily hidden (items in a non-expanded drop-down menu, off-screen modals which haven't been triggered, etc.), this is a failure.

Examples

Link to nowhere 1

Link to nowhere 2

Reveal Hidden Content

<a href="#">Link to nowhere 1</a>
  <a href="#">Link to nowhere 2</a>
  <a href='javascript:$("#hiddenContent").show().focus();'>
      Reveal Hidden Content
  </a>
  <div id="hiddenContent" 
       style="display:none;" 
       tabindex='-1'>
      This div was hidden, now it's not!
  </div>
  

Avoid using tabindex of >= 1 as this will disrupt the normal tab order of the page. tabindex of -1 is only appropriate when auto-focusing an element not normally interactive.

Keyboard Trap

hidden

Select to disable keyboard trap

Select to disable keyboard trap

Select to disable keyboard trap

Select to disable keyboard trap

hidden

This is an example of a keyboard trap. Focus moves in a loop making the rest of the page inaccessible. A quick test is to tab through the page quickly and ensure you can get focus back to the address bar.

Images

When using images on a page, you must provide an alternate method for that content. This can be provided in multiple ways. You can provide this information with a caption, alt tag, title tag, or aria label. If an image has text, all the text in the image must be provided in the alternate content. No matter which method is used, an alt or title tag must be provided, even if the tag is blank.

Testing

1. Using the web developer tool, select images > Display Alt Attributes & Outline All Images
2. Inspect each Alt tag for the following
   • A unique description of the image is provided
   • Repeated images have the same alt text
   • All text in the image is included in the alt text
   • "Image of" or "Photo of" is not used
   • If the alt tag is empty, ensure the image is purely decorative
   • If the image is not decorative, make sure the image is described on the page
3. Check outlined images without alt tags by doing the following
   • Right click the image
   • Select 'Inspect Element'
   • Check for a title tag for the information normally found on the alt tag

Examples

Passes

<img src="/accessibility/images/sign.jpg" alt="Sign that reads No smoking in this area">
  

Preferred method for providing alternate content. Clear alt tag with all text included.

<img src="assets/examples/sign.jpg" title="Sign that reads No smoking in this area">
  

Acceptable, but less compatible with certain Assistive technologies Clear title tag with all text included.

<img src="assets/examples/sign.jpg" alt="">
  <span>Sign that reads No smoking in this area</span>
  

Information contained in the image is provided on the page. In most instances, an alt tag would be preferred. Images marked with an empty alt (alt="") are considered "Decorative" and not read by AT.

Fails

<img src="assets/examples/sign.jpg">
  

Image is missing an alt tag and alternative content

<img src="assets/examples/sign.jpg" alt="sign">
  

Alt tag is missing text from image

<img src="assets/examples/sign.jpg" alt="Image of sign that says NO SMOKING IN THIS AREA">
  

Avoid using "Image of" or "Picture of" as the screen reader will notify the user that it is an image. Also avoid using all caps as some screen readers will read each letter. ie. W-A-R-N-I-N-G

Symbols

Symbols or icons are often used to draw attention to certain content and can carry with them a certain context. For example, an alert, error, or success message.

<div class="alert alert-danger" role="alert">
  <span class="glyphicon glyphicon-exclamation-sign" aria-hidden="true"></span>
  <span class="sr-only">Error:</span>
  Enter a valid email address
</div>

Passes

An icon used in an alert to convey that it's an error message, with additional .sr-only text to convey this hint to users of assistive technologies.

Color and Contrast

There are two aspects we need to address when it comes to color, contrast and color dependence. Color contrast is the ratio of the foreground color(text) and the background color. Color dependence is the need to see color to understand the information. Unless specific agency requirements dictate otherwise, color contrast should meet the WCAG 2.0 AA minimum color contrast ratio of 4.5:1.

Testing

Color Contrast

1. Using a color contrast checker, select the darkest/lightest section of the text
2. Select the darkest/lightest section of the background
3. Check the ratio and ensure its greater than 4.5:1 (ex 5.3:1 would pass)

Note: Run this test for all states of the text (hover, visited, focused). This test should also be performed on images of text unless the image is a logo, which are exempt.

Color Dependence

1. Identify sections which use color to convey information
2. Check to see if the information is conveyed in another way visually and programmatically

Examples

Failures

This text fails.

This text fails because it is too light. The contrast ratio is (2.93 : 1).

This text fails.

This text fails because the background isn't dark enough. The contrast ratio is (3.28 : 1).

Red text indicates a required field

First Name 

Last Name 

This is a failure because the only indication of which fields are required is the color of the text label.

Passes

This text passes.

This text passes. The contrast ratio is (4.56 : 1).

This text passes.

This text passes. The contrast ratio is (4.54 : 1).

* indicates a required field

First Name 

* Last Name 

This example passes because the * and the red text indicates the required field. Although it is preferred to require all fields and label the optional ones with placeholders

Forms

Making forms accessible is a simple process. Each form element should be associated with its instructions and errors, and everything should be accessible via the keyboard.

Testing

1. Identify each form element
2. Find all instructions associated with each element
   • If a form element isn't programmatically associated with ALL instructions, this is a failure
3. Ensure all field elements are accessible via the keyboard
   • If the form cannot be filled out with just a keyboard, this is a failure
4. Check for title tags
   • Title tags can be a substitute for labels
   • If the title tag provides all the related information it passes, if it provides extra information it fails.
   • Title tags are not accessible via keyboard

Examples

Passes

<fieldset>
  <legend>Name</legend>
  <label for="firstname">First&nbsp;</label><input type='text' id='firstname'><br>
  <label for="lastname">Last&nbsp;</label><input type='text' id='lastname'>
  </fieldset>

  <fieldset>
  <legend>Favorite Soup?</legend>
  <input type='radio' name='soup' value='pea' id='peasoup' title='Pea Soup'>&nbsp;Pea Soup<br>
  <input type='radio' name='soup' value='chicken' id='chicken' title='Chicken Noodle'>&nbsp;Chicken Noodle<br>
  <input type='radio' name='soup' value='tomato' id='tomato' title='Tomato'>&nbsp;Tomato
  </fieldset>
  

Name: Each form element has a label, and its associated with the for tag. The for tag refers to the id of the input. When looking at this form, 'First' and 'Last' wouldn't make since without 'Name.' This is associated with the fieldset and legend. All elements are wrapped in a fieldset. There can only be one legend tag per fieldset. Anything in the legend tag will be associated.

Favorite Soup: Fieldset and legend is often used for radio buttons as its the easiest way to associate the radio buttons with the question. Notice there are no labels for the radio buttons, but each button has a title tag for assistive technology to read.

Fails

<fieldset>
  <legend>Name</legend>
  <label for="first_name">First&nbsp;</label><input type='text' id='firstname'><br>
  <label for="1lastname">Last&nbsp;</label><input type='text' id='1lastname'>
  </fieldset>

  <fieldset>
  <legend>Favorite Soup?</legend>
  <p><span style='color:red;'>This Question Is Required</span></p>
  <input type='radio' name='soup' value='pea' id='peasoup' title='Chick Pea Soup'>&nbsp;Pea Soup<br>
  <input type='radio' name='soup' value='chicken' id='chicken' title='Chicken Noodle'>&nbsp;Chicken Noodle<br>
  <input type='radio' name='soup' value='tomato' id='tomato' title='Tomato'>&nbsp;Tomato
  </fieldset>
  <br>
  

Failure: First name label for and id don't match.

Failure: Last name has an invalid id.

Failure: "This Question Is Required" is not associated with the form fields

Failure: The title tag for Pea Soup indicates it's 'Chick Pea Soup.' This information is not available to keyboard, sighted users.

How ARIA affects form inputs

Screen readers vary on what they read and the additional information they provide by default. This is a broad summary of what is read based on VoiceOver for Mac OSX.

You can test these with your own screen reader. If you have a OSX you can turn voice over on by hitting command+f5.

TL;DR Using aria-label or aria-labeledby will cause a screen reader to only read them and not the default label. If you want an input to read from multiple things like an error message, use aria-labeledby and pass it the for attribute of the label and any additional ids you want read. ex. aria-labeledby='car1 car_description car-error-message'

No ARIA

Reads just the label and not the description

Car
Please enter Make and Model

<label for="car_1">Car</label>
  <input type="text" id="car_1"/><br/>
  <span id="carmakedescription_1"><i>Please enter Make and Model</i></span>
  

Screen Reader reads input as: Car Edit text

With aria-label

Reads the aria-label and doesn't read the normal label.

Car
Please enter Make and Model

<label for="car_2">Car</label>
  <input type="text" id="car_2" aria-label="Car, please enter make and model" /><br/>
  <span id="carmakedescription_2"><i>Please enter Make and Model</i></span>
  

Screen Reader reads input as: Car, please enter make and model Edit text

With aria-labeledby pointing at carmakedescription

Reads only the aria-labeledby attribute and not the default label

Car
Please enter Make and Model

<label for="car_3">Car</label>
  <input type="text" id="car_3" aria-labeledby="carmakedescription_3" /><br/>
  <span id='carmakedescription_3'><i>Please enter Make and Model</i></span>
  

Screen Reader reads input as: Please enter Make and Model Edit text

With aria-labeledby pointing at car carmakedescription

Reads both labels indicated by the aria-labeledby attribute

Car
Please enter Make and Model

<label for="car_4">Car</label>
  <input type="text" id="car_4" aria-labeledby="car_4 carmakedescription_4" /><br/>
  <span id='carmakedescription_4'><i>Please enter Make and Model</i></span>
  

Screen Reader reads input as: Car Please enter Make and Model Edit text

With aria-describedby pointing at carmakedescription

Voice-over only reads the label, Jaws should read the description as well

Car
Please enter Make and Model

<label for="car_5">Car</label>
  <input type="text" id="car_5" aria-describedby="carmakedescription_5" /><br/>
  <span id='carmakedescription_5'><i>Please enter Make and Model</i></span>
  

Screen Reader reads input as: Car Edit text

Tables

When tables are used to show data, the header cells that relate to the data cells need to be programmatically linked. This makes table navigation for screen readers less painful.

Simple tables can have 2 levels of headers. Each header cell should have scope='col' or scope='row'.

Complex tables are tables with more than 2 levels of headers. Each header should be given a unique id and each data cell should have a headers attribute with each related header cells id listed.

If a table has text associated with it, ensure the text is programmatically linked to the table. This is usually with a <caption> element. This element should be the first element under the <table> element. While a caption is not required, it can be very helpful to screen reader users navigating the page. A caption element is strongly encouraged on data tables as it gives context to the data.

Testing

1. Identify 'data' tables (layout tables are exempt)
2. View the table source code
3. Identify the table headers
   • Check for scope on simple tables
   • Check for id and headers on complex tables

Examples

Passes

Simple Table

<table>
    <caption>User's Height and Weight</caption>
    <tr>
      <th scope="col">
        Name
      </th>
      <th scope="col">
        Height
      </th>
      <th scope="col">
        Age
      </th>
    </tr>
    <tr>
      <th scope='row'>
        Walter
      </th>
      <td>6'4</td>
      <td>34</td>
    </tr>
    <tr>
      <th scope='row'>
        Steve
      </th>
      <td>5'4</td>
      <td>30</td>
    </tr>
  </table>
  

Looking at this table, the column headers all relate to the cells below. This is done programmatically with scope="col". Each height and age value is related to the person and this is done programmatically with scope="row".

Complex table

<table>
    <caption>User's Height and Weight</caption>
    <tr>
      <th rowspan='2' id='name'>
        Name
      </th>
      <th colspan='2' id='height'>
        Height
      </th>
      <th rowspan='2' id='age'>
        Age
      </th>
    </tr>
    <tr>
      <th id='feet' headers='height'>
        Feet
      </th>
      <th id='inches' headers='height'>
        Inches
      </th>
    <tr>
      <th headers='name' id='walter'>
        Walter
      </th>
      <td headers='height feet walter'>6</td>
      <td headers='height inches walter'>4</td>
      <td headers='age walter'>34</td>
    </tr>
    <tr>
      <th headers='name' id='steve'>
        Steve
      </th>
      <td headers='height feet steve'>5</td>
      <td headers='height inches steve'>4</td>
      <td headers='age steve'>30</td>
    </tr>
  </table>
  

This is an example of a complex table, all the cells are associated to their respective headers with the headers attribute. Most tables don't require this level of complexity.

Links and Repetitive Content

Links are commonly used to quickly navigate a site when someone is using AT. Often, screen reader users won't read through an entire page to find what they are looking for, they simply move from link to link.

Things become problematic when links only make sense with context. Links such as 'Click Here' or 'Read more' don't make sense without that visual context. It's important that we inspect our sites for these types of links. These links can be made accessible using title or ARIA attributes, but this is not ideal. The ideal method for making these links accessible, is just writing better link text.

The other issue screen reader and keyboard users come across is lengthy nav bars. These are usually made up of a list of links and with compound menus, they can be quite lengthy to tab through. To alleviate these pains, a skip navigation link should be provided. This is the first link on the page and jumps to an anchor with a tabindex='-1'.

Testing

Unique Links

1. Identify all links on the page
2. Identify links with the same text
   • If they point at the different location, check for title or ARIA attributes to distinguish them
3. Identify links with generic text ('Click here', 'Read more')
   • Check for the title or ARIA attributes to provide context or additional off-screen text

Links that open in a New Window

1. Identify links that open in new windows
2. Check that target='_blank'
3. Verify that some indication is given programmatically
   • <a href='#' target='_blank' aria-label='Opens in new window>
   • <a href='#' target='_blank' title='Opens in new window'>
   • <a href='#' target='_blank'>Link<span class='sr-only'>Opens in new window</span></a>

Skip Navigation

1. First compare the pages on the site for links that are repeated at the beginning of the tab order
   • Skip Navigation is not needed if repetitive nav links are not used
2. If the Skip Navigation link is not visible, ensure it becomes visible when it has focus
3. Find the target of the skip navigation link
   • Verify the target is a valid id
   • Verify the target is after the repetitive content and before meaningful content
   • Verify the target has a tabindex='-1' or is included in the tab order (such as a link or a button)
   • This ensures the element will receive focus in chrome and safari
4. Select the Skip Navigation link
5. If visual focus is after the repetitive content, the test is complete
6. If there is no visual focus, tab again to verify focus is after the repetitive content

Examples

Passes

Home Click Here

Keyboard Access Click Here

Home <a href='../' title='home'>Click Here</a>

  Keyboard Access <a href='/keyboard' aria-label="Keyboard Access">Click Here</a>
  

These links are not unique, but the title attribute in the first link gives a screen reader user context and the aria-label provides the context in the second link.

Skip Navigation

  <div class="skip-nav">
      <a href="#mainContent">Skip to main content</a>
  </div>
  ...
  <h1 id="mainContent" tabindex="-1" class='mainContent'>Main Content Heading</h1>

  

div.skip-nav a {
    position: absolute;
    left: -10000;
    top: 0;
    width: 1px;
    height: auto;
    overflow: hidden;
  }
  div.skip-nav a:focus, div.skip-nav a:active {
      position: absolute;
      top: 5px;
      left: 5px;
      width: auto; 
      height: auto;
      z-index: 999999;
      background-color: white;
      padding-left: 2px;
      padding-right: 2px;
      overflow: visible;
   }

   .mainContent:focus, .mainContent:active {
      outline: none;
   }
  

This is how the 'Skip Navigation' was achieved for the accessibility site, feel free to use for your own site.

Animations and Motion

Adding animations and movement to a site or application is becoming more and more popular. It can be used to call attention to a particular section, give the interface depth with page transitions and slideouts, or maybe you have a beautiful video playing in the background. Just be careful not to over do it, and you may want to add some user control to those effects.

Flashing however is generally a bad idea. It can cause all sorts of issues, from seizures to motion sickness. If you absolutely must have a flashing element there are a few things to consider.

Testing

• Failure at any step constitutes a 508 compliance issue

1. Check if you can determine the frequency of "flashing"
   • Note: Scrolling text is considered flashing for our purposes
2. Check that the rate of flashing is less than 3hz (3 times a second), or scroll delay is set to >= 400

Examples

Passes

Here is a marquee, I bet you haven't seen this in a while, anyway, the scroll delay is set to 400.

<marquee scrolldelay="400">
      Here is a marquee, I bet you haven't seen this in a while, anyway, the scroll delay is set to 400.
  </marquee>
  

This is an example of marquee. The scrolldelay is set and it is equal to 400 meaning it is compliant.

Fails

Click to see non-compliant flashing This text is blinking

Failure: This blinking text fails because the rate of flashing can't be determined and its greater than 3hz.

Page Titles

Page titles are important because they help a user navigate their browser. Most users have multiple tabs open at once. It's easier to jump between pages if each page title is unique. It's also helpful to have the unique portion first, usually the name of the page.

Testing

1. Check that the title shown in the tab for the page is unique and describes the page accurately.
   • The title should be in plain english
   • The title should describe the web site as well as the specific page being displayed by the site

Examples

<title>How - San Francisco Accessibility Guide</title>
  

The title for this page is 'How - San Francisco Accessibility Guide'. The first half is the name of this page and the second is the name of the site.

Headings

When laying out a page, headings provide a semantic way to lay out sections of content. A heading element briefly describes the topic of the section it introduces. Heading elements are used by users of AT to navigate a page quickly and to understand the structure of a page. Also see Landmarks.

When using heading elements, reserve the <h1> element for the page title. On the home page, this is usually the title of the site and on other pages, this may be the page title. Use the <h1> element once per page—some assistive technology may be unable to read multiple <h1>s on a single page correctly. Other heading levels may be used more than once following document outline order and you may reset headings up to <h2> with the <section> element.

For sub sections, use <h2> to <h6> in document outline order. <h1> is the most important and <h6> is the least. Avoid skipping headings. Avoid breaking document outline order (you may go from <h1> to <h3>, but never <h3> to <h1>).

For logos that are text-based, use <em> element.

If your logo is an image and acting as the main heading of the page, add an <h1> element for its text and use a sr-only rule so it's visibly hidden but accessible to screen reader users.

<h3>Section</h3> 
  lorum ipsum 
  <h2>Sub Section</h2>
  lorum ipsum
  

Testing

1. Identify visual 'heading' elements
2. Check that all visual 'heading' elements use an <h> tag
3. Verify that all sub heading elements have a higher number

Examples

Passes

<div>
    <h3>Category</h3>
    <p>Lorem ipsum dolor sit amet, consectetur adipiscing elit. Nam sit amet auctor lectus. Curabitur non est nibh. Suspendisse vehicula fermentum quam. Donec lobortis diam a ligula faucibus mattis.</p>
    <h4>Sub Category 1</h4>
    <p>Lorem ipsum dolor sit amet, consectetur adipiscing elit. Nam sit amet auctor lectus. Curabitur non est nibh. Suspendisse vehicula fermentum quam. Donec lobortis diam a ligula faucibus mattis.</p>
    <h4>Sub Category 2</h4>
    <p>Lorem ipsum dolor sit amet, consectetur adipiscing elit. Nam sit amet auctor lectus. Curabitur non est nibh. Suspendisse vehicula fermentum quam. Donec lobortis diam a ligula faucibus mattis.</p>
  </div>
  

This section has a main category and two sub categories. The sub categories are on the same level and as such use the the same heading element.

Fails

<div>
    <h4>Category</h4>
    <p>Lorem ipsum dolor sit amet, consectetur adipiscing elit. Nam sit amet auctor lectus. Curabitur non est nibh. Suspendisse vehicula fermentum quam. Donec lobortis diam a ligula faucibus mattis.</p>
    <h3>Sub Category 1</h3>
    <p>Lorem ipsum dolor sit amet, consectetur adipiscing elit. Nam sit amet auctor lectus. Curabitur non est nibh. Suspendisse vehicula fermentum quam. Donec lobortis diam a ligula faucibus mattis.</p>
    <h6>Sub Category 2</h6>
    <p>Lorem ipsum dolor sit amet, consectetur adipiscing elit. Nam sit amet auctor lectus. Curabitur non est nibh. Suspendisse vehicula fermentum quam. Donec lobortis diam a ligula faucibus mattis.</p>
  </div>
  

This section has several issues. The first sub category has a lower value than the main category. The second sub category has skipped a heading level which while is better, this can cause confusion as its not clear if this category is the sub category of Category or Sub Category 1

Landmarks

All elements on a page should be contained in a landmark element. This helps users of AT quickly navigate a page. HTML5 provides built in landmark elements such as main, nav, aside, header, footer. When using HTML5 elements, don't define role.

When using HTML4 use ARIA role on divs to define landmark elements such as role="main".

Testing

1. Identify content in the source code
2. Check that all rendered content is contained by a landmark element

Examples

HTML5

<!DOCTYPE html>
  <html>
    <head>
      <meta charset="UTF-8">
      <title>Sample page</title>
    </head>
    <body>
      <header>
        <h1>Site Name</h1>
      </header>
      <nav>
        <ul>
          <li>Home</li>
          <li><a href="./otherpage/">Other Page</a></li>
        </ul>
      </nav>
      <main>
        <article>Here's an article</article>
      </main>
      <footer>Footer</footer>
    </body>
  </html>
  

HTML4

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
          "http://www.w3.org/TR/html4/strict.dtd">
  <html>
    <head>
      <meta charset="UTF-8">
      <title>Sample page</title>
    </head>
    <body>
      <div role='banner' id='header'>
        <h1>Site Name</h1>
      </div>
      <div role='navigation' id='main-nav'>
        <ul>
          <li>Home</li>
          <li><a href="./otherpage/">Other Page</a></li>
        </ul>
      </div>
      <div role="main">
        <div>Here's an article</div>
      </div>
      <div role='contentinfo'>Footer</div>
    </body>
  </html>
  

Multimedia

When using multimedia, we must provide means for everyone to consume the media. Multimedia is anything that uses audio and video

Closed Captioning

Videos with audio require synchronized closed captioning. Anything said in the video must be included in the closed captioning, and anything in the closed captioning must be said in the video.

Transcripts

Transcripts can be beneficial as users are able to read and search them must faster. Anything said in the video or audio must be included in the transcript, and anything in the transcript must be said in the video or audio.

Audio Description

Audio description ensures any information displayed visually is conveyed via audio. The most basic example of this is text on screen. All the text on screen should be available by audio. This can be done a couple of ways. The script for the video can be written in a way that all visual information is read by the narrator. The other way is to add a separate audio track that describes the visual content. This can be done with a special player or a separate version of the video with the audio baked in.

Keyboard Access

Just a note about keyboard access. All video controls should be accessible via the keyboard, but its also worth noting the time stamp information should be available to screen readers as well.

Time Outs

If timeouts are used, you must give the user at least 20 seconds to request more time.

Testing

1. Identify any timeouts on the page
   • Contact the developer to find these
2. Trigger the time out
   • If you are not able to request more time or the request lasts less than 20 seconds, its a failure

Web Text Properties

Having the HTML properties of your website set properly ensures assistive technology interacts with your site correctly. AT will read foreign languages, but they need to know when the language differs from the page's default.

Testing

1. Open the inspector panel
2. Locate the main html tag
   • If the lang attribute isn't set to the correct language, this is a failure.
3. Identify any content that differs from the default language, make sure the content has its own lang attribute set with that language
   • Any alternate language content not set constitutes a failure

Examples

Passes

Sus ojos son verdes.

    <p lang="es"> Sus ojos son verdes.</p>
  

This text passes because the lang="es" attribute identifies its content as Spanish.

CSS Dependence

CSS Dependence just means site shouldn't rely on CSS to be functional or understandable. Often sites will use CSS to load important images for example. This is bad for several reasons. Background images can't be tagged for accessibility and with CSS turned off they aren't shown.

The other issue that pops up with CSS dependence is content order. Sometimes, content will be arranged on screen with CSS instead of the natural code flow.

Testing

1. Disable CSS
2. Check for missing information (images, text, etc)
3. Check for code or other items the developer doesn't want you to see
   • Confusing elements shouldn't be present such as CSS, JavaScript, or other code, etc.
4. Check for overlapping text

Frames

When using frames, its important that all content contained in them is accessible.

Testing

1. Identify all frame / iframe elements on a page
2. Using the keyboard, navigate to each frame to ensure content is accessible
3. Check the title or name attribute of each frame for a description of the content

Examples

Passes

<iframe title='Provide Name Form' src="../iframeform/"></iframe>
  

Correct title is provided. This would also pass if this information was in a name attribute.

Failure

<iframe src="../iframeform/"></iframe>
  

This iframe doesn't have a title or name.

<iframe src="../iframeform/" name='Provide an address form'></iframe>
  

This name isn't correct

Maps

An embedded Google Map alone is not screen reader accessible, but the driving and walking instructions are. To maximize the effectiveness of Google Maps:

1. Include a street address and zip code to enable Google Map search.
2. Include basic text-based directions.
3. A Google Map is typically embedded within an iframe. Make sure the iframe includes a title attribute.

Passes

<iframe title='Google Map with a pin dropped on San Francisco City Hall' src="https://maps.google.com/..." width="400" height="350" frameborder="0" style="border:0" allowfullscreen></iframe>
  

Map is provided with specific location so link to directions is available and title is given with enough context to inform the user.

Plug-ins

Plugins provide extended functionality not native to the browser. Examples include PDF, Flash, Shockwave, Silverlight, and Java.

Anytime a plugin is used on a page, they must be tested for accessibility.

Pro-tip: Flash always fails for accessibility, but is often given an exception.

Testing

1. Identify any plugins on the page
2. Identify a link to download each plugin
   • Plugin download links can be provided on a single page. Ensure this page is referenced on pages that require plugins.
3. Check each plugin for accessibility
   • Most plugins have a VPAT available on the manufactures website which lists its accessibility findings

Alternative Versions

Alternate versions of web pages should only be used when the main page can't be made accessible. There are very few instances where they would be necessary. Live dynamic mapping applications is one example.

In a situation where an alternate version is provided, it must provide the same information and provide similar functions.