Project 2:  Build An Accessible Web Page

Due:  Thursday, September, 14th  *in class*

In this week’s project, you will create an accessible web page. This web page you’ll start with has been constructed to allow you practice with a wide variety of different kinds of web content, and thus practice making a wide variety of web page content accessible. Another way of saying this is that the web page you’ll start with is absolutely dreadful, but Jeff has seen all of the problems it contains on web pages not only “in the wild” but in accessibility evaluations he’s participated in.

You will explore not only making content that is accessible, but also explore how to use tools to automatically assess the accessibility of web pages. Determining whether a web page is accessible is quite difficult to do automatically, and so part of the goal of this exercise is to become familiar with some of those limitations.

Below is a list of what you’ll need to do for Project 2. Rather than a formal write-up, please keep a “lab notebook” that includes the results from the activities below. You’ll turn in that, along with your final web page. You’ll also discuss your web page, what was inaccessible about its original form, and what you did to make it accessible in class.

Web Page Overview

The purpose of this web page is to advertise accessibility and provide some hints for people who want to get started. You’ll make the basic web page accessible, make its embedded video accessible, etc. The page is a bit ridiculous because of how many different kinds of content it contains all on one page, but is formed of fairly common components.

The base web page (HTML, CSS, and Javascript) are located in the
base-webpage.zip.

The initial state looks visually like this:

The final state of the web page will look visually similar, but it will be much more accessible!  Your final web page might look a bit different. Please feel free to deviate from the style here if you need to do so for better accessibility or usability.

Exploring Automatic Accessibility

Before getting started in your manual evaluation of the accessibility of this page, use one of the many (free) accessibility evaluation tools to get a quick sense of obvious problems that should be fixed. There are many such tools, and you’re free to use whatever one you want, but a good option is WAVE.

Copy & paste the output from WAVE (or your preferred tool) into your lab notebook. Then write a short description of the main problems that the tool was able to discover.


Making the Page Accessible

To make the web page accessible, please pay attention to the following points. To receive an A, find and fix at least one problem in each category below; if you prefer a B, complete something from all but 1 category; for a C, complete something in all but 3 categories.

Record in your lab notebook a description of each problem, your estimate of the severity of the problem, how you fixed it, and whether or not it was detected by the automatic accessibility evaluator you tried in the previous step. You might optionally also look up what guideline it breaks in WCAG 2.0, and note the level of compliance it corresponds to (A, AA, AAA).

  1. Headings and Landmarks
  2. Good Alternative Text for Images
  3. Form Labels
  4. Form Widgets without Semantics
  5. Video Captions
  6. Audio Descriptions
  7. Tab Order & Visible Focus
  8. Color Contrast
  9. Keyboard Access
  10. Information Conveyed Only via Color

Headings and Landmarks

Headings and landmarks provide an outline for the web. This helps in reading, but also helps in efficiently navigating the page if you’re using a screen reader. Headings are the <h1> through <h6> HTML tags.

You can read more about headings and other elements for providing semantics at this WebAim article on
Semantic Structure.

Good Alternative Text for Images

Visual information have an alternative text form so that users who can’t see the content can still access that information. While somewhat intuitive, deciding on good alternative text and which images need alternative text can be a little tricky. When in doubt, label an image.

You can read more about images and alternative descriptions at this WebAim article on
Alternative Text.

Form Labels

Providing labels for form fields makes them easier to understand for someone who is not viewing the visual layout of the page, or is not viewing it in the way it was designed for (e.g., at a different level of magnification).

You can read more about form labels, including what makes a good form label and who to assign them on this WebAim article on Creating Accessible Forms.


Form Widgets without Semantics

Dynamic HTML and Javascript allow new kinds of elements to be created from scratch using other HTML elements as building blocks. For example, if you take a <DIV>, visually style it to look like a button, and then add some Javascript to it so it responds like a button when pressed, it’s essentially a button. Except, if it’s not been coded to advertise that it’s a button, a screen reader won’t know what it is. If it’s instead a more rich control, it also may need to convey its state. For example, a radio button needs to convey whether it’s checked and which radio button family it’s part of.

The W3C offers examples of using ARIA to make such hand-crafted widgets accessible.

Video Captions

