RE: SC 2.4.5, meaningful link text

A question and answer:
 
<blockquote>
>>> If you have a list of links- can't you jump to the location of a
link in the text?
 
This is not possible in Jaws, WindowEyes, or HPR. The list of links does
not take the user to the link text, but rather it takes the user to the
destination
of the link.
 
 
</blockquote>
 
Actually, JAWS *does* allow users to jump directly to the *location* of
a link in the links list. (Pressing Ins+F7 brings up the links list;
once inside the links list, pressing alt+m jumps the user to the link
that was highlighted in the links list. This does not activate the link.
Screen readers aren't the only type of user agent that builds a links
list. Opera does it. So does Firefox (Tools>>Page Info>>Links tab),
though the links in the list don't seem to be operational (so what's the
point?).
 
John
 
 

"Good design is accessible design."

Dr. John M. Slatin, Director 
Accessibility Institute
University of Texas at Austin 
FAC 248C 
1 University Station G9600 
Austin, TX 78712 
ph 512-495-4288, fax 512-495-4524 
email jslatin@mail.utexas.edu 
Web  <http://www.ital.utexas.edu/>
http://www.utexas.edu/research/accessibility 

-----Original Message-----
From: w3c-wai-gl-request@w3.org [mailto:w3c-wai-gl-request@w3.org] On
Behalf Of David MacDonald
Sent: Thursday, January 05, 2006 9:13 AM
To: w3c-wai-gl@w3.org
Subject: RE: SC 2.4.5, meaningful link text



 

>>>And is there a way to get to links without having to tab all the way
down?

 

Yes, it is the links list view. Every major screen reader has that
function. The reason for that is that it is useful and it compensates
for what seeing people do effortlessly. The links list view works
because of our 1.0 Guideline 13.1 Priority 2. Although I don't think of
it as pulling information

 

>>> If you have a list of links- can't you jump to the location of a
link in the text?  

 

This is not possible in Jaws, WindowEyes, or HPR. The list of links does
not take the user to the link text, but rather it takes the user to the
destination of the link.

 

>>If not, couldn't you?

 

Besides the programming difficulties involved in creating a function in
AT that would do this (which are not trivial), the concept does not make
sense to me. If there is a list of "Click here" links, how would someone
know which one they wanted to select in order to jump to it and find out
more information about its destination? Once at the link text they would
need to press keys combinations several times in succession to find the
words surrounding the text, and then cursor back to the link and then
select it to be taken to its destination.

 

>> I would like to see easy access to links at a high level, but if we
make link access require verbose links then I think it will have to be
at level 3.  

 

I don't think meaningful link text necessarily means verbose text. I
don't know why we would have to move it to level 3. Unlike many other
issues that we have had to revisit in the 2.0 Guidelines, I would say
the conditions that were present that prompted the 1.0 Guidelines
committee to include that guideline 13.1 (requiring meaningful link
text) at Priority 2 have not significantly changed. Links are still the
major way to surf the net, and the difficulties around "click here"
links have not changed either I would say.

 

 

 

 

 

 

 

 

 

 

 

...Access empowers people
            ...barriers disable them...

www.eramp.com


  _____  


From: w3c-wai-gl-request@w3.org [mailto:w3c-wai-gl-request@w3.org] On
Behalf Of Gregg Vanderheiden
Sent: Wednesday, January 04, 2006 10:40 PM
To: 'David MacDonald'; 'Ben Caldwell'; 'Jason White'
Cc: w3c-wai-gl@w3.org
Subject: RE: SC 2.4.5, meaningful link text

 

Hi David,

 

  I like adding the exception - but i think it should be broader than
this one example.   This is exception by item and is not good.  There
are others I'm sure. You identified one yourself.    We need to find out
what it is about these that makes them viable exceptions and capture the
concept.

 

Also, can those who use screen readers regularly comment on a couple
things.   One - use of key combinations is made out to be very
difficult.  I presume key combinations are used regularly in screen
readers.  Also, control shift arrowkey doesn't sound like a twist of
wrist to me.  I use it all the time.    And is there a way to get to
links without having to tab all the way down?   If you have a list of
links- can't you jump to the location of a link in the text?  If not,
couldn't you?   

 

I would like to see easy access to links at a high level, but if we make
link access require verbose links then I think it will have to be at
level 3.  

 

Thoughts? 

 

 

Thanks 

 


Gregg

 -- ------------------------------ 
Gregg C Vanderheiden Ph.D. 
Professor - Ind. Engr. & BioMed Engr.
Director - Trace R & D Center 
University of Wisconsin-Madison 

 

 


  _____  


