Home -> (Resources) -> Case study

Please also see my current work at The Enabled Web.

Case study: "College Portrait"

This work was done for the Vice President, Student Services, California State University Long Beach. An abbreviated, non-technical demonstration of the results has been given to senior executives at both CSULB and the CSU Chancellor's Office. The project is an example of how a profoundly inaccessible web document can be transformed using only very basic techniques and skills. The revised document provides full compliance with Section 508 and WCAG, retains the visual look and feel of the original, and substantially upgrades usability for all readers.

The project

The College Portrait, also known as a "voluntary system of accountability" (VSA), was developed by a nationwide consortium of universities and colleges. Its purpose is to present statistical information—demographics, graduation rates, and so on—in a standardized format for easy comparison by prospective students and other interested individuals. The basic document, along with some of the statistics, is provided by the consortium; local information is filled in by each campus. It was first released in beta test form in November 2007; the President of CSU Long Beach had volunteered that campus to participate in the initial testing.

The document was distributed to campuses in the form of a Microsoft Excel® spreadsheet. With local information added, the campus created both Adobe® PDF and HTML versions, using Excel's built-in export capability. Because of the high level of interest, immediate posting on the campus web site was imperative; however, it was clear due to the CSU Accessible Technology Initiative that any posting must be fully accessible. Tom Jewett Web Design llc was chosen to evaluate the document and perform any necessary remediation.

Testing the original

If you already have a favorite set of testing tools, use them as you normally do. Otherwise, you can install my environment quickly and easily on your own computer.

Use the Firefox browser, with both the Illinois Accessibility Extensions and Charles Chen's CLiCk, Speak talking browser extension installed. It's easiest to work in three tabs (or three separate browser instances), which contain:

• this document,
• the original College Portrait HTML version, and
• the revised version.

Working in the original HTML document, you can duplicate the sequence that I used for my first look at this page:

1. Disable images. On the Illinois toolbar, select Text Equivalents -> Show Text Equivalents. Scroll down to view the entire page and compare what you see now to what you saw with images available. Then un-check the Show Text Equivalents selection and look again at all of the information that is available only to fully-sighted readers.
2. Display headings. Same toolbar, select Navigation -> Headings. Notice the empty popup window (no headings present), then close that window.
Visually, though, there certainly appear to be headings on the page.
3. Display table headers. Same toolbar, select Navigation -> Show Data Table Headers. If there were any, they would be shown on the page. None are present, although some information looks like a table (for example, Race/Ethnicity). Turn off the display option, anyway: select Options -> Reset styling and settings from the toolbar.
4. Disable styles. Same toolbar, select Style -> Disable CSS, Style -> Disable Tag Styling, and Style -> Disable Table Layout. Try to make sense of what you are now reading, then either un-check all three style selections or select Options -> Reset styling and settings from the toolbar.
5. Listen. To reinforce what you have just seen, click the mouse cursor just before the (fake) heading "Student Characteristics (Fall 2006)", or just highlight that whole line. Then click the Go button on the CLiCk, Speak toolbar. Listen at least until it reads the block of text beginning "A 71% four-year success and progress rate...", then click the CLiCk, Speak Stop button. As you listen, follow the visual cursor and notice what it is doing. Imagine what it would be like to use only the audio version.
6. Scan the rest of the document. Look at the bottom of the browser window. Click on the tabs labeled "Page 1", "Page 2", and so on. Try to imagine how you would navigate to the various sections if you didn't know in advance where they are. Also notice that the page tabs are in a separate frame. (If your browser window is very wide, you might not see the horizontal scroll bar.)

Problems

With those few simple tests, you have already experienced the major barriers to accessibility in this document. I'll list them more formally in this section, along with a few others that are slightly less critical or would require a more detailed look at the pages to identify.

• There are no useful text alternatives for information contained in the graphics; this includes the entire box of text describing the College Portrait itself! [Section 508, para. 1194.22(a)]
• "Headings" are available to sighted readers only—they are not semantically marked in the code—and there is no other method for navigating through the document with a screen reader [Section 508, paras. 1194.22(d) and (o)].
• The document is not readable without requiring an associated style sheet, and the table layout does not linearize correctly for a voice reader [Section 508, para. 1194.22(d)].
• Information that is really tabular in nature does not have proper row and column headings [Section 508, para. 1194.22(g)].
This can render the data in each cell incomprehensible to voice-reader users.
• Frames are not titled for navigation [Section 508, para. 1194.22(n)]. This could prevent some users from finding the page navigation tabs. In fact, the page will not be displayed at all if the user agent does not support frames.
• Even if frames were not used, the tab navigation between pages makes content essentially inaccessible for all readers on the web.
• There are several instances of link text reading "click here" or otherwise failing to identify the link destination. (Not specifically 508, but a barrier for voice-reader navigation.)
• The page does not use valid W3C-compliant HTML, CSS, or character encoding. (Not specifically 508, but hinders maintenance and causes erratic or improper display in some user agents.)

These are not simply technical violations of Section 508. Taken together, they deny a substantial population of readers equally effective access to the information contained in the document. This raises a strong possibility of adverse legal action under Section 504 of the Rehabilitation Act, a very serious consideration for a publicly-funded university.

Developing a solution

Approaching this project as an application of four-layer design principles (please see the Designed-in accessibility tutorial on this site), it was clear that:

1. The content layer was already provided. Much of it could simply be copied and pasted verbatim into a new structure, although other sections would require some amount of manual data transfer.
2. The structure layer was completely missing. Constructing it would be the central part of the project.
3. The presentation layer was mostly pre-determined. All that had to be done was to build a style sheet that produced a visual effect similar to the original.
4. The behavior layer was not needed, since there were no dynamic elements in the original design.

