Re: Let's add an approved date field to Failures and Techniques

I don’t think failure to use ARIA would ever be failure.    Use of ARIA is a technique — a way of accomplishing something.   The only time it  would be failure would be if one could prove that there was absolutely no other way of accomplishing the SC without using ARIA.    No way to design the page or use markup or text on the page to accomplish the same thing.   I can’t think of any use of ARIA where that would be true. 

ARIA is an amazingly powerful way of adding semantics to a page in a way that is programmatically determinable - without being otherwise visible — so it is very desirable tool for authors - and one that makes some things very easy.   But just like longdesc was a way of providing a long description - it was not the only way.  D links and even just describing the diagram in the following paragraph would also be sufficient.   Hence “not having a long description” of an essential and complex diagram would be a failure - but using longdesc to do that would not be a failure.   That is just a technology and a technique for doing what the SC requires.   Even there one has to word the failure carefully so it does not create a new requirement.  

for example 

F67: Failure of Success Criterion 1.1.1 and 1.2.1 due to providing long descriptions for non-text content that does not serve the same purpose or does not present the same information <https://www.w3.org/TR/2014/NOTE-WCAG20-TECHS-20140408/complete.html#F67>
carefully uses the wording from 1.1.1   (serve the same purpose)  so that it takes it’s validity from the SC rather than creating new rule.   (actually it should have read  “serves the equivalent purpose” but we evidently were a bit sloppy)   

And again - here we did not say longdesc but rather just  long descriptions. 




gregg

