Re: warning category for techniques / failures.

Hello Alastair,
>>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.
Sailesh:
If the technique is not implemented as documented, it impacts the SCs
it applies to.
Usability impacts everyone generally; on the other hand techniques
misapplied impact only those who depend on accessibility quite
adversely. So the content does become inaccessible.
e.g. Typically one relies on technique H2 for image links. So if the
alt duplicates the anchor text and is not called out because it fails
test#2 of H2, does it not lead to a failure?

Consider a skip nav that points to start of main content correctly but
the main landmark is set at a different spot.: Which one is correct?
The incorrect landmark implementation is in effect disrupting or
breaking  accessibility. This is not usability.
 Thanks,
Sailesh Panchang




On 5/5/16, 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
>

Received on Thursday, 5 May 2016 17:10:59 UTC