EDUCAUSE Accessibility Guidelines

Posted by Terrill Thompson on January 8, 2009

This guide is a working draft developed by the IT Accessibility Constituent Group at the request of EDUCAUSE staff. It is designed to provide guidance to authors, reviewers, and publishers associated with EDUCAUSE Review Online, and to the larger EDUCAUSE community, on how to ensure that web content is accessible to all users, including those with disabilities.

What is Accessible Web Design?

Accessible web design is the practice of designing and developing websites that are usable by everyone. People who use the web have a growing variety of characteristics. As web developers, we can not assume that all our users are accessing our content using the same web browser or operating system as we are, nor can we assume they're using a traditional monitor for output, or keyboard and mouse for input. For example, users who are blind may access a web page using an audible interface such as screen reader software or tactile interface such as a refreshable Braille output device; users with low vision may be viewing the page with large fonts or high contrast color scheme; users with physical disabilities may be navigating the web without a mouse, instead using keyboard, speech recognition technology, or other assistive technologies. The growing variety of compact web-enabled mobile devices adds further variety to the user agent spectrum. The following guidelines are designed to assure that EDUCAUSE content does not place constraints on users by requiring that they use a narrowly defined set of supported devices. By following these guidelines, EDUCAUSE content can be accessible to everyone.

Overview of Web Accessibility Guidelines and Standards

Web accessibility is formally defined by the World Wide Web Consortium (W3C), whose Web Content Accessibility Guidelines (WCAG) 2.0 became an official W3C Recommendation in December 2008. WCAG 2.0 organizes web accessibility success criteria into four general principles:

• • Perceivable - content must be perceivable to all users. Keep in mind that users perceive content with a variety of senses, output devices, and settings.

  • Operable - user interface components, including menus, links, and controls must be operable by all users. Keep in mind that users operate such controls using a variety of input devices, including mouse, keyboard, stylus, touch screen, speech, and other assistive technologies.

  • Understandable - content and the user interface must be usable and easy to understand.

  • Robust - Content must use standard technologies and be coded in a way that will increase the likelihood of its being supported across all web-enabled technologies including assistive technologies and future technologies.

For additional information, consult the comparatively user-friendly WCAG 2.0 Checklist created by WebAIM at Utah State University.

Another set of relevant standards is the Electronic and Information Technology Accessibility Standards, developed by the federal Access Board in support of Section 508 of the Rehabilitation Act as amended in 1998. Section 508 is federal law that requires federal agencies to ensure accessibility of their electronic and information technologies, including web sites, software, and multimedia, plus three other categories of IT. The Section 508 standards, published in the Federal Register in 2001, are based in part on the previous version of the WCAG (version 1.0), and have been adopted by many states and higher education institutions. These standards are currently under review.

Accessible Word Processing Documents

Additional information about creating accessible Microsoft Word documents, and converting them to HTML, is available in the WebAIM article simply titled Microsoft Word.

Document Structure and Presentation

• • Place content in logical reading order so that the document renders correctly when the display size is changed, or when the document is magnified or converted into alternative formats (audio, HTML, PDF, DAISY, Braille etc).

  • Avoid complex layout, sidebars and other ornamentation as they make it difficult to maintain a logical reading order.

  • Avoid placing content in drawing-canvases or text-boxes as these are floating objects and flow to the bottom of a page’s reading-order

  • Use structural and stylistic features that are built into word processing software (e.g., headings, paragraphs, lists, sections, headers/footers, tables, columns, forms). This ensures that objects on the page are coded semantically, and this information is passed on to HTML or PDF files when exported, and plays a critical role in screen reader users' ability to navigate efficiently through these documents.

Images / Non-Text Objects

• • Always provide an alternative text description ("alt text") for all non-text objects (graphs, images, illustrations, multimedia, etc). Users of non-visual devices such as screen readers or Braille output devices depend on alt text in order to access the essential content of the images.

  • Most word processing software applications provide a means of adding alt text to images, and this is passed on to HTML or PDF files when exported. For example, in Microsoft Word 2003, you can add alt text to images by right clicking on an image, then selecting "Format Picture", then selecting the "Web" tab, then entering text into the "Alternative Text" field. In Word 2007, this same feature is accessed by right clicking on an image, then selecting "Size", then selecting the "Alt Text" tab.

  • If images are provided as separate image files (e.g., JPEG, GIF, PNG) an alternative text description must be provided separately within the document, clearly identified as alternate text for a particular image (e.g., "Alt Text for Figure1.gif").

  • Alt text should communicate the essential content of the image as efficiently as possible.

  • Alt text should not be provided for decorative elements.

  • If multiple images are used for a single concept, they should be merged into a single composite image.

  • If images communicate highly detailed visual information, as in charts or graphs, a long description must be provided in addition to the shorter alt text. This should be provided separately within the document, clearly identified as a long description for a particular image (e.g., "Long Description for Figure1.gif"). See the section "Images Requiring Long Description" below for information about how this information is utilized in HTML.

