- From: Katie Haritos-Shea <ryladog@gmail.com>
- Date: Sat, 30 Apr 2016 11:36:21 -0400
- To: CAE-Vanderhe <gregg@raisingthefloor.org>
- Cc: WAI Interest Group <w3c-wai-ig@w3.org>, WCAG <w3c-wai-gl@w3.org>
- Message-ID: <CAEy-OxFpKgSBOqg5Kkb+zRXiy3aapi6TOxFwECvH3_QgJekp+w@mail.gmail.com>
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. >>>>> ------------------------------ >>>>> >>>> >>>> >>> >> >
Received on Saturday, 30 April 2016 15:36:55 UTC