RE: About "programmatically determined link context"

How is the question if "a" screen reader implemented a specific preferential function of what to read imply accessibility for anything other than narrowly defined set of technologies and content?  If that specific function is not coded in a product doesn't have anything to do if it can work if coded.  I don't really expect most end users to do such coding themselves, but when something like this is needed by a lot of customers they would ask and something as easy as this gets put in the products as a great sales feature or coded by one person in the open source community.  When you ask if something can be read by an AT product which simply isn't available then you get in to real world operability questions.  There are always formats which lend themselves to customized AT rdndering.  I recall writing functions wich would follow the cursor in 3270 window and read three vertical colum elements of text, since that application presented hex data in that format-hex values and character.  There is never an end to such customization and indicating something is inaccessible without such feature set seems like a no win situation for a developer.




From: Sailesh Panchang [mailto:spanchang02@yahoo.com]
Sent: Thursday, May 08, 2014 12:32 PM
To: rcorominas@technosite.es
Cc: david100@sympatico.ca; WCAG-WG
Subject: 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.