Re: About "programmatically determined link context"

Hi Ramon--

Wouldn't pressing the "alt + numpad 5" keys in JAWS (for example) to read the sentence be an acceptable way to get context, without losing current focus on the link?

That said, it's been one of the mysteries to me of the WCAG 2.0 revision that permits getting context by reading preceding text (SC 2.4.4), including paragraphs. This would seem to encourage the use of redundant links like "read more".

There's bound to be a trade-off between reading efficiency and listening to lengthy, descriptive links, but I would think that skimming would be facilitated by getting context directly from the link.

Mike


On Wednesday, May 7, 2014 8:11 AM, Ramón Corominas <rcorominas@technosite.es> wrote:
 
Hello, Sailesh and all,

> This is built upon key-combinations to make a screen reader read a 
> sentence / paragraph (or the title of the page / application) ... keys 
> that users employ routinely across applications including word 
> processing or even on a Web page . So these are not obscure key 
> combinations.

That "routine" you mention seems to be an obscure thing for me and for 
all my blind colleagues. And they are all advanced screen reader users, 
but they do not know anything about the mere existence of any of those 
combinations that supposedly allow you to obtain the context without 
moving the keyboard focus.

How do you obtain the preceding heading of a link using JAWS or 
VoiceOver, for example, without moving the keyboard focus? How do you 
obtain the full text of the enclosing paragraph or list item without 
moving the keyboard focus from the link?. I know a combination for a 
link inside a data cell that is associated with a header cell, but I'm 
not able to find those other keys in JAWS, NVDA or VoiceOver help.



> Placing a link in a paragraph or sentence is normal construct; requiring 
> one to place aria-labelledby/describedby additionally on contextual 
> content is good for more robust / usability but may be needed in some 
> situations even to pass SC 2.4.4.

I think that, in most situations, an explicit association is a 
requirement (provided that accessibility support exists). Even assuming 
that the combinations might exist and supposing that every user knows 
them, unless the context is explicitly associated (maybe using 
@aria-describedby or @aria-labelledby), a blind user would be forced to 
try every combination by essay-and-error before getting the appropriate 
context for the link.

In conclusion, I think that, for the moment, there is no accessibility 
support for most of the possible contexts mentioned in WCAG and they 
should not be accepted to meet CR #4.

Kind regards,
Ramón.