Re: Techniques revision - Meaningful link names

I am addressing two messages at once, here:

techniques - link text
  http://www.w3.org/mid/200308061758.h76Hwanj032692@mail1.magma.ca

proposed core checkpoint - page titles, section headings, and link text
  http://lists.w3.org/Archives/Public/w3c-wai-gl/2003JulSep/0244.html

The theme of my argument is that we will probably need to give the authors
some relief based on machine-recognizable-as-pertinent labeling in the
syntactically-defined context.

The markup structures are not there in HTML4 but they are there in some
formats like SVG.

At 01:58 PM 2003-08-06, David MacDonald wrote:

>Hi Mike & Ben
>
>One of our action items was to check with people who use screen reader and
>ask their reasons for using the dialogue box that lists links.  This was in
>view of possibly slackening the techniques about having "meaningful names
>for links."  One suggestion on the techniques phone call was that using a
>list box of Headings is a better way for Screen Reader users to understand
>the overall page and therefore we could slacken the need for meaningful
>links names (e.g., "details" after a paragraph)
>
>I just got off the phone with Harry Monk who is the Regional Director of the
>Canadian Human Rights Commission.  He is a blind Jaws user.  He said he uses
>the Headings lists frequently and finds them to be an excellent aid.
>However he also frequently pulls up the dialogue box that lists links that
>are on the page.  He says his reasons for using this "links" dialogue box
>are distinct from the reasons he uses a Headings dialogue box in Jaws.
>(i.e., he knows that there is a link on the page to a site that he wants to
>visit but doesn't know where it is.)  He says it would be a mistake to allow
>the justification of links with names such as "more details" into the
>techniques document.  He says that meaningful link names make the page more
>accessible regardless of whether there are properly laid out headings. His
>words were "I'm just delighted when a site makes maximum us of both Headings
>AND meaningful links names."
>
>He gave examples of poorly designed sites and it appears to me that these
>examples are precisely the kind brought forward as a circumstance where it
>might be appropriate to use the word "details".  Yet he had trouble
>navigating it.
>
>http://www.vancouverfoundation.bc.ca/
>
>Another similar example is the Canadian newspaper that has headlines with a
>short description of the article and then a link entitled "full story".  He
>said this was very difficult to navigate.
>http://www.globeandmail.com/
>
>So I recommend that we not justify any use ambiguous link names.

On the other hand, links with normally-displayed text content of
'more,' 'details,' 'continued,' are no more going to go away than
links with text content of "click here."

  http://lists.w3.org/Archives/Public/w3c-wai-ig/2002JulSep/0469.html

Fixing this problem is going to take new markup, not just campaigning
authors.

Or should I say that the problem with be abated better/quicker/easier using
some markup reform and not asking that one version of link text try to fit
all delivery contexts.

'More' links etc. are found in contexts where a logical unit is spread over
non-contiguous display regions in the layout and pagination of the content.

In HTML4 you can't reliably figure out "the details of what?" without
comprehending the natural language leading up to this link.  But if we get
people to mark the topical units of their content with enclosing
container-elements (like 'div'), and we define a 'more' element that is a
sub-species of link, then it will be clear that what is meant is "more of
the container element most closely containing this 'more' element.  The
closing 'more' link could be an optional closing element in a container as
much as the headingOrTitle is a required starting element.  Then the
assistive technology can label the link using both 'more' and the heading or
title attribute for the appropriate container.

Page titles, link texts, headings, etc. are always going to be some sort of
a compromise between conserving display consumables (screen space, time to
speak) and the error rates in understanding the message.

To actually work the problem we need to get reasonable guidance to authors
so that these identifying text fragments

- only rely on clearly traceable and duly labeled contexts
.. by this I mean that if we construct a breadcrumb trail through the
.. parse tree for the document by an algorithm[1] that has passed the laugh
.. text with the AT vendors, it is exorbitantly clear to a semantic-pragmatic
.. individual...

- are as context-independent as practical for their size

- relate the link destination to the current context
.. and distinguish it from peers (other links out of this context)
.. again as possible in the space taken and [as a fallback] as augmented by
.. the standard breadcrumb trail of contexts.

Al

[1]  The rough outline of the algorithm is that one retraces the containers
by means of the parse tree, including and excluding containing elements based
on some combination of

- prior knowledge of which element types are strong containers (form, table)
.. vs. weak containers (span, ruby)

- presence in the hypertext of author-provided labels (header subelement or
.. title attribute, whatever the format syntax provides for identifying text
.. fragments) for the containers

..and then composes the [text form of the] labels for the surviving contexts
into a abstracted breadcrumb trail of context-identifying text phrases.

>Cheers
>David MacDonald
>
>
>
>=========================
>
>Access Empowers People...
>        ...Barriers Disable Them
>
>         www.eramp.com

Received on Wednesday, 6 August 2003 16:36:22 UTC