Re: About "programmatically determined link context"

Ramon,
As a JAWS user, I have found Control+NumPad5 works fine to read current paragraph / list item ... for a very very long time now. And I have tried them in Window-Eyes in the past too.
Using JAWS+T (to read page title) makes JAWS read the nearest preceding heading too.
I have lamented  about the lack of similar keystrokes in NVDA  and VO ... VO lets one read next/prev para or sentenceon a MacBook not the current one.
And please do not get me wrong: My first email pointed to the normative definition you refferred to and that's the basis for the WCAG techniques H77, H78,H79, G53, (all sufficient) and H80 (now marked as advisory).
NVDA and VO were not as widely used five years ago and support by JAWS and perhaps another SR like WinEyes was  enough to deem the techniques AT-supported.
In one vein some argue "x y z is a AT limitation or bug", so that should not dictate changes to a technique.   
And then sometimes some argue that the onus should be put on the content developers (by using ARIA) and not AT-developers.
I find this inconsistent.
Note: my first email pointed out that one can use ARIA techniques to  make support more robust in some situations and the WG has agreed to include an aria-describedby technique for SC 2.4.4.
I have written to NVDA developers (James Teh) requesting support for  a keystroke for reading current para and nearest heading like JAWS does . Maybe more users should do so.
My thought is: when two screen readers can implement this, it means it is not something impossible to do.
Thanks and regards,
Sailesh

On Wednesday, May 7, 2014 11:49 AM, Ramón Corominas <rcorominas@technosite.es> wrote:
  
Hi, David and all,

Unfortunately, this is one of those few cases where the issue is not 
only in a technique, but in the WCAG Recommendation itself, since it is 
used as an example in the normative Glossary:

"programmatically determined link context

(...)

Example: In HTML, information that is programmatically determinable from 
a link in English includes text that is in the same paragraph, list, or 
table cell as the link or in a table header cell that is associated with 
the table cell that contains the link.

Note: Since screen readers interpret punctuation, they can also provide 
the context from the current sentence, when the focus is on a link in 
that sentence."

Thus, my view is that we can concentrate not only on depracating 
implicit tecniques, but also on describing their lack of accessibility 
support.

That said, I agree that there should be a compromise between the 
descriptiveness of the links and their verbosity, which can be annoying 
when reading them in context (Wikipedia is a good example).

Kind regards,
Ramón.

David wrote:


> 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