Data Tables

When a non-visual user (e.g., screen reader or Braille user) reads a data table, the default reading order flows by row from the top left cell to the bottom right cell in the matrix. As tables increase in complexity (especially if there are nested columns or rows), it becomes increasingly challenging for non-visual users to understand their position with the structure of the table. HTML provides markup that allows table structure to be explicitly communicated to non-visual users. Word processing software does not have similar markup or functionality. Therefore, the process of converting a data table to HTML requires extra steps to properly mark it up for accessibility. See the section on Data Tables under Accessible Web Pages for more information about accessible table markup in HTML.

Links

• • Use link text that makes sense out of context. Screen readers are equipped with functionality that allows users to pull up a list of links on the page, and navigate through that list either in order of appearance or alphabetically. In this context, links that are dependent on context (e.g., redundant links or "click here") make no sense.

  • Use link text that is succinct and easy to verbalize. Speech recognition users select links by speaking the link text. Long, complex link text, including URLs, are difficult to verbalize and should therefore be avoided.

Accessible Web Pages

Document Structure and Presentation

HTML is a semantic, structured language. Assistive technologies such as screen readers utilize this structure extensively, so it is critical that HTML be used properly to support accessibility.

• • HTML heading elements must be used to markup all headings and subheadings. If used properly, the headings on a page form an outline of the content of that page.

  • HTML list elements must be used to markup any lists of content, including navigation menus (which are lists of links).

  • Forms must include markup that explicitly communicates the structure of the form, and the relationships between its parts. The most fundamental step in creating accessible forms is to using the HTML label element to identify labels and explicitly associate them with the form fields they represent. Additional information about accessible forms in HTML is available in the WebAIM article Creating Accessible Forms.

  • HTML should be validated using the W3C Markup Validation Service. This increases the likelihood of interoperability across platforms and browsers.

Images /Non-text Objects

Images must have alternate text in order to be accessible to non-visual users. The method for providing alternate text varies depending on the content of the image, and the method of submission:

• • In HTML, the <img> element must have an alt attribute, e.g., alt="description of the image"

  • If the image is decorative, the best practice is to deliver the image as a background image using Cascading Style Sheets. However, if an HTML <img> element is used, include a NULL alt attribute (alt=""). This is a standard practice that instructs screen readers to ignore the image.

  • Alt text should communicate the essential content of the image as efficiently as possible.

  • If images contain text, repeat the text verbatim.

  • If images contain highly detailed information, as in charts or graphs, provide a succinct alt attribute (e.g., alt="Figure 1"), and provide additional detail using a long description (see below).

Images Requiring Long Description

If images communicate highly detailed information, as in charts or graphs, the important content from these images must be communicated in a long description.

• • The long description should be provided in a separate HTML page.

  • The <img> element should have a longdesc attribute, which points to the URL of the separate web page where the long description is available (e.g., <img src="figure1.gif" longdesc="figure1_description.html"/>).

When screen reader users encounter an image with a long description, they are informed that the image has a long description, at which point they have the option of reading that description or skipping it.

Data Tables

The following HTML markup is needed in order to ensure that non-visuals users can navigate tables with full awareness of their position within the table, and of how all parts of the table are related.

• • Wherever possible, avoid complex tables with nested rows and columns or split or merged cells. Even with accessible markup, complex tables present usability challenges for non-visual users, and they are not easily converted into alternative formats such as Braille.

  • Include a summary attribute with the table element (e.g., <table summary="This table shows...">). The summary attribute is read by screen readers, but is not displayed visually. The purpose is to provide a succinct overview of the table's content and layout so screen reader users can explore the table with an idea of what to expect.

  • Markup the table's caption using the HTML <caption> element. This ensures that the caption is explicitly associated with the table, for non-visual users.

  • Markup column and row headings with the HTML <th> element, and include a scope attribute to identify whether the heading is for a column (<th scope="col">) or row (<th scope="row")

  • For complex tables, include id attributes on all <th> elements, and headers attributes on all <td> elements, where the value of the headers attribute is a space-delimited list of id's that correspond with the current table cell.