A deaf or hard of hearing person cannot listen to video content without a suitable visual substitute. One way to do that is to provide captioning for the video, which means creating a text alternative for the speech in the video and allowing it to be displayed.

Different video players have different ways of allowing you to provide captions. One relatively easy way to create captions is to upload your video to YouTube,
request it automatically caption your video, and then edit those captions. Once you do this,  you can either keep your video on YouTube, and use the embedded player to put the content on your own site. Or, you can download the caption file, and put it into your own player. For example, the HTML5 <video> tag accepts captioning files, and is pretty easy to use once you have created the captioning.

Audio Descriptions

Audio descriptions are the video equivalent of alternative text for images. Oftentimes, visual content in an image is not mentioned in the audio track. In that case, you’ll need to provide information about the visuals in the audio track so that people who can’t see the visuals have access to them. This can be tricky, mostly because of timing -- it can be really hard to fit in audio descriptions into natural pauses.

You can add video descriptions in a few different ways. One is to use video editing software, such as Adobe Premiere or iMovie, to add a new audio track to the video that contains the descriptions. Another way is to upload your video to YouTube, and then use the YouDescribe service to add the alternative descriptions. For some reason, it’s a little tricky to find the video you want to describe from the YouDescribe interface -- the best approach I’ve found is to post your video publicly on YouTube, then search for your username, which should display all of your public videos.

Regardless of tool used, you’ll want to think about what you’ll need to describe, versus what doesn’t need visual description. For instance, if a person is talking, there’s probably no reason to say that there is a person on-screen. But, you might want to describe facial expressions, or mention someone sneaking onto the screen.

Here’s a video describing
how to create audio descriptions using iMovie, including a number of useful tidbits about what goes into a good audio description. Here’s a short professionally-created video that has been audio described. You might also check out your favorite movie’s special features to see if it has an audio description track that you can turn on. Many popular movies have these nowadays!

Tab Order & Visible Focus

A proper tab order means that as you move through the page with the TAB and SHIFT-TAB keys, a logical order is followed. This is the natural result in simple pages, but as content can be placed pretty much wherever you want. And, as web pages are increasingly formed by brining in content for various sources, sometimes the result is a non-sensical order.

Another element of this is that to be able to effectively “tab through” a web page, you need to be able to see what element currently has focus. Setting the outline property to “none” in CSS, or making the change on focus too difficult to see, can make doing so very hard. The focused element on a page should be easily visible.

WebAim has more about these issues in its
Keyboard Accessibility page.

Color Contrast

The foreground and background need to have sufficient contrast in order to be possible to see. WCAG 2.0 provides very specific guidance on acceptable contrast levels, but you might wonder how you can test that?  Fortunately, WebAim has a free and easy contrast checker.

Keyboard Access

All functions of the page should be possible to use with the keyboard. This is important for people who can’t use the mouse, or are using some other input device that effectively acts as a keyboard. Most “soft keyboards” effectively act as a keyboard as far as the web page is concerned. Software keyboards take input from switches, head mouses, speech, eye gaze, etc., and turn it into key presses. So, if a page doesn’t work for a keyboard, it won’t work for these inputs either.

We already covered tab order and visible focus in a previous item, so for this item you’re looking to make sure that all functionality is possible without the mouse, i.e., can you press all the buttons, follow all the links, interact with form controls, etc.

Information Conveyed Only via Color

Information conveyed only in color is not accessible to people who cannot see or who have limited color vision. As a result, color should be supplemented with other content that is more semantic in order to make it accessible. Avoid such things as, “the items in blue are required”, or denoting links only by their color (and not by some other font decoration, such as underlining).

You can learn more about color blindness and other related issues at WebAim’s article on
Color-blindness.

Project Turnin and Grading

You have each been added to a shared folder on “Box” with your Andrew ID as the folder name. You should have received this invitation to <your username>@andrew.cmu.edu. Please put your “lab notebook” document, your fixed web page, and anything else relevant to the project in the appropriate folder within the shared folder. You should see a folder labeled p2 through p12.

Your project will be graded in class with a partner. You will be asked to describe the elements you completed, and your partner will submit your grade via a Google Form in class. Then, you’ll switch and grade the other person’s.


This page and contents are copyright Jeffrey P. Bigham except where noted.