Re: About "programmatically determined link context"

Ramon,
Control+NumPad5 for reading current paragraph is listed on the user agent support page David referred to  and is documented as working at least  in 2005 and I have used it before that too.
It used to be listed in JAWS keys for Word etc. but it seems to have fallen off the list now.
While writing in a word processing program, one needs to read the current sentence or para and it is the same keystroke that works on the Web. If a screen reader does not provide such keys, than it is surely lacking (not just for SC 2.4.4 support) but simply as an SR for  reading / composing text.
How does one know  what keys to use?: Well if one lands on a "Read more" link, one can try Control+NumPad5 to see if it is in a para or list and get useful context or use Ins+T to check for nearest heading.
Ramon, I too am a user and and am interested in  the final user experience. 
I agree, an ordinary user not savvy with HTML etc. does not care if it is the the coding or the browser or AT in use that's lacking, but the end result is that a particular task remains unaccomplished. And it happens to me not infrequently while trying to access websites for shopping, banking, ticketing etc. Then I switch browsers or AT and hope that makes a difference. 
Thanks,
Sailesh
On Thursday, May 8, 2014 8:25 AM, Ramón Corominas <rcorominas@technosite.es> wrote:
  
Hi, Sailesh.

Sailesh wrote:

> Control + Numpad5 / JAWS + T under JAWS screen reader

I've tried those keys, and yes, they work, although I must say that you 
are the first JAWS user I meet that knows about them, and I know many. I 
don't know Window Eyes, there was no Spanish version until recently and 
I've not tried the English one.


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

I'm not sure that JAWS-only -or almost- features are enough to consider 
the technique as accessibility supported. It seems that this technique 
will only work on Windows environments, and only with one or two screen 
readers. I'm open to say "ok for a closed environment" but maybe not for 
a publicly available website.

In any case, even assuming that there are ways to obtain these contexts, 
the issue of essay-and-error identification persists, and the ambiguity 
is still possible, since there is no way to know which is the proper 
context unless using logical deduction. I imagine a "more info" link 
that is in a paragraph after a heading, both of them inside a table cell 
that is associated to a table header. Which of the possible contexts is 
the one that clarifies the purpose of the link? How to know in advance 
which key to press? Is it acceptable that the user is forced to try 
three or more different keys and then guess which one gave the right 
context?

In addition, it is clear that WCAG relies on desktop browsers and 
keyboard, leaving apart mobile users. For the moment, none of these 
techniques are supported on mobile devices. Does WCAG apply exclusively 
to a desktop Web experience?


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

In terms of conformance, I really don't mind about who is responsible of 
fixing "bugs" (if they are really bugs). If a technique is not supported 
on a specific combination of screen reader, browser and operating 
system, maybe it is an AT bug, a browser bug or an OS bug, but in any 
case the user is not able to access, so we cannot say that the technique 
is accessibility supported for that combination. It doesn't matter who 
has to fix the bugs, the problem exists and the user is blocked.

Content developers should know what techniques they can use safely and 
choose those that are accessibility supported under the environment 
where the web page will be available. Or at least make a decision about 
the degree of support they are willing to accept. The problem is that 
techniques do not specify their accessibility support, and when they are 
marked as "sufficient" most developers assume that they are good for 
everyone under any circumstance (for example, PDF techniques are assumed 
to create perfectly accessible PDFs, which is only true on Windows + 
Adobe Reader, and not completely).


> 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 agree, too. I think that explicit association is much more robust. 
Hopefully, aria-describedby will also be accessibility supported some day.

Regards,

Ramón.