Time: 2:00 PM EST; 1:00 PM CST; 12:00 PM MST; 11:00 AM PST
- Discussion of D2L drop-down widget (continued).
- Overview of results of usability tests (Joe, Janna).
- Authoring a white paper on our collaboration efforts
- New time in the new year? We have some people in the UK that are interested in joining us. 4PM GMT/ 11 AM EST/ 9AM MST may work.
Meeting Time Changes
Judging from responses to the Doodle query Janna sent out soliciting possible regular meeting times, it looks like meeting the favored time for a meeting is Tuesday's at 4 PM GMT, 11AM EST, 9AM MST. OSU and Illinois have a conflict with the Friday time, since it overlaps with a Committee on Institutional Cooperation (CIC) meeting. Moving it an hour earlier would work for Illinois and OSU, but that puts Mark and Dawn (Arizona) in a meeting at 8 AM (ouch!). So:
Date and Time (tentative): 8 January 2008, 4 PM GMT, 11 AM EST, 9 AM MST.
Call in information: 614-247-6424, id number: 0490#.
- Janna Cameron
- Don Amos
- Joe Wheaton
- Vinnie Young
- Ken Petri (scribe)
- Alan Foley
- Nolan Crabb
Regrets: Hadi Rangin. (Hadi's wife, Mahnaz, became a U.S. citizen Friday and Hadi attended the ceremony. Congratulations to Mahnaz and Hadi.)
Summary of Teleconference
Discussed progress of the usability tests. OSU has tested seven users, three with cognitive and four with visual disabilities. A wide spectrum of users with visual disabilities was tested, from power users to daily users only recently becoming fully reliant on JAWS. At least one user still frequently uses screen magnification. Given the wide range of skill levels, we saw varying strategies for approaching pages in D2L using a screen reader. Most users read lists of links as an early strategy. The more advanced users used heading navigation and moved between frames or form controls. Most scanned the page using the down arrow or the "N" key to move between blocks of text. If specific content was known to be available on the page, users frequently used JAWS's search facility.
Overall, it seems pretty clear that the changes in markup since version 7 and 8.1 have made significant improvements in usability--that is, good semantic use of HTML elements is key for screen reader users.
Users with cognitive disabilities liked the more intuitive and larger icons used on interfaces. Improved use of whitespace and cleaner layout in design also was a factor in improved appeal. These users also appreciated the use of TITLE in images for tooltips.
Tooltip and alternative text for images has improved on many interfaces. It is noteworthy how much more "contextual" it is. For example, the same icon may get different alternative values depending on what information it is supposed to convey. Screen reader users also benefited from this greatly. This was obvious in the ability for screen reader users to very easily read data in graphical charts.
Some users with cognitive disabilities found that icons that were not clickable were somewhat confusing. Some of this was mitigated by consistent use of tooltips.
In review of the final test session, that had happened early in the day of the teleconference, we discussed the order of elements on the discussion interface. The final user test we conducted showed that the order of elements in a single discussion posting--subject line of post, author, reply-to options, place in thread, followed by the posting itself--was confusing. Our tester had difficulty finding the post itself. This tester and others also clicked the name of the poster, thinking that this would take her to the post by this person, when instead it opened an email. The problem here is that, normally when using a screen reader, the screen reader will identify a link as a mail to hyperlink. Since the email functionality in D2L is built in, not reliant on the user's email agent, the link appears as a regular hyperlink. So the assumption of it not taking one to an email makes sense.
We kicked around a bunch of possible solutions, including making the name link say "send email to user's name," and flipping the order of the post, so that the content of the post came immediately after the topic. The topic, also, might be implemented as a heading, allowing easier navigation through the list of topics in the discussion list.
On the Table of Contents page, the issue of how topics are listed came up again in our last test. The user had difficulty locating the topics because they were preceded by a search box. So, in arrowing down through the Table of Contents, the user stopped at the search box and tried to perform a search, not realizing that the topics were listed below. After we prompted the her that the topics were listed below, she had difficulty discerning their structure. The listing of topics appears to be a heading with a bullet list of related topics, implemented at links to content, below each heading. In fact, however, the list and topics are simply items arranged visually in a table and don't have the necessary semantics to make them easily navigable. The roman numeralled list gets read as "e," "ee", "eee", "iv", etc. Again this is caused by not using an ordered list.
The general principle is that designers should strive to use the most appropriate HTML elements to contain content.
- Janna will take a first pass at our joint authored white paper on our collaboration efforts. She will try to get that to the group by December 21. Ken and Joe will take it through a next draft and then pass it on for further addition and revision.
- Joe is submitting a panel proposal on our efforts to the 24th Annual Conference on Distance Teaching and Learning.
D2L has a prototype of their drop down menu, the one we critiqued at the teleconference before this one. D2L will make the prototype open for our testing soon. They have reimplemented so that one moves through the options using arrow keys and the control is activated via a space-bar or enter keystroke. The control itself is a tab stop. A screen reader user at Guelph has tested the new implementation, with positive results.
Ken noted a couple of articles that might help with the problem of screen updates for JAWS users. The two articles by Gez Lemon, with Steve Faulkner, on Gez's Juicy Studio site are:
- Making Ajax Work with Screen Readers, which has a thorough explanation of how popular screen readers work: http://juicystudio.com/article/making-ajax-work-with-screen-readers.php
A follow up article by article by Bob Easton includes a couple of test implementations: http://www.access-matters.com/2007/01/22/improving-accessibility-for-todays-ajax-to-hack-or-not/
It seems like the method in number 2, above, might work for updating the buffer for any dynamically added content, not just something returned from an Ajax call.