W3C home > Mailing lists > Public > w3c-wai-gl@w3.org > January to March 1999

Re: Evaluation results: Navigation

From: Wendy A Chisholm <chisholm@trace.wisc.edu>
Date: Sun, 14 Mar 1999 11:17:30 -0600
Message-Id: <199903141721.LAA24240@trace.wisc.edu>
To: c.g.colwell@herts.ac.uk (Chetz Colwell), w3c-wai-gl@w3.org
Chetz and Helen,

a few comments and questions (chetz's original text marked with CC:: my
responses marked with WC::):

CC::
>Participants were observed to perform two types of 'finding' task while
>using the Guidelines: finding a topic initially; and re-finding a section
>after reading it or seeing a reference to it.  They had difficulties with
>both of these tasks, for several different reasons.
>
>Problem with initial finding:
>The Table of Contents does not currently support authors in finding
>guidelines for particular topics, such as images, frames, forms (although
>it is an improvement on previous versions).
>
>Potential solution:
>* Perhaps in addition to the existing list of guidelines in the Table of
>Contents, a list of HTML topics could also be provided.
>
WC::
Did participants not make use of the Checklist of Checkpoints?  The
checklist is organized by topic and points back to the Guidelines document.


CC::
>Problem with re-finding:
>Several factors seemed to contribute to the difficulties with re-finding
>sections or references to sections, including the ability to keep track of
>which document was being viewed.
>When Participants followed a link from the Guidelines to the Techniques
>they did not seem to be aware that they had moved into a different
>document; the transition was almost too seamless.  Participants were
>observed to follow a link to the Techniques and then scroll up to try to
>return to the link they had followed, as if they were still viewing the
>same document.
>
>Potential solutions:
>* Link text could be modified to include information about which document
>the destination of a link is in. (See below for more on link text.)
>
WC::
yes, others have made this comment as well.  We are addressing this problem.

CC::
>* Could the final URL be made shorter and less complex?  A participant
>pointed out that the URL was interfering with their usual strategy for
>keeping track of where they were: it was too long to fit in the status bar
>of their browser which meant they could not check the destinations of
>links.  They also said that it was too complex to easily spot when it
>changed when they moved between documents.
>
WC::
All of the URLs between the Guidelines doc, the Techniques doc and the
checklist of checkpoints are relative, thus they should be no longer than a
few words (this was a change that may not have been in effect in the
version that participants used).

CC::
>* Could the section numbers indicate the current document, such as G1.1 or
>T2.2?  Is there a way in which the numbering could match across the
>documents, for example, could G1.1 relate to T1.1?
>
WC::
hmmm.  New section numbering is an interesting idea.  Unfortunately, since
the Techniques document and the Guidelines document are organized
differently (Guidelines by issue, Techniques by issues then HTML topics) i
don't think we will be able to synch them up as suggested.

other thoughts?

CC::
>There may be other solutions to this which are visual in nature, such as
>colour-coding, but non-visual solutions are more difficult to identify.
>
>Related problem: Link text.
>Participants often found that links did not take them where they expected,
>for example:
>- In Guideline 2 it is not clear where the link "important" goes to.
>- In Guideline 2 the link "long description" goes to information on long
>descriptions, whereas the link "a long description" in Checkpoint 2.1 goes
>to examples.
>- In Checkpoint 1.3 the link "provide a text equivalent" goes to examples
>for imagemaps, whereas the link "provide a text equivalent" in Checkpoint
>2.2 goes to examples for images.
>
>Don't the Guidelines (or the Techniques) state somewhere that links with
>the same text should go to the same destination?
>
WC::
yes, we have violated our own guidelines.  thanks for pointing this out.
We will remedy this.

CC::
>Potential solution:
>* If a link is to a definition, or examples, or further description this
>could be indicated, for example, <link> definition of important, <link>
>examples of long descriptions for imagemaps, <link> further information on
>long descriptions, etc.

>
>* It may also help if the document is indicated as well as the content at
>the destination, such as <link> Techniques for providing text alternatives
>for images.  This link text is rather long, but it clearly indicates the
>destination of the link.
>
WC::
these are interesting proposals.  we will try them out.

CC::
>Related problem: position of links.
>In Checkpoint 1.1 the link "Provide text equivalents for all images" goes
>to Techniques Checkpoint 1.1 (examples) where the first few words are a
>link with same text, "Provide text equivalents for all images", back to
>Checkpoint 1.1 in the Guidelines.  In both locations the first words an
>author would read are a link to somewhere else.  This is the case for many
>Checkpoints.
>
>Potential solution:
>* The link text could indicate that it links to some examples, and could
>also be moved from the beginning of the Checkpoint to the end, for example:
>
>1.1 <no link> Provide text equivalents for all images [Priority 1]
>For example, in HTML, use the "alt" attribute of the IMG and INPUT
>elements, or for OBJECT, use "title" or the element's content. <link>
>Examples of providing text equivalents.
>
>This could be applied to many of the Checkpoints.
>
WC::
i believe this is what the other WAI guidelines have done.  This is a good
solution.

CC::
>Finally, Checkpoint 15.5 recommends the use of a site map. A participant
>suggested that the Guidelines could use one because it can be difficult to
>navigate between the documents.
>
WC::
<grin>  hopefully we can find a solution that makes it less confusing.  if
not, maybe we'll have to create an example of an accessible site map.

thanks again chetz and helen!!
*great* comments,
--wendy
Received on Sunday, 14 March 1999 12:21:59 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:46:59 GMT