From: w3c-wai-gl-request@w3.org [mailto:w3c-wai-gl-request@w3.org] On
Behalf Of David MacDonald
Sent: Wednesday, January 04, 2006 6:28 PM
To: 'Ben Caldwell'; 'Jason White'
Cc: w3c-wai-gl@w3.org
Subject: RE: SC 2.4.5, meaningful link text

The editor's note on 2.4.5 asks us to comment about how closely link
text should be associated with text describing the destination. Below I
will provide the requested comments and then a recommendation:

 

In order for a person using JAWS to access the words around a link they
need to TAB to the link and press INSERT + LEFT ARROW or INSERT + RIGHT
ARROW. In Home Page Reader (HPR) it requires SHIFT+CONTROL+LEFT (or
RIGHT) ARROW. In WindowEyes it requires the same SHIFT+CONTROL+LEFT (or
RIGHT) ARROW.

 

My experience as someone who works in the field of ergonomics, as well
as providing Assistive Devices accommodation, is that the incidence of
repetitive strain injury (RSI) is higher among screen reader users than
in the general population of computer users. Forcing blind users to make
unnecessary extra combinations of keystrokes, is not fair I would say.
This may not be as big an issue for our young blind users. But over the
years the extra wear and tear on their elbows, wrists and hands will
often take their toll. I have seen this. Assistive Technology is
supposed to overcome disability, not cause it.

 

It also takes extra time to TAB and twist the hands to hit INSERT + LEFT
(RIGHT) ARROW or CTL +SHIFT +ARROW.

 

There is nothing more important on the internet than links, it is what
makes it the internet. Sighted users effortlessly visually skim the page
for the links they want. (often with no key strokes)Why would we want to
force blind users to risk cumulative Repetitive Strain Injury over the
years (hundreds of thousands of extra keystokes) when it is such a
fundamental part of what the web is all about? I don't think this is
about taking the links out of context, anymore than zooming into a small
part of a page with a screen magnifier is taking information out of
context. I don't know why we would want to make it harder for AT users
to compensate for what sighted people do effortlessly.

 

It is not hard to create meaningful text links, as long as we allow
exceptions for arrays of links. Explicit meaningful text is priority 2
in the 1.0 Guidelines. I think there will be quite a big price if we let
this slide off the table in the 2.0 Guidelines.

 

Therefore, for these reasons and others, I think we should be fostering
a culture of meaningful link text. 

 

*Recommendation* 

 

SC 2.4.5

 

<current>

Each programmatic reference to another delivery unit or to another
location in the same delivery unit, is associated with text describing
the destination. 

</current>

 

<proposed>

Each programmatic reference to another delivery unit or to another
location in the same delivery unit, is programmatically associated with
text describing the destination, unless it is part of an array of
programmatic references to different versions (or views) of the same
information. 

</proposed>

 

Regards

David MacDonald

 

 

...Access empowers people

            ...barriers disable them...

 

 www.eramp.com

 

 

-----Original Message-----
From: w3c-wai-gl-request@w3.org [mailto:w3c-wai-gl-request@w3.org] On
Behalf Of Ben Caldwell
Sent: Wednesday, January 04, 2006 5:39 PM
To: Jason White
Cc: w3c-wai-gl@w3.org
Subject: Re: SC 2.4.5, meaningful link text

 

 

Jason White wrote:

> On Mon, Jan 02, 2006 at 12:45:41PM -0600, Gregg Vanderheiden wrote:

>>Also - the question is how helpful.  And why couldn't AT be programmed
to

>>allow users to get information around a link with a simple keystroke
for

>>those cases where the link all by itself did not give them enough

>>information.

> 

> Do GUI screen readers make this hard? Under all of the Unix text
browsers I

> use, and with both braille and speech assistive technologies it's
trivial to

> read the line containing the link, the lines before and after, etc. As
a

> result, this has never struck me as a concern. At most it's a couple
of

> seconds of extra work to read the context. I tend to read the text of

> unfamiliar pages anyway, rather than just reading links, so for my
usage

> pattern the problem rarely arises. With familiar pages I use the "text
search"

> function of whichever user agent I'm running to get straight to the
desired

> point without having to navigate to it.

> 

> I suspect it's the kind of problem that affects some user
agent/assistive

> technology combinations more than others, and some people more than
others.

 

My understanding is that reading the text that surrounds a link in GUI 

screen readers is not at all difficult. It is true that when a user 

pulls up a list of links on a page, surrounding text would no longer be 

available, but I don't believe this is something we should be concerned 

with as this is a case of a UA feature that re-displays the content 

outside of its original context.

 

David, can you clarify where you recommend including this? I assume your


proposed text (Provide meaningful link text, unless the link is part of 

an array of links to different versions (or views) of the same 

information.) is a technique, but it is phrased like a success 

criterion. If the former, would this be advisory or sufficient?

 

-Ben

 

Received on Thursday, 5 January 2006 15:55:51 UTC