- From: David MacDonald <david100@sympatico.ca>
- Date: Fri, 29 Apr 2016 21:16:51 -0400
- To: Gregg Vanderheiden RTF <gregg@raisingthefloor.org>
- CC: Katie Haritos-Shea <ryladog@gmail.com>, IG - WAI Interest Group List list <w3c-wai-ig@w3.org>, GLWAI Guidelines WG org <w3c-wai-gl@w3.org>, Laura Carlson <laura.lee.carlson@gmail.com>, John Foliot <john.foliot@deque.com>, Andrew Kirkpatrick <akirkpat@adobe.com>, Joshue O Connor <josh@interaccess.ie>, "Denis Boudreau (gmail)" <dboudreau01@gmail.com>, Kevin White <kevin@dewoollery.co.uk>
- Message-ID: <BLU436-SMTP6637B71B30A179BF19E24BFE670@phx.gbl>
The legacy aspect in this particular situation is this... When we wrote WCAG no evaluator failed a page under 1.3.1 for not informing a user programmatically that they were entering a header, footer, navigation region or Main content. But in hind site we *should* have. It was an information and relationship that was visual but not perceivable to blind people except by exploring around and guessing. Soon after, Landmarks came out and solved the problem. They took minutes to add to entire sites in most cases and allowed the blind user to know when they entered that section or not and also allowed them to easily jump to that region 2.4.1 The issue was brought up by Paul Adam who felt there should be a failure. After originally arguing against the failure, I thought it through and felt there was a basis for a proposal. technologies relied upon on most sites include HTML 5. Hence, the proposal for a failure of 1.3.1 filed as issue 1.3.1 Legacy sites could do this with text or headings... however, there is the problem that none of use failed these sites back in 2008 so why would we fail them now. And that is what torpedoed the failure... some argued it was too hard to do... some argued that old sites would suddenly fail... My thought is: - In hindsight we should have failed pages for not informing users that they were entering a section of the page that visually set apart. It is an information and relationships issue - There are hardly any old sites around from 2008 - This is easy to fix now - It has a high impact on end users. Hence I wrote https://github.com/w3c/wcag/issues/173 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 Fri, Apr 29, 2016 at 6:57 PM, Gregg Vanderheiden RTF < gregg@raisingthefloor.org> wrote: > but voting a failure through is almost impossible especially in the light > of legacy sites.. > > > I am confused. > > Failures should only be documentation of things that WCAG required but are > not met by some condition….. hence a failure. > > If we document a failure today based on WCAG — it was always a failure. > And legacy sites failed it or not back in 2008 whether we documented it or > not. > And legacy sites that didn’t fail WCAG in the past — won’t fail any > failure we document today. > We cannot create any new failure conditions - we can only document what > was always a failure under WCAG. > > The only exceptions I can think of (e.g. it fails today because new > technologies now…. ) would only mean that a failure would have to be > defined and scoped properly. > > > Now I agree that creating Failures ( and creating techniques) is a LOT of > work. Ive done many and there is no getting around the fact that it is a > lot of work. > but I miss the legacy content aspect. > > *gregg* > > On Apr 29, 2016, at 4:39 PM, David MacDonald <david100@sympatico.ca> > wrote: > > I spent 10 hours on Issue 173 trying to those 3 things ... > https://github.com/w3c/wcag/issues/173 > I rewrote it numerous times addressing concerns... changing scope trying > to accommodate the legacy question... > > Yes, it's a lot of work, and I think that work was reasonably well done, > but voting a failure through is almost impossible especially in the light > of legacy sites...I trust the group conscience, and am not going to push > it, except to hope that we can provide add some common failures in 2.1... > > 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 Fri, Apr 29, 2016 at 4:09 PM, Gregg Vanderheiden RTF < > gregg@raisingthefloor.org> wrote: > >> the biggest thing holding back documenting failures — is that it is a lot >> of work. >> >> >> 1. have to explore it >> 2. have to find out if there are ways to succeed while doing this >> 3. have to qualify it properly ( If xxxxxx is used ….) >> >> then you have to write it up >> >> lot of work. >> >> >> *gregg* >> >> On Apr 29, 2016, at 1:53 PM, David MacDonald <david100@sympatico.ca> >> wrote: >> >> >> I think 4 failures in 8 years is fewer than the common failures that we >> as a11y evaluators have seen show up on many of our reports since that time. >> >> >> > >
Received on Saturday, 30 April 2016 01:17:23 UTC