Links

• • See the corresponding section above, under Accessible Word Processing Documents.

  • Avoiding causing links to open in a new window. This can be disorienting to users of assistive technologies, and is unreliable given the widespread use of pop-up blockers.

General Considerations

• • Be sure that all links, form fields, and controls can receive focus and be operated without a mouse. This can be tested by navigating through a web page using the Tab key in most browsers.

  • Avoid using color as the sole means of communicating differences or other information. Keep in mind that some users, including those who are blind or color blind, are unable to perceive differences between color.

  • Avoid causing objects on the screen to flash (i.e., in a strobe-like effect). Flashing objects can trigger seizures in susceptible individuals.

  • Avoid using or requiring plug-ins or other technologies that do not honor the user's operating system or browser settings for font choice, font size, and alternative color scheme. This can be tested by changing these settings within the preferences of the browser or control panel of the operating system, then refresh the web page to determine whether it's still usable.

Accessible PDF

Portable Document Format (PDF) is a file format developed by Adobe to deliver and render on the web, documents created for print. It preserves a source document's original style, layout, formatting, fonts, images, etc. A PDF document uses a helper agent to “view” or “read” the document on the screen making it independent of operating system, authoring software and display device.

General Types of PDF Files

• • Image: a graphical representation (unstructured) of the original document. They are created by scanning the original document as an image and are inaccessible to assistive technologies such as screen readers.

  • Searchable Image: (structured) consisting of image + electronic text of the original document. They are created by using the Adobe Distiller or other PDF writers. The text is searchable and is partially accessible to screen reader, although without the markup that is required for full accessibility.

  • Tagged Document: a true electronic document, with searchable text and an underlying semantic structure. This is the only type of PDF that has full support for accessibility, including a heading structure that can be easily navigated by screen reader users, support for alternative text for images, and the ability to reflow (wrap) document text when zoomed. Tagged PDF is created by default when converting to PDF from Microsoft Word, Excel, and PowerPoint using Adobe's Acrobat PDFMaker plug-in for Office.

Creating Accessible PDF Files

Craft original document with accessibility in mind (see the earlier section on Accessible Word Processing Documents). Keep in mind that:

• • Complex tables may not be correctly interpreted by screen readers.

  • Complex layouts with multiple layers may not be fully recognized, or might follow a reading order that is not consistent with how the information is presented visually.

The steps for converting a document into an accessible Tagged PDFfile depend on the original source of your document:

• • Documents created in Microsoft Office and several Adobe products are converted by default to a tagged PDF file when exported via the PDF toolbar, the PDF menu, or Save As > PDF. For this to result in an accessible document, care must have been taken when authoring the document to include semantic structure, add alternate text to images, and other accessibility techniques as described in the Accessible Word Processing Documents section of these guidelines.

  • PDF documents generated using Acrobat Distiller and other PDF writers are not tagged by default. However, accessibility can be added post-production using Adobe Acrobat. The first step in making the document accessible is to select the menu item Advanced > Accessibility > "Add Tags to Document". Note that this is only the first step. Additional steps must be taken to add alternate text to images, add heading structure, check for proper read order, etc. Adobe Acrobat provides tools that support these steps in the Advanced > Accessibility menu. An audible text reader is also available in both Acrobat and Acrobat Reader, accessed via the menu by selecting View > "Read Out Loud". Additional information about checking for and fixing accessibility in PDF files is available in WebAIM's article titled PDF Accessibility.

  • PDF documents created as scanned images require the same procedure as in the previous item, plus the additional first step of performing optical character recognition. This can be done within Adobe Acrobat via the Document > "OCR Text Recognition" menu.

Accessible Slides

When presentation slides are delivered over the web, there are two general accessibility considerations: The slides must be created with attention to accessibility; and the slides must be delivered in a format that is perceivable and operable to all users. One good test for operability is to try to advance the slides, or operate any other slide controls, using keyboard alone. Since the most common slideshow application is Microsoft PowerPoint, these guidelines focus primarily on PowerPoint accessibility.

Creating Accessible Slides

