Accessible DHTML: A Case Study

The original version of this document was last updated 26 April 1999 [ADHTML]. This version supercedes that version with several corrections and further discussion.

To better understand the issues that are addressed, interact with all of the pages refered to in this document

Goals of this exercise


Table of Contents

  1. Issues discovered during evaluation of the HTML Guru site
    1. Images without alt-text
    2. Images used for stylized text
    3. Use of absolute positioning and pixels
    4. Javascript for URLs
    5. Content generated on the fly
    6. Shadow text created with scripts.
    7. Menus and Submenus
    8. Summary
  2. Intermediate investigations
    1. Creating shadow text with style sheets
  3. Solutions produced with Madison Women Climbers page
    1. Layout adjusts to font increase (use of em)
    2. Content hidden/displayed dynamically
    3. Shadow text created without scripts
    4. Menus and submenus that are navigable.
    5. Site is usable without javascript
  4. Open issues
    1. Bookmarking text of submenu
    2. Using back button between submenus
    3. Menu mechanism is not obvious to a screen reader user
    4. Using the page with style sheets but no script
    5. Why does the "link-to-top" class display in Netscape 4.5"
    6. Using images and alt-text, including animation.
    7. Transfer knowledge back to the Guru site
  5. Applicable Web Content Accessibility Guidelines
  6. References

Issues discovered during evaluation of the HTML guru site

In early 1999, we reviewed The HTML Guru site designed by Jeff Rouyer [GURU]. A snapshot of what we evaluated at that time is available from the Trace Center's site. Thank you Jeff for lending this to us.

Images without alt-text

Several images on the guru site do not contain alt-text. Providing text equivalents for images is a Priority 1 checkpoint in WCAG 1.0.

Images used for stylized text

Images of cursive text are used instead of "actual" text. This is understandable since techniques for modifying text appearance (other than font-size, font-color, and basic font-family) are not widely supported. However, these images do not have text equivalents. Many of these images are used as links and therefore users who are unable to access the images are also unable to select the graphical links. Providing text equivalents for images is a Priority 1 checkpoint in WCAG 1.0.

Use of absolute positioning and pixels

The guru site creates several interesting effects by creating "layers" of information then positioning them on the Web page. Image clipping is another technique commonly used. Combining these techniques, Jeff was able to create an animation of a futuristic person raising their hands as part of a mouseover effect. Each of the images used to create the animation and the buttons of the main menu that causes the mouseover events, are positioned relative to each other. However, there are at least three layers on the page and they are positioned at pixels.. Thus, if the window is resized, the 3 layers begin to overlap and the page becomes unreadable. Also, if the text size is increased or decreased, the text begins to overlap. Using relative units for positioning and specifying font size is a Priority X checkpoint in WCAG 1.0.

Content generated on the fly

When the user selects a link to display new content, the request is not sent to the server to retreive a new page. The text is embedded in the script and drawn to the screen on request. When a person accesses the page without JavaScript, they receive the contents of the NOSCRIPT element for this page which says, "get a JavaScript enabled browser." Ensuring that a page is usable when JavaScript is not supported in a browser or is not enabled is a Priority 1 checkpoint in WCAG 1.0. Also, providing a usable alternative, for example in the NOSCRIPT element, is a Priority @@ checkpoint in WCAG 1.0.

Javascript for URLs

Most of the links on the page reference "javascript" rather than an actual resource. This activates a client-side action (javascript) rather than a request to the server. As discussed earlier, many of the links on the page are created with images and these images do not have alt-text. Therefore, when a person uses a screen reader to read the links all that is read is, "javascript, javascript, javascript." Making it this far into the Guru site means that scripts are enabled and working, however other sites use this technique in such a way that if a user does not have script support or scripts enabled they are not able to activate links on that site. Making sure that sites are usable when scripts are not supported or not enabled is a Priority 1 checkpoint in WCAG 1.0. Others that apply??

Shadow text created with scripts

If a text phrase is drawn to the screen twice, in two colors, at slightly different positions on the page, a "shadow" effect is created. It was anticipated that this would cause a screen reader to read the text twice, but in our tests, it did not. Once again, if a browser does not support scripts or scripts are not enabled and this technique is used, the user will not have access to the text.

Menus and Submenus

The main menu appears in the lower right corner by the animated person. In the upper right corner is a submenu. It was not immediately obvious when using the page in a visual manner that the choices in the submenu changed as main menu items were activated. We were not able to test this example with a screen reader because the link text was not provided. However, the submenu items are the last links a user tabs to. Therefore the screen reader user is unlikely to make the connection between the submenu and menu items. This is true for the visual experience as well, since the menu and submenu are in such different places in the visual display.

