Re: warning category for techniques / failures.

This approach bothers me.  (e.g. Failures are hard so lets create something new that is easier to provide warnings on)

There SHOULD be very few “Common Failures” to document.  

The are only there to get rid of the most obvious common and egregious errors. 

If the working group starts getting into defining warnings and other test tool like behaviors you will not complete the work that only a WG can do.    

I predict endless and lengthly  discussions on this — if you go down this path. 
Leave warnings to the tool people. 
(just my two cents worth.   My opinion / advice on this activity.   Going silent now on whether to have warnings or not   (after I just gave a warning…. ) )  

gregg

> On May 5, 2016, at 10:29 AM, Alastair Campbell <acampbell@nomensa.com> wrote:
> 
> HI Sailesh,
> 
> Let’s separate the examples from the concept. 
> 
> The concept of warnings came about because it is so hard to ‘mint’ new failures. Four new ones in how many years?
> 
> If there were a slightly looser ‘failure’ category, that fits into the current model quite well:
> 
> 1. Sufficient Techniques (reliable way to pass, quite specific, other ways may exist) 
> 2. Advisory Techniques (common ways to pass, but there may be one or more limitations) 
> 3. Warnings (common ways that pages don’t pass, but don’t automatically fail) 
> 4. Failures (common ways that pages definitely fail, quite specific).
> 
> 
> If we had this slightly looser category of things not-to-do, then examples that people generally think should be failures (like David’s recent one) would have a place, and people (like me) wouldn’t feel constrained by the current definition of 'failure'.
> 
> You mentioned that:
>> I would like the WG to not lose  sight of the thought discussed  in a Nov-2015 meeting 
>> and documented: "Best practices may become a category of output when new guidelines, 
>> SC, techniques are published".
> 
> I wasn’t in that meeting, but it sounds like that is something associated with WCAG.next? (New SCs means WCAG.next?).  ‘Best practices’ seems to be wider concept to me, in that each one would probably cross over more than one SC. Is that fair?
> 
> In terms of examples, I think it is easier to link the warnings to SC criteria. Several of the mis-applied techniques I would struggle to point out where they fail an SC, such as title text duplicating link text, incomplete ARIA landmarks, inconsistent skip link targets etc.
> 
> They are things I recommend against by way of showing how to do it properly, but they tend to fall into the usability side of things rather than direct failures, which means they don’t easily fit into the WCAG model at the moment.
> 
> You can find scenarios where the warning examples do not fail, but that is helpful to my point, they are common warning that should trigger a further check. They are not definitely failures.
> 
> Overall, I think both are useful things to work on, but ‘warnings' is conceptually easier to fit into the short to medium term work of the WG (if people agree and are happy to contribute!).
> 
> I’m not wedded to the idea by any means, it might not be a big problem (do we need negative examples?), or there might not be anyone wanting to work on them. It just seemed a good way of providing more negative examples than we can do with ‘failures’
> 
> Cheers,
> 
> -Alastair
> 
> 
> 
> 
> 
> On 04/05/2016, 16:55, "Sailesh Panchang" <spanchang02@yahoo.com> wrote:
> 
>> Hi Alastair,
>> Sure the presentation does state "availability of reliable accessibility guidance" as an assumption. 
>> I did not say "techniques misapplied" is a failure  but a distinct category that  accessibility testers should include in their report. It will not be practical for the WG to attempt to list all "techniques misapplied". But it will help testers if the WG recognizes it as a category with a brief description and a handful of examples and advise designers / developers to guard against these situations. Testers too will have a category against which specific issues can be recorded.
>> 
>> I am not sure about the warning situations you raise:
>> Data table without a visible caption: if there is no visual title for the table or is within a section that has a heading that clearly describes the section's topic, a caption is not needed. Adding one will change the UI and author's intent. 
>> Form control without a visible label: e.g. Search form with text box and Search button: 
>> I have maintained, visually the search button does double duty conveying purpose of the button and a cue for the text box. Accessibility testers turn a blind eye to 3.3.2 in a sense. In this situation title (H65) is sufficient goes the guidance. 
>> 
>> Fieldset / legend for group of controls: If the group has no visible common label required that helps to more fully convey the control's purpose, a legend is not needed. Yes, a fieldset (without legend) will help some users in this situation too. That will involve a small change to the presentation by default. 
>> Use of 'click here' / 'read more’.: This is a 2.4.4 failure if  it is not in a para or list or table etc. or has  no title or aria-describedby or aria-label.
>> 
>> And so forth. So I find it difficult to support a separate category for such  "Warnings".
>> Again,  assumption#1 of that presentation refers to applying the correct technique in the particular situation;  most techniques are grouped by situation they apply to.
>> I would like the WG to not lose  sight of the thought discussed  in a Nov-2015 meeting and documented: "Best practices may become a category of output when new guidelines, SC, techniques are published".
>> I hope the description of a best practice in that CSUN presentation might help in this regard.
>> Thanks and best wishes,
>> Sailesh Panchang