• • Use a standard design style template. Templates create organized placeholders for standard content. Using them increases the likelihood that when content is exported it will be properly exposed to conversion tools and assistive technologies.

  • Be attentive to reading order. If text boxes are added to a standard slide design, be aware that the content of the text boxes will be appended to the end of the read order, which in some cases may result in an illogical flow for non-visual users.

  • Add alternative text to all images. The technique for doing so in PowerPoint is similar to that of Microsoft Word: In PowerPoint 2003, you can add alt text to images by right clicking on an image, then selecting "Format Picture", then selecting the "Web" tab, then entering text into the "Alternative Text" field. In PowerPoint 2007, this same feature is accessed by right clicking on an image, then selecting "Size and Position", then selecting the "Alt Text" tab.

  • Use discretion with embedded multimedia, automatic progression, transitions, custom animations and similar features when PowerPoint presentations are intended for distribution over the web. If the PowerPoint will be distributed in its original format, some of these features may inherently pose accessibility challenges. If the PowerPoint will be exported to HTML or PDF, these features may not survive the export, and the remaining content may be impacted by their absence.

  • Provide sufficient contrast between foreground and background colors, and avoid using patterned backgrounds

  • Give each slide a unique title, since this information can help to facilitate navigation, both within PowerPoint and within exported formats.

  • If inserting diagrams, charts, or tables into a PowerPoint slide, consider accessibility best practices. Techniques vary depending on how the slides will ultimately be delivered. Microsoft provides additional details related to specific PowerPoint features in their document Creating accessible PowerPoint presentations.

Distributing Slides Over the Web

• • If PowerPoint slides are distributed in their native format, users must have PowerPoint or an alternative software package that is capable of reading PowerPoint. A free PowerPoint Viewer browser plug-in is available from Microsoft, but it does not work in all browsers nor across all operating systems, and does not work well with assistive technologies.

  • PowerPoint has built-in features for saving to web pages, but the output is a complex frameset with pages that are coded in ways that are not well-supported by assistive technologies.

  • PowerPoint can be converted to valid, accessible HTML with software such as Virtual 508.com Accessible Web Publishing Wizard for Microsoft Office. In addition to exporting to an accessible format, both products provide a wizard interface that helps to identify accessibility problems and solutions.

  • PowerPoint slideshows can be exported to PDF using Adobe's Acrobat PDFMaker plug-in for Microsoft Office, accessed via the PDF toolbar, the PDF menu, or Save As > PDF. As with Microsoft Word, this plug-in exports by default to a tagged PDF file. However, for this to result in an accessible document, care must have been taken when authoring the document to use standard design templates, add alternate text to images, and other accessibility techniques as described in the preceding section. The resulting output is a single file, and is therefore easily distributable.

Accessible Video

Accessibility of video content affects many groups of users, including people who are unable to hear the audio content, people who are unable to see content that is presented visually, and people who are unable to access the player controls.

• • Video content must be captioned. Otherwise the content is inaccessible to the deaf or hard of hearing. There are a growing number of software tools and services available, many of them free, that support adding captions to video. Consult WebAIM's Captioning Resource List for additional information.

  • Video content must be described. If video content is communicated visually and is not already described in the audio, this content is inaccessible to people who are unable to see it. This content must be described, either in a transcript accompanying the video, or via audio description, a standard technique by which video is supplemented with a narrative track that describes visual content as it's happening.

  • A transcript should be provided. This benefits users who don't have the technology or bandwidth to view the video, as well as those who want quick access to information without watching the entire video production.

  • Video must be delivered in a player that (a) is accessible by keyboard to users who are unable to use a mouse; and (b) has buttons and controls that can be read by screen readers.

Accessible Audio

Audio-only content such as podcasts must be accompanied by a transcript. Otherwise the content is inaccessible to the deaf or hard of hearing, is not searchable, and can be inconvenient to users who want to quickly retrieve specific information from the presentation.

For issues related to audio that is part of a video, see the preceding section.

Accessible On-line Applications

On-line applications such as interactive games, automated simulations, etc., are each unique, and therefore must be evaluated individually for accessibility. The following is a quick checklist of some of the issues to consider:

• • Can the application be operated without a mouse, e.g., using keyboard alone or speech recognition technology?

  • Is the application accessible to blind individuals using screen readers or Braille output devices?

  • Does the application avoid using color as the sole means of communicating differences or other information?

  • If the application includes audio or video, are these features accessible as defined in the preceding two sections?

  • Does the application avoid causing objects on the screen to flash in a way that may trigger seizures in susceptible individuals?

  • Does the application honor the user's operating system or browser settings for font size or alternative color scheme?

  • If the application changes automatically over time, does it provide a mechanism by which the user can pause or override this behavior?