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

Gregg,

I didnt say or mean, failure to *use* ARIA. I meant, as an example for
dating rationale, a common failures of using a particular ARIA component to
meet some SC requirement.

Again, I am not even sure ARIA common failures are needed....

Katie Haritos-Shea
703-371-5545
On Apr 30, 2016 10:57 AM, "Gregg Vanderheiden RTF" <
gregg@raisingthefloor.org> wrote:

> 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> 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>
>> 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
>> On Apr 30, 2016 7:13 AM, "David MacDonald" <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
>>>
>>>
>>> *Can**Adapt* *Solutions Inc.*
>>> Tel:  613.235.4902
>>> LinkedIn
>>> <http://www.linkedin.com/in/davidmacdonald100>
>>> 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> 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>
>>>> 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> wrote:
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> *From:* Joshue O Connor [mailto:josh@interaccess.ie
>>>>> <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.
>>>>> ------------------------------
>>>>>
>>>>
>>>>
>>>
>>
>