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

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