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

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