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

Dating would have no effect on our concept of conformance... In a 2.1,
there would be no change to our concept of conformance...

However, documenting a date when we created a failure (or last approved)
might give jurisdictions information that they might find useful when they
are making policy and/or laws.

I also like Jason's idea of "technology relied upon" given that this is
consistent with Conformance requirement 4. But regardless I think dating
techniques and failures is good... it's also good administrative tool for
us to review and prioritize review of old techniques... I think this is an
important concept underpinning conformance which has gotten a little lost
in our telephone game of passing on the WCAG.

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