- From: Alastair Campbell <acampbell@nomensa.com>
- Date: Thu, 5 May 2016 15:29:14 +0000
- To: Sailesh Panchang <spanchang02@yahoo.com>
- CC: GLWAI Guidelines WG org <w3c-wai-gl@w3.org>, "IG - WAI Interest Group List list" <w3c-wai-ig@w3.org>
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
Received on Thursday, 5 May 2016 15:29:50 UTC