RE: About "programmatically determined link context"

[David wrote] 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.



>From reading the discussion in Understanding SC 2.4.4 it appears that the
benefits of providing this information in relationship to headings, list
items, paragraphs, etc. extends to users with cognitive and motor
disabilities.  Thus, any action to make this requirement explicit should
not negate the need to ensure these former programmatic associations are
still available for other user groups.  Thus, I don’t recommend moving it
to advisory.



Best Regards,



Jonathan



*From:* David MacDonald [mailto:david100@sympatico.ca]
*Sent:* Wednesday, May 07, 2014 10:28 AM
*To:* rcorominas@technosite.es
*Cc:* Sailesh Panchang; WCAG-WG
*Subject:* 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



*CanAdapt* *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.