RE: About "programmatically determined link context"

That helps Katie.
If we can just think carefully when developing failure examples how we expect a developer to incorporate assistive technologies in a meaningful way, and then what that implies for their education requirements, it helps think about the return on the investment of the requirement.  There is always value in validation of operability, but each of such activities has an associated cost in education, time, and at the end of the day, money.  Some of such actions are very difficult to justify accept for specific conditions or situations and I'd just like to put it out there for us to think about that when putting such information up, especially for general case usage.  I would think of this like the WCAG 2.0 levels 1, 2, and 3, some testing is not warranted for levels 1 and 2 but probably is well worth it for level 3.



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

Allen,

As you know specific Techniques (failures, sufficient and advisory) are
NEVER required for WCAG. The requirement added to the test procedure is to
help developers (and others) understand their responsibility to
take-into-account what their intended users environment is expected to be.
(All the way from an enclosed intranet to the wild web).

It is my understanding that the Section 508 refreshed standards using WCAG 2
are not expected to be using the WCAG 2 Conformance Requirements component
of the spec. Am I mis-informed?

I do not think that WCAG *requires* testing with AT (though we all know it
is a good idea). We do expect organizations who want to follow WCAG to meet
accessibility requirements for their content to use the latest data to
determine what elements and components are currently supported in their
intended web environments.

The Failure technique F65 test procedure does *not* require testing with AT.
It required understanding whether or not your intended user environment
supports one of those three ARIA components or not.

* 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: Hoffman, Allen [mailto:allen.hoffman@hq.dhs.gov] 
Sent: Thursday, May 8, 2014 9:52 AM
To: Katie Haritos-Shea GMAIL; rcorominas@technosite.es; 'Sailesh Panchang'
Cc: david100@sympatico.ca; 'WCAG-WG'; Katie.Haritos-Shea@Chase.com
Subject: 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 14:19:24 UTC