RE: Twisties re notes/domino

For those of us who do not happen to have Notes available to them, can
someone post a URL or provide sample files that demonstrate the twistie?  I
have a feeling I have seen this in a variety of pages using straight HTML
links, DHTML, and ActiveX, resulting in a situation where we have the same
UI implemented via different techniques.

Mark

> -----Original Message-----
> From: w3c-wai-ig-request@w3.org [mailto:w3c-wai-ig-request@w3.org]On
> Behalf Of Leonard R. Kasday
> Sent: Monday, August 10, 1998 7:53 PM
> To: Al Gilman; w3c-wai-ig@w3.org
> Cc: w3c-wai-cg@w3.org
> Subject: Re: Twisties re notes/domino
>
>
> One possibility is to simply give users direct access to the
> hierarchy, via
> the following functions
>
> parent
> child
> next/prevous sibling(s).
>
> This does functionally some of what the accordion list does for sighted
> users, viz ability to quickly get items for above relationships.
>
> There is problem of getting lost as to which level you're in.
> Perhaps some
> explicit audio label (e.g. "level 1" preceding output) would do the trick.
> Or Raman's audio techniques.
>
> Len
>
> At 10:02 AM 8/10/98 -0400, Al Gilman wrote:
> >[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.
> >
> >
> >
> -------
> Leonard R. Kasday
> Institute on Disabilities at Temple University
> kasday@acm.org
> telephone (215} 204 2247
> Chair, Web Accessibility Inititative Evaluation and Repair Interest Group
> http://www.w3.org/WAI/ER/
>
>

Received on Monday, 10 August 1998 23:42:17 UTC