- From: Gregg Vanderheiden RTF <gregg@raisingthefloor.org>
- Date: Sat, 30 Apr 2016 09:34:23 -0500
- To: Katie Haritos-Shea <ryladog@gmail.com>
- Cc: IG - WAI Interest Group List list <w3c-wai-ig@w3.org>, GLWAI Guidelines WG org <w3c-wai-gl@w3.org>
- Message-Id: <CAEEB779-411D-4868-AA9A-F533093832ED@raisingthefloor.org>
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 <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. >> > >
Received on Saturday, 30 April 2016 14:34:55 UTC