W3C home > Mailing lists > Public > w3c-wai-ig@w3.org > April to June 2016

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

From: Gregg Vanderheiden RTF <gregg@raisingthefloor.org>
Date: Fri, 29 Apr 2016 23:39:15 -0500
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: <3825BECE-A9DA-42EE-A60C-37C723D4F4D1@raisingthefloor.org>
To: David MacDonald <david100@sympatico.ca>
WCAG 1.3.1 said - and says - that anything that is visually presented (obvious to someone with vision) needs to be programmatically determinable or be presented in text.   

If something looks like a Header - it must be marked up as a header.

If it is navigation, it needs to be possible for someone without vision to tell that it is navigation.    Etc.  

Usually it is obvious from the contents that they are nav or footer.   

But if it is not - then something needs to be provided.    Always have.  

but be careful with failures.   We often found that the failure — after we stopped specifying things needed to be done a particular way - ended up just being a parrot of the SC which doesn’t help. 

I think failures are the hardest thing to do right — and are the most dangerous when done wrong.   



RE old and new sites.    If you passed things that should have failed — that doesnt mean you need to pass them now.    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. 



Good luck. 



gregg

> On Apr 29, 2016, at 8:16 PM, David MacDonald <david100@sympatico.ca> wrote:
> 
> 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 <https://github.com/w3c/wcag/issues/173>
> 
> Cheers,
> David MacDonald
>  
> CanAdapt Solutions Inc.
> 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 Fri, Apr 29, 2016 at 6:57 PM, Gregg Vanderheiden RTF <gregg@raisingthefloor.org <mailto: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 <mailto:david100@sympatico.ca>> wrote:
>> 
>> I spent 10 hours on Issue 173 trying to those 3 things ...
>> https://github.com/w3c/wcag/issues/173 <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
>>  
>> 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 Fri, Apr 29, 2016 at 4:09 PM, Gregg Vanderheiden RTF <gregg@raisingthefloor.org <mailto:gregg@raisingthefloor.org>> wrote:
>> the biggest thing holding back documenting failures — is that it is a lot of work.
>> 
>> have to explore it
>> have to find out if there are ways to succeed while doing this
>> 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 <mailto: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 04:39:49 UTC

This archive was generated by hypermail 2.3.1 : Saturday, 30 April 2016 04:39:51 UTC