Twisties re Notes/Domino

 
Al:

Your "accordion file" analogy is a good one for describing the functionality of
Notes "twisties".  The "-" denotes that the section is collapsed, so the
available actions are either to review the information as provided or to choose
Enter to expand the section.  The HTML source code for these collapsed sections
is:  <IMG SRC="/icons/collapse.gif" BORDER=0 ALT="- ">

Conversely, the "+" denotes that the section is expanded, and the action to be
taken would be to collapse the section.

Therefore, to address this issue, I believe that the appropriate solution would
be to have the Notes-to-HTML translation generate an ALT="Expand Section"
instead of the "-" and an ALT="Collapse Section" instead of the "+"
This would address the "meaningful link text" rule to which you referred below.

However, the much more serious issue is that performing an action (collapsing an
expanded section or expanding a collapsed section) results in the page being
refreshed, and screen readers do not presently keep track of the current (at the
time the action was taken) location within the page.  This is extemely
frustrating for blind users, particularly if the page contains many twisties and
they were selecting one near the bottom of the page.  This also greatly reduces
efficiency of working with the information provided.

The best short-term solution is to use the search capability to find the
requested information (the Notes application will need to have the full-text
index created so that the search feature is enabled for browsers).

As you indicate below, this would be more generally applicable to accordion
lists, regardless of the technology used to develop them.

Karl Hebenstreit, Jr.
US General Services Administration
Center for IT Accommodation

____________________Forward Header_____________________
Subject:    Re: Twisties re notes/domino
Author: "al gilman" <asgilman@access.digex.net>
Date:       8/10/98 10:02 AM

[follow-up to discussion of the Lotus Notes/Domino implementation
of expanding lists with inscrutable "+/-" link text on twisties.]

The existing rule about "use meaningful link text" explains why
using plus and minus as the link text for twisties does not work
for screen reader users.  But it does not really tell you what to
do about it because a long substitution would get tedious even in
speech.  We probably need to step back and see what the twisties
are doing for us to understand the problem.

Twisties are used as controls inside what we might call
"accordion lists" by analogy to "accordion file" containers for
information on paper.  These are list structures similar to a
table of contents that the user interface lets you fold and
expand on a section by section basis.  Users of MacOS since
version 7 and Microsoft Windows since Windows 95 will be familiar
with this in the file system interface.

The problem is that the visual user can see where the un-changed
parts of the list come back in the adjusted list presentation.
It is not similarly easy to perceive the structure in terms of
changed and unchanged segments in audio, so far as I know.

Accordion lists are visual context-savers for exploring
hierarchical information structures.  I might even say that
accordion lists are a best current practice for this function.
If there is a comparable best current practice for saving context
inside a hierarchical domain, in the context of an audio user
interface, I don't know what it is.

What to do about it?  This could easily get technical enough and
voluble enough to be worth moving off the general interest list.

There are several groups that are potentially affected: User
Agent, Page Author, Authoring Tools, Protocols and Formats.
Maybe we should try an ad-hoc action team.

If people will volunteer to work on how to make accordion lists
accessible, then we can move the discussion off the Interest
Group list.  The WAI Coordination Group <w3c-wai-cg@w3.org> can
worry about what sort of a coordination process will keep the
interested groups tuned in.

Al Gilman

PS:

HTML 4 already has the functionality suggested as LABELFOR for
form controls, but not for general links.

The usability concerns are the same whether the interface
behavior is done with Javascript or CGI.