PICK A DAY PAGE RATIONALE

After a user has selected the month that their Change of Address takes effect, a calendar is generated for the chosen month of the current year. The user is then asked to select the day that the Change of Address is to take effect.

What follows is a description of the original page, the strategies we tried, and finally a solution that we recommend be used. We have also included links to the original page and our current solution. Please look through these and send us your comment s and suggestions to web-team@trace.wisc.edu

PROBLEM WITH THE ORIGINAL PAGE

With images not loaded, the original page consists of a commonly used format for presenting calendar information (seven columns by six rows). Three letter abbreviations of the names of the days of the week are listed in the first row of the calendar and the image icon fills the spaces for the numeric days of the month. After images are loaded, the image icon is replaced by square buttons labeled with numbers.

When viewed with a screen reader, the user is able to read the day name abbreviations yet nothing happens if they try to click on any of these names. The user sees that there is a line of image icons on the next five lines but if one of these is selected , the image is loaded and now nothing is read when the screen reader passes over the image. Most users have no way of knowing what each image represents since most screen readers can not yet read by columns.

To a screen reader that verbalizes images this page would look like:
image image image
Please pick the day that this change takes effect
January 1996
Sun Mon Tue Wed Thu Fri Sat
image image image image image image
image image image image image image image
image image image image image image image
image image image image image image image
image image image image
image image

Turn autoload images off and view the original pick a day page


STRATEGIES INVESTIGATED

Investigation 1. Simply adding alt-text to images.
The first step was to simply add alt-text for each of the buttons. Our concern was that if viewed with a screen reader it would be hard to connect the day of the week with the particular day of the month on which it fell. Many screen readers can not read individual columns. Because the user is forced to read this page one row at a time, there is no easy way to tell, for example whether the 3rd is a Sunday, Monday, Tuesday etc.

Investigation 2. Include column information in alt-text
Our way around this problem was to have each cell of the table present both the day of the month, for example 3, and the name of the day itself, for example Sunday. We wanted to front-load each entry with the information the user might need first. In this way, if a person were using a screen reader to find the 3rd day of the month, he or she could rapidly skim over the unwanted dates by pressing the right arrow after the number was read and before the day name had been spoken. In this way, the user would not have to listen to each entire entry preceding the 3rd. However, we found that we couldn't fit the date and the complete day names on the line without the right-most columns scrolling off of the screen. We couldn't even fit the date and a 3 letter abbreviation of the day names on the line without having the same problem occur. (This happened using 12-point Times as the font on a 13" monitor).

Another concern was how to make a table easily readable with a text-based browser. When the original page is viewed with LYNX, the table is joined into one long line of text. Using line breaks between rows of the table put rows on sep arate lines when viewed with LYNX, but pushed the beginning of the table down the page a few lines when viewed with Netscape.
Second investigation as viewed with Lynx.


CURRENT SOLUTION

Except for Sunday, which appears as 'SUN' and Thursday which appears as 'R', we used the first character in the day name. even if the first two letters of the day name fit on a line without scrolling off of the screen, a synthesizer would read some very strange sounds. The almost silent TH sound in Thursday would not be audible, Wednesday would become WE, and Tuesday would be pronounced as 2. We might want to put another reference point in the middle of the week WED for example, but that increases the possibility that the calendar will scroll to the right of the screen where it is not read by a screen reader.

The same problems occur with three letter abbreviations. For example 2 Tues is read as 2 2's and the possibility of scrolling is increased.

Including line breaks within the last column element of a row (before the closing "TD"), will appear on separate lines in LYNX and the appearance when viewed with Netscape will not be affected. For example

<TR> <TD></TD> <TD><A HREF="http://trace.wisc.edu/text/ext_docs/wings/moving/day1.html"><IMG SRC=http://trace.wisc.edu/text/ext_docs/wings/moving/day_1.gif alt=" 1 M "></A></TD> <TD><A HREF="http://trace.wisc.edu/text/ext_docs/wings/moving/day2.html"><IMG SRC=http://trace.wisc.edu/text/ext_docs/wings/moving/day_2.gif alt=" 2 T "></A></TD> <TD><A HREF="http://trace.wisc.edu/text/ext_docs/wings/moving/day3.html"><IMG SRC=http://trace.wisc.edu/text/ext_docs/wings/moving/day_3.gif alt=" 3 W "></A></TD> <TD><A HREF="http://trace.wisc.edu/text/ext_docs/wings/moving/day4.html"><IMG SRC=http://trace.wisc.edu/text/ext_docs/wings/moving/day_4.gif alt=" 4 R "></A></TD> <TD><A HREF="http://trace.wisc.edu/text/ext_docs/wings/moving/day5.html"><IMG SRC=http://trace.wisc.edu/text/ext_docs/wings/moving/day_5.gif alt=" 5 F "></A></TD> <TD><A HREF="http://trace.wisc.edu/text/ext_docs/wings/moving/day6.html"><IMG SRC=http://trace.wisc.edu/text/ext_docs/wings/moving/day_6.gif alt=" 6 S "></A><BR></TD> </TR>

With autoload images off view our current solution

Return to the WINGS Access Project