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

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