RE: About "programmatically determined link context"

This helps me contextually.

I would just restate, however, my heart felt suggestion for everyone working any portions of this effort, is to consider not only the part being discussed, but how any change or new information will effect all the various aspects of usage over time, and with that consideration at least discuss the benefits and challenges of the new or updated information.  This work is tremendously important and helpful, but, at least to me, doing the analysis of what the benefits and challenges and outcome of each and every success criteria, sufficient technique, failure condition, test process, conformance requirement, or understanding text is extremely important for all involved in the operational side of producing equal access to information and data.




From: CAE-Vanderhe [mailto:gregg@raisingthefloor.org]
Sent: Thursday, May 08, 2014 10:54 AM
To: Hoffman, Allen; Katie Haritos-Shea; rcorominas@technosite.es; Sailesh Panchang; David MacDonald; GLWAI Guidelines WG org; Katie.Haritos-Shea@Chase.com
Subject: Re: About "programmatically determined link context"


Disclaimers/background
No one can speak authoritatively for the Working Group - or for the Standard.  They speak for themselves.

  *   If a question is to be asked of the current working group - it should be addressed to the group on the public comment list.
  *   For the standard - it speaks for itself in it's language.
  *   For the intent of the WG when it wrote the standard - one should read the Understanding WCAG 2.0 at the time that WCAG was released (though more recent versions have been made to make some thing clearer).  That is the purpose of that doc.  And this is standard procedure with standards etc.
All this is by way of saying that the following is my recollection as co-chair when WCAG was released.  It is not more than that (though I do have a quite clear memory of this since we spent quite a bit of time on it).


My understanding of this topic (Accessibility Support)

  1.  WCAG requires that there be real assistive technologies that work with the content.  One cannot just electronically  "expose" the information and claim conformance if there is no AT that exists that actually will expose it to the user.
  2.  WCAG does not specify how MANY assistive technologies need to support it.  Nor does it specify whether they need so support it in their native configuration.
     *   It was  felt that this went beyond setting a standard or measure - and getting into how that measure would be used (getting into regulation).
     *   It was also felt that this could change in different situations.  (e.g. a company intranet would only need to work with the AT in a company while the Internet might require more.
     *   It was decided in the end to leave this up to those using the standard (companies buying web services and putting language in their RFP,  the government setting 508 regs,   companies setting internal standards, etc.) to make those determinations.
     *   This was a specific and deliberate decision of the WCAG WG.   'There had to be support by real AT, but the working group (and WCAG) does not define how much, leaving that to the users of the standard (purchasing agents, the government, companies internally using the standard to set their internal standards etc.) to make those determinations.'

RE  508 -  until 508 comes out it is not clear what it will or will not require.    So I think informed discussion by most of us (those not involved in writing it) will need to await it's release.


hope this is helpful

Gregg


On May 8, 2014, at 9:18 AM, Hoffman, Allen <allen.hoffman@hq.dhs.gov<mailto:allen.hoffman@hq.dhs.gov>> wrote:


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<mailto:rcorominas@technosite.es>; 'Sailesh Panchang'
Cc: david100@sympatico.ca<mailto:david100@sympatico.ca>; 'WCAG-WG'; Katie.Haritos-Shea@Chase.com<mailto: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<mailto: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<mailto:rcorominas@technosite.es>; 'Sailesh Panchang'
Cc: david100@sympatico.ca<mailto:david100@sympatico.ca>; 'WCAG-WG'; Katie.Haritos-Shea@Chase.com<mailto: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<mailto:rcorominas@technosite.es>; 'Sailesh Panchang'
Cc: david100@sympatico.ca<mailto:david100@sympatico.ca>; 'WCAG-WG'; Katie.Haritos-Shea@Chase.com<mailto: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<mailto: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<mailto: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.