> On Apr 30, 2016, at 9:42 AM, Katie Haritos-Shea <ryladog@gmail.com> wrote:
> 
> Gregg,
> 
> In my mind dating would work as an aid to understanding its rationale.
> 
> So someone seeing a failure of using ARIA a certain way wouldn't think "well this failure is rediculous, ARIA didnt exist in 2008".... or "blink? We havent used it in years".
> 
> We understand common failures are never normative.
> 
> We know they are never normative.
> 
> Katie Haritos-Shea
> 703-371-5545
> 
> On Apr 30, 2016 10:34 AM, "Gregg Vanderheiden RTF" <gregg@raisingthefloor.org <mailto:gregg@raisingthefloor.org>> wrote:
> Hi Katie, David, 
> 
>  Help me understand the “dating” bit.     What value does putting a date on the failures have?   If we document a new failure — it was always a failure - we just documented it now.  We aren’t creating any new things that would fail.       If a new technology is misused in a failing way - and we document it — the documenting of a failure isnt what makes it a failure (it always was) - it just makes it easier to notice / identify.     I’m not sure what the date the we finally documented the failure has to do with anything. 
> 
>  I DO think that a  “last reviewed on”  date would be good — and that all failures should be reviewed every few years to be sure they are still failures.   We found that with improving technologies and new options made some failures - no longer absolute failures.   Sometimes we needed to kill them.  Sometimes we needed to reword them or qualify them so that they were still failures.  
> 
>  But documenting a failure doesn’t mean that something suddenly fails that didn’t before.   That is - documenting something as a failure isn’t what makes it a failure — it always was.  We are just documenting common ones as a service. Hence they are not normative but simply informative of what is already normative (the SC).     So I’m not sure what the date that we finally documented it has to do with anything or what it’s utility would be. 
> 
> thanks 
> 
> gregg
> 
>> On Apr 30, 2016, at 9:23 AM, Katie Haritos-Shea <ryladog@gmail.com <mailto:ryladog@gmail.com>> wrote:
>> 
>> I think actually that as we have had to add techniques because of new technologies, and interaction paradigms, that we do need to also document common failures that use those new things - when we see them happening. And I don't think we need to wait for WCAG.next to do that.
>> 
>> For older sites that didnt rely on those newer technologies, it is not a fail of course. This is also where Davids  suggested dating would help.
>> 
>> Katie Haritos-Shea
>> 703-371-5545 <tel:703-371-5545>
>> On Apr 30, 2016 7:13 AM, "David MacDonald" <david100@sympatico.ca <mailto:david100@sympatico.ca>> wrote:
>> >>> But I would be careful to not fail things that really arent a problem.  That is, it is easy to tell what they are without any special markup. 
>> 
>> Words and phrases like "easy" and  "aren't a problem" is where we, as a group, have to judge. My proposal is that on today's complicated web it's *more* important than in 2008 to identify regions, so it *more* of a problem now than then, and why we should be documenting it now as a common failure. It always failed techically (it was a visually formatted region of content that was took extra time for a blind person to figure out) but it was not a *big* (just a nuisance) problem on text sites of 2008, but now it's *more* of a problem, AND elegant solutions have made it easier to remedy.
>> 
>> Cheers,
>> David MacDonald
>>  
>> CanAdapt Solutions Inc.
>> Tel:  613.235.4902 <tel:613.235.4902>
>> LinkedIn 
>>  <http://www.linkedin.com/in/davidmacdonald100>
>> twitter.com/davidmacd <http://twitter.com/davidmacd>
>> GitHub <https://github.com/DavidMacDonald>
>> www.Can-Adapt.com <http://www.can-adapt.com/>
>>   
>>   Adapting the web to all users
>>             Including those with disabilities
>> 
>> If you are not the intended recipient, please review our privacy policy <http://www.davidmacd.com/disclaimer.html>
>> On Sat, Apr 30, 2016 at 3:31 AM, Gregg Vanderheiden RTF <gregg@raisingthefloor.org <mailto:gregg@raisingthefloor.org>> wrote:
>> Agree.   
>> 
>> Failures are NEVER normative.   And they are never new.   
>> 
>> Failures are simply documenting things that are ALREADY failures of SC.  They just document things that are commonly done that would fail to meet WCAG to make them obvious to those who do not see them.   
>> 
>> Failures can never add nor subtract from WCAG.     Their full name is    “Common failures of WCAG SC”.    
>> 
>> The only way to add something to WCAG or make something a failure that is not already a failure is to look to future versions as Josh points out. 
>> 
>> gregg
>> 
>>> On Apr 30, 2016, at 1:42 AM, Joshue O Connor <josh@interaccess.ie <mailto:josh@interaccess.ie>> wrote:
>>> 
>>> Hi Jason,
>>> 
>>> Yes.  As failures are hard to mint, and David is calling out a need for more,  my 'warning' suggestion is maybe a way of meeting the need without doing normative or quasi normative work. So this suggestion would be firmly in guidance and non normative space.
>>> 
>>> Tbh, that we don't have lots of hardcore failures may also be a good sign rather than indicate some dearth in WCAG. FWIW,  I'm not convinced this thread does call out a substantial problem but if there is real need we will aim to address it.
>>> 
>>> Regarding WCAG.next topics,  in general things we cannot incorporate in current work can be looked at in future versions.
>>> 
>>> Thanks
>>> 
>>> Josh
>>> 
>>> Sent from TypeApp <http://www.typeapp.com/r>
>>> 
>>> On 30 Apr 2016, at 00:44, "White, Jason J" <jjwhite@ets.org <mailto:jjwhite@ets.org>> wrote:
>>> 
>>>   
>>> 
>>> 
>>>   
>>> 
>>> From: Joshue O Connor [mailto:josh@interaccess.ie <mailto:josh@interaccess.ie>] 
>>> Sent: Friday, April 29, 2016 5:57 PM
>>> 
>>> 
>>> I wonder if we could have a 'warning'  category?  So it's not a hard fail,  with all the baggage of gaining consensus, but a common anti pattern that could cause known a11y issues?
>>> 
>>> 
>>> Would that be useful in a WCAG.next ?
>>> 
>>> 
>>> 
>>>   
>>> 
>>> I would prefer them to be in non-normative techniques, if anywhere, not in the guidelines proper.
>>> 
>>> 
>>> 
>>> 
>>>   
>>> 
>>> I thought we were only talking about what should belong in non-normative material in this discussion, yet some people keep referring to WCAG Next, so I really don’t understand what is being proposed.
>>> 
>>> 
>>> 
>>> 
>>>   
>>> 
>>> 
>>> This e-mail and any files transmitted with it may contain privileged or confidential information. It is solely for use by the individual for whom it is intended, even if addressed incorrectly. If you received this e-mail in error, please notify the sender; do not disclose, copy, distribute, or take any action in reliance on the contents of this information; and delete it from your system. Any other use of this e-mail is prohibited.
>>> 
>>> 
>>> Thank you for your compliance.
>>> 
>> 
>> 
>