- From: Wendy A Chisholm <chisholm@trace.wisc.edu>
- Date: Sun, 14 Mar 1999 11:17:30 -0600
- 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 UTC