A number of practical considerations influenced the selection of a remediation strategy, as they would in any project:

• The original data will continue to be supplied in Excel. A spreadsheet is the most common and efficient tool for manipulating statistical data; it also can automatically produce graphics that are important to the visual display of this report.
• This particular spreadsheet is both complex and poorly structured. It simply cannot be exported automatically into an accessible HTML format, either with built-in Microsoft tools or with any available third-party application.
• The underlying data for this document is updated only once a year. Although automatic conversion to accessible HTML is desirable in the long run, it was not an immediate priority.
• The original HTML code is impossible to retrofit piecemeal, due to the proprietary code generated by exporting it from Excel.
• Since an accessible version is likely to be adopted by other universities—perhaps by the entire consortium—it could not be dependent on any specific server platform or development environment.
• The presentation of information should be consistent with that used by other members of the consortium, whether or not they decide to keep the original version.
• Fortunately, the document is strictly informational. There is no need for video, captioning, Flash, or other specialized development techniques.
• Second in importance only to accessibility compliance, rapid development was required by the contracting campus.

The simplest possible strategy turned out to be the most appropriate: hand-write completely new HTML and CSS code in a text editor. That is what you will see in the next section.

Remedies

Working now in your tab or browser instance with the revised version, repeat the sequence of tests described above. The differences here will be self-evident. The techniques used in this version are all well-known best practices for accessible design, but they are also specifically listed in the soon-to-be-finalized W3C Web Content Accessibility Guidelines (WCAG) 2.0. I have referenced that document in the following list:

• Text alternatives for graphic content are provided in a number of forms:
  • For statistical graphics (bar charts, pie charts, and so on), the actual numbers are added in the form of a data table immediately following the graphic. Alternate text can then simply read, for example, "Bar chart, details follow." Visible inclusion of the data table is not redundant; it benefits all readers, not just those with visual disabilities. [WCAG 2.0, 1.1.1 G95 and G73]
  • For most graphics containing only text, the text alternative is identical to its visual counterpart: for example, "President's welcome" in the Community section. [WCAG 2.0, 1.1.1, G94 and H37]
  • Some textual graphics suitable for sighted readers (for example, "Click here to get a cost estimate..." in the financial aid section) have been re-worded to better describe the link target to listeners (in this case, "Cost estimates are available on our financial aid page").
  • The useless image of text that described the College Portrait itself was simply replaced in its entirety with actual text. No alternative is necessary. For visual readers, the all-caps typography of the image is replaced by normal, easier-to-read, sentence case text.
• Visual-only ("fake") headings are replaced with semantic markup in the HTML code (<h1>, <h2>, and so on). These are styled to look as they did originally, but they are now also available for use by assistive technologies. [WCAG 2.0, 1.3.1, G115 and H42]
  • The entire document, rather than arbitrary original pages, is structured into a coherent whole.
  • Other added semantic markup includes lists (the table of contents and some demographic information) and tables (discussed below). [WCAG 2.0, 1.3.1, G115 and H48]
• With document structure now made explicit, a table of contents—which includes all level 2 headings—replaces the tab navigation. It remains always available in the left column of the page, while content is displayed on the right. (Frames, of course, are gone.) Navigation for sequential reading of the document has been added below the content. [WCAG 2.0, 2.4.1, H69]
  • This presentation follows a user's mental model of a document, not a page or a spreadsheet. It can be scanned visually or aurally, with direct access to any information of interest.
  • Links for each table of contents entry go directly to the selected section, not just to the page that contains that section. There is no need for "skip navigation" links.
  • Technical note: the columns could have been layed out on the page using CSS; I elected to use a single layout table (one row, two big data cells), due to the wide range of potential browsers that readers might be using. It linearizes correctly with layout tables removed.
  • Possible enhancement: the content area could be refreshed without reloading the whole page, using W3C WAI-ARIA techniques. This contemporary approach would simplify maintenance for the developer and make a more seamless experience for the reader. However, it would have to be done in such a way that no reader would be excluded, regardless of user agent support for the new standard.
• Data tables are used to supplement the graphics (as discussed above) and to mark up truly tabular information that had been styled only for visual readers. [WCAG 2.0, 1.3.1, G115, H51, H39, H43]
  • No table has more than a single row and column of headers, so simple markup (for example, <th scope="col">) was sufficient.
  • A caption is associated with each table. Where an immediately preceeding heading makes the table's purpose clear, the caption is kept short and the title attribute is omitted, to avoid needless repetition for visitors using a voice reader.
  • Data sets that would have contained only two columns in a table (for example, Degrees Awarded) were organized into lists instead.
• The code is valid XHTML 1.0 Strict; visual display is with W3C-compliant CSS. [WCAG 2.0, 4.1.1, G134]

Current status and remaining work

As soon as the revised document was delivered to the campus, it was posted on their web site ( http://daf.csulb.edu/offices/univ_svcs/institutionalresearch/college_portrait/). The campus home page has a link to it; for several weeks after posting, it was one of the featured news items on that page. Notice that they have integrated their existing visual styles—an easy job given standards-compliant code. The PDF version of the document is also available online, for readers who want to print a copy.

The present version of the College Portrait solves only an immediate problem for one campus. In reality, it would take just a few hours to manually update the statistics and graphics next year, but that is neither a good long-term approach nor generalizable to other campuses. At this writing, the underlying statistics are still under discussion among the test campuses, so further work on a web version would be premature. However, automatic production of accessible HTML is definitely under consideration, perhaps through an intermediate XML representation of the data. Progress will be reported on this page as it become available.