Summary

The primary issue is that the site is completely unusable without images or scripts. If images are not loaded there is no alt-text. Also, the JavaScript loops until all of the images are loaded. If the user has turned image loading off, the opening page will loop infinitely. If scripts are not loaded, the user is told to get a browser that supports scripts. If scripts and images are loaded, since there is no alt-text, none of the links are accessible to a person unable to see the page.


Intermediate investigations

We wanted to tackle each of the above issues. Our first step was to investigate some new technologies.

Creating shadow text with style sheets

It is possible to use Microsoft filters, supported in MSIE4 and 5 to create the same shadow effects as the guru site. However, this is not a cross-platform solution. As style sheets become more robust, this technique should become platform independent. Example of glowing and shadowed text produced with MS filters.


Solutions produced with Madison Women Climbers page

After a brief look at new technologies we decided to create a site that uses all of the same features as the Guru site but that was accessible. Thus, instead of redesigning an existing site, we decided to create a site from scratch. We have made several attempts at the site. We will discuss each of the improvements made with each attempt as well as the issues created or not solved by each of our existing solutions.

Layout adjusts to font increase (use of em)

Absolute positioning is used on the MWC pages, but by using the "em" unit (the width of the letter "M" for the current base font size), if the font is increased or decreased, the layout of the page is maintained.

Content hidden/displayed dynamically

The content is not generated on the fly. All of the content is available in the page, but it is displayed or hidden using style sheets. This means that if style sheets and javascript are not loaded, the page is usable as a text-only page. Part of the reason this is possible is that proper HTML markup was used throughout the page. The "table of contents" when displayed with style sheets and javascript appears as users interact with it. When a user first views the page, only the top three levels of information are displayed. If the user selects one, a "submenu" of more choices is made visible. Thus, it is a dynamic, horizontal table of contents. When scripts and style sheets are not loaded, the table of contents appears as a hierarchical, vertical list - an outline view of a table of contents.

URIs are not javascript but actual resources

Unlike the Guru site, when a link is selected, the user is taken to an actual resource. Thus, when viewed without style sheets or scripts, if a user selects a link from the table of contents, they are taken to the content that appears later in the page. With scripts and style sheets loaded, the information is displayed dynamically in the blue "content box."

Menus and submenus that are navigable

Since the submenus appear directly below the main menu item, if a user is tabbing between links, once displayed, they will tabbed directly from the main menu item to the submenu items before tabbing to the next main menu item.

Site is usable without javascript

Because the content is not generated on the fly, the links go to actual resources, and the content is structured so that when scripts and style sheets are not loaded it is a properly marked up HTML document, the page is usable without scripts and style sheets.


Open issues

Bookmarking text of submenu

Since the content is hidden and displayed using scripts and style sheets, the main URI of the page does not change. Thus a user is unable to create a bookmark to a particular "page" within the "site."

Using back button between submenus

Related to the issue of bookmarking, the "back" button does not work either. The URI does not change, thus pressing the "back" button will take the user to the page that they visited prior to visiting the MWC pages.

Menu mechanism is not obvious to a screen reader user

A user of a screen reader is used to hearing an indication when they open a menu, and it if has a submenu. Since we are emulating a menuing mechanism, no such indication is given. Thus, a user may think that each time they select a link they are going to a new page and it can be confusing why the same choices ("menu options") are available in different orders on each page. Thus, we need to find a way to make this more obvious.

Using the page with style sheets but no script

It has been discovered that the pages are usable in the two extreme cases, but not in the grey area in between. In other words, the pages are usable when scripts and style sheets are turned off, or when scripts and style sheets are turned on, but not usable when only style sheets are loaded and scripts are not.

Why does the "link-to-top" class display in Netscape 4.5"

There are some funky bugs with our implementation in Netscape 4.5. Some of the layers that should be hidden, are visible.

Using images and alt-text, including animation.

We need to include graphics and animations on the page to discover access issues.


Applicable Web Content Accessibility Guidelines

  1. Guideline 1. Provide equivalent alternatives to auditory and visual content.
  2. Guideline 3. Use markup and style sheets and do so properly.
  3. Guideline 6. Ensure that pages featuring new technologies transform gracefully.
  4. Guideline 7. Ensure user control of time-sensitive content changes.
  5. Guideline 9. Design for device-independence.

References

  1. [WCAG] Web Content Accessibility Guidelines 1.0. Published as a W3C Recommendation on 5 May 1999.
  2. [GURU] The HTML Guru site by Jeff Rouyer.
  3. [ADHTML] Accessible DHTML Web pages

Valid HTML 4.0! $Date: 2000/08/17 14:57:27 $ Wendy Chisholm