Did you know?

We perform accessibility testing for MIT web sites before launch and during redesign phases. Contact us to learn more.

MIT Web accessibility guidelines


General Overview:

- Audiences for Accessibility
- 5 Minute Quick Check for Accessibility

Best Practices

Audiences for accessibility

Visual disabilities:
Difficulty accessing unlabeled graphics, icons, buttons, multimedia. Info may be lost in poorly marked up tables, forms and frames. May use keyboard navigation rather than a mouse. Use screen enlargement, screen readers or Braille displays. Problems with font sizes, color contrast or other display problems.
Hearing disabilities:
Need captioning for audio and video.
Physical disabilities:
May need to substitute mouse use with keyboard, voice input, or other input methods.
Cognitive disabilities:
Need consistent navigation structure. Overly complex presentation can be a problem. Flickering or strobing designs can be a problem.
Technology or bandwidth challenged:
May have older browsers or computers, may have a dialup connection. Large files or those requiring special plugins may be a problem.
Pew Internet and American Life Project:
Part 7 - The Disabled: A Special Analysis


Accessibility: Basic Goals

Site content should be accessible to users employing screen readers, those relying on keyboard only navigation, low-bandwidth visitors, people with Javascript disabled within their browsers, and those using other assistive technologies. In short, sites should be accessible to the widest possible audience.



5 minute Quick check for accessibility on your web site:

  1. Turn off images in your browser
    (make sure image place holders are turned on)
  2. Turn off support for JavaScript
  3. Tab through the page, try navigating without a mouse
  4. Try to change the standard font colors and styles in your browser
  5. Try to increase the font size by using the browser (view > text size > increase)
  6. Turn off support for stylesheets, does your site still makes sense?

The following techniques may be used to achieve a basic to intermediate level of accessibility.

Label all images: use ALT Tags

  • Alt tags and title tags should be added to the source code for the embedded images.
  • Structural images (spacers, backgrounds) can contain empty tags , i.e. alt="".
  • Images (navigational buttons, banners, and image maps) with descriptive text can borrow the text shown in the graphic and use this text for both ALT and title attributes.
  • If an image conveys complex information, such as a graph, use a brief ALT tag and link the image to a longer page with an extended explanation using the longdesc tag: <IMG SRC="graph.gif" ALT="graph of donations by donor type" LONGDESC=http://www.website.com/donationsgraph.txt title="graph of donations by donor type">
  • ALT tags are often misused.

Note: Images used to convey content (e.g. equations, diagrams), should be delivered to the site developer with alt tag tag and long description text (via email or separate document). Developers should not be responsible for creating this text.


Create structure: use headers and proper markup

  • Pages that are well structured, follow proper syntax, and pass the W3C validator are most accessible.
  • Headers ( <H1> - <H6> ) can be skipped and can make the site more navigable to users with screenreaders, text only browsers, etc.
  • Label links properly, avoid using "click here" - be brief but descriptive.

Improve navigation: use skip Links

  • Skip links should be used to allow screen readers to go directly to desired content or to skip over navigation elements that are common to each page.
  • To create a skip link: Use an <href> tag to link a 1 x 1 clear image gif to an anchor on the page. Like so:
      <a href="#content"><img src="images/1pixel.gif" alt="Skip to content" /></a>
  • Use both id and name when creating anchor tags: <a id="content" name="content">
  • You may also create a skip link that's visible, this will benefit those relying on keyboard shortcuts as well as screen readers. This is often a "skip to content" link on the immediate top left of the page.

Keyboard friendly shortcuts: use access keys

  • Access keys can provide a shortcut to major areas of the site (home, search, etc.).
  • Access keys are built by assigning a key within the <href> tag.
      <a href="../index.html" accesskey="1">
  • To follow access key links on the page, users must hit a combination of keys:
      Mac: CONTROL + access key follows link.
     Windows: ALT + access key brings focus to the link. Users must hit "enter" to follow link.
  • Go ahead and try it. The access key for the Adaptive Technology in Computing (ATIC Lab) home page is is the number 0 on your keyboard.

    Here's the link code:
    <a href="http://web.mit.edu/atic/www/index.html" target="_blank" accesskey=0>< img src="../images/spacer.gif" alt="link to home page accesskey=0" width="1" height="1" border="0" /></a> link to home page
  • You can let users know which keyboard shortcuts they can use, by creating a page for your accessibility statement that lists each of these shortcuts and how to use them on a mac or PC. The accessibility link to this page should appear at least on the homepage but ideally on all pages i.e. within the global navigation or footer links of your site.

Access Keys are a topic of hot debate, read more about why.

Using Accesskeys - Is it worth it? http://www.wats.ca/show.php?contentid=32

Accesskeys and Reserved Keystroke Combinations
http://www.wats.ca/show.php?contentid=43

Screen Readers & Assistive Technologies:

  • Assistive Technologies encompass a wide range of software and hardware designed to aide in accessibility. See our list of Assistive (or Adaptive) Technology devices.
  • Skip links and access keys benefit 1.) users with screen readers e.g. software that's able to read web pages and operating system prompts out loud and 2.) those who rely on the keyboard alone.
  • Experience the web as a blind person would, see webaim.org's simulation of what it's like to use a screen reader .

