Re: About "programmatically determined link context"

Hi Ramón

I totally support your position. While it is true that JAWS has commands
that read context while sitting on a link.  (see links below **) it is also
true that in 12 years of working with blind Screen Reader users I've never
seen anyone know how to do this or actually use it in the real world. At
the time, around 2005 when this issue came up, those of us on the committee
who were advocating for the concern of screen reader users were looking for
a compromise with those who wanted to ensure that authors of hotel sites
etc, had flexibility with authoring. John Slatin, who was an expert screen
reader user came up with this compromise. But is important to note that he
was quick to say that even as an expert JAWS user, he had never used any of
these keystrokes or even knew about them before investigating this issue
with the group. And in the nearly 10 years since then, it is still an
unknown, and not well supported in most screen readers.

I think in light of aria-describedby, aria-label, and aria-labelledby we
should be considering moving implicit  programmatic association techniques,
such as "enclosing sentence", and "enclosing paragraph" from  sufficient to
advisory.

**
http://www.w3.org/WAI/WCAG20/Techniques/ua-notes/html#H78
http://www.w3.org/WAI/WCAG20/Techniques/ua-notes/html#H80



Cheers,

David MacDonald



*Can**Adapt* *Solutions Inc.*

Tel:  613.235.4902

LinkedIn <http://www.linkedin.com/in/davidmacdonald100>

www.Can-Adapt.com



*  Adapting the web to all users*
*            Including those with disabilities*

If you are not the intended recipient, please review our privacy
policy<http://www.davidmacd.com/disclaimer.html>


On Wed, May 7, 2014 at 8:10 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.
>
>
>
>
>