RE: About "programmatically determined link context"

For 508 conformance assuming "any" AT testing is very problematic to the extreme.  Expecting we scale up actual At testing to a vast developer community without solid data showing cost and methods seems like we are putting requirements out without knowing if they can be accomplished.  So, please correct me if I have missed something, but if someone "tests" content for WCAG conformance but didn't include At in the test process, would the conformance claim be considered valid?  If this invalidates a conformance claim we have reall usability problems for such requirements operationally.  Sorry if this goes off topic and I'll stop if so, but I am just trying to understand the discussion around accessibility supported as it relates to failures and conformance claims.  





-----Original Message-----
From: Katie Haritos-Shea GMAIL [mailto:ryladog@gmail.com] 
Sent: Thursday, May 08, 2014 8:57 AM
To: rcorominas@technosite.es; 'Sailesh Panchang'
Cc: david100@sympatico.ca; 'WCAG-WG'; Katie.Haritos-Shea@Chase.com
Subject: RE: About "programmatically determined link context"

Ramon,

We have just added the requirement of "accessibility support" to the test
procedure for at least one Failure technique F65 in the latest published
version (http://www.w3.org/TR/2014/NOTE-WCAG20-TECHS-20140408/F65.html) of
the Techniques.

I would very much like to see us do more of the same thing for all of the
Sufficient techniques and failures. That will prevent us from having to go
back to update them, and it will get the developers (and others) more
attuned to what accessibility support means.


* katie *
 
Katie Haritos-Shea 
Senior Accessibility SME (WCAG/Section 508/ADA/AODA)
 
Cell: 703-371-5545 | ryladog@gmail.com | Oakton, VA | LinkedIn Profile |
Office: 703-371-5545

-----Original Message-----
From: Ramón Corominas [mailto:rcorominas@technosite.es] 
Sent: Thursday, May 8, 2014 8:22 AM
To: Sailesh Panchang
Cc: david100@sympatico.ca; WCAG-WG
Subject: Re: About "programmatically determined link context"

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.

Received on Thursday, 8 May 2014 13:52:50 UTC