Choose color and contrast wisely: never use color alone to convey information

  • Use a symbol or graphic or another treatment that will work in a monochromatic environment.
  • To test a page for effective contrast, print it on black and white printer with the background color included.
  • Color vision deficiencies affect interpretation of red and green as well as yellow.
  • Beige, yellow and orange can be confused with red and green.
  • See your website as a color blind person might, go to Vischeck to run a simulation.
  • An article from Lighthouse International:Effective Color Contrast
  • Safe web colors for color deficient vision
  • A full palette of hex values and how these colors are transformed for those with color deficient vision
  • New Architect Article: Considering the Color Blind

Allow for font resizing: ensure control over fonts

  • Stylesheets created with pixel measurements (px) cannot be resized in Internet Explorer for Windows. To allow for resizing on windows size your stylesheets using another measurement such as em, pt, or relative sizes (keywords: i.e smaller, larger, etc and percentages).
  • Read the W3C spec on CSS relative fonts and font size properties
  • Specify generic font family with font declarations in stylesheets.
  • Specify all five attributes: text color, link, vlink, alink, and background colors in all documents (HTML and CSS files) to avoid a clash between your stylesheet and one that the user may have set by default.
  • We recommend using a body font of 95% or 12 points (similar to 12 pixels in size but percents and ems are resizeable on IE for windows). This is roughly equivalent to .85 - .95em depending on screen resolution settings (i.e. 96 or 72dpi).

    Read more about relative font sizing and accessiblity on A list Apart's web site
  • See screenshots of styled fonts by browser, each is listed by platform and font style. Or by method.

Avoid tables when you can: use div tags instead

  • Use stylesheets and div tags for visual layout.
  • Use tables for layout if they make sense when linearized.
  • Use basic header information for data tables (the <th></th> element).
  • Use <caption></caption> elements and summary attributes whenever possible; summary=" " is desirable for layout tables.
  • See our detailed table examples for further explanation
  • Jim Thatchers's tutorial on accessible tables and accessible navigation using tables

PDF Files

  • Ask yourself: is PDF necessary to deliver the information you're posting?
  • Always offer alternative redundant information in accessible HTML format.
  • Convert PDF files to HTML, check to see if the HTML is well structured and valid.
  • Users without the acrobat plugin and anyone relying on screenreaders may not be able to access the information contained within the PDF.
  • Learn to use the accessibility extension for Acrobat 5 & 6 when creating PDF files from scratch.
  • Learn how to tag your PDF to increase accessibility for all users.
  • See MIT's PDF FAQ and Guidelines for PDF creation.
  • Adobe's Tips and Techniques for creating PDF files.
  • PDF Zone's 10 Tips for Better PDFs.
  • Adobe Acrobat 5 the Professional User's Guide, a book by By Donna L. Baker

Accessible Forms:

(Source: list from Chapter 12 of Joe Clark's book Building Accessible Websites, New Riders, 2003)
  • Group related form options using <fieldset></fieldset> and <optgroup></optgroup>.
  • Do not code forms so that an action takes place as soon as the visitor makes a selection. Include a Go button (or similar function) so the visitor has control over what happens when using the form.
  • Use as many of the five possible form-element text equivalents - alt, name, value, id, and title - as is legal for the HTML version declared in that page's DOCTYPE.
  • Form example with detail from webaim.org

Interactive Content/Flash

  • Alternate, low-bandwith versions of all interactive content and Flash pieces should be provided.
  • Flash 5 and MX have support coding for access keys in actionscript, use keyboard equivalents for mouse movements such as onMouseOver, OnClick, etc. when possible.
  • Use the accessibility features provided in Flash MX.
  • Caption your Flash, use NCAM's free MAGpie Flash captioning tool.

Javascript

  • All javascript-based navigation should include alternate navigational images or text links within <noscript> tags.
  • The href tag should be used for a direct link to content, either in the parent (target="_parent") window or a new (target="_blank" ) window, so non-javascript enabled browsers can access the content.
  • Use keyboard event handlers in addition to mouse event handlers
    e.g. <onclick=openWin(index.html) onkeypress=openWin(index.html)
  • Read about how to make Javascript "jump lists" accessible: http://jimthatcher.com/webcoursea.htm#Webcourse10.1.5
  • See detailed information about non-mouse event handlers at watchfire.org
  • When using javascript event handlers, return false so the href link is not followed by javascript enabled browsers.
  • The Trace Center's Javascript accessiblity issues in detail

Pop up windows

  • When pop-up windows are invoked to display separate html content, use the onclick and onkeypress event handlers to open the window (both returning false so the href is not followed by javascript enabled browsers) and point the the href directly to the html content, targeting a "_blank" window. This will allow javascript-enabled keyboard users to benefit from javascript window control, while allowing non-javascript enabled users to view the content, albeit in a full browser window.

     <a href="index.html" target="_blank" onclick="openWin(index.html); return false;" onkeypress="openWin(index.html); return false;">

Video Captioning

Simulations (JAVA, etc.)

  • Provide alternate text descriptions or other meaningful equivalent
  • Sample simulation in JAVA

ATIC Home