- From: Brian Bors <b.bors@accessibility.nl>
- Date: Mon, 29 Jul 2019 10:41:05 +0200
- To: Jonathan Avila <jon.avila@levelaccess.com>
- Cc: "w3c-wai-ig@w3.org" <w3c-wai-ig@w3.org>
- Message-ID: <CAKekdvW18S9TW0S-io_22pZgKLA57-Qy=Xuj+56W3JNU5zxmTw@mail.gmail.com>
Hey All, The techniques and understanding documents are non-normative (although they are a good indication of what the original intention of the SC was). When doing audits for legal reasons I would say we should stick to the normative text instead of trying to guess the original intention of the SC. The SC text itself doesn't demand anything of the sort, it just demands labels or(!) instructions to be present (and doesn't define the term instructions). I would happily hear from some official source that this should fail but so far I would have passed all 4 scenario's on both SC 3.3.2 as SC 2.4.6. Greetings, Brian Bors [image: Facebook] <http://www.facebook.com/accessibilitynl> [image: Twitter] <http://www.twitter.com/accessibilitynl> [image: LinkedIn] <https://www.linkedin.com/company/accessibilitynl> [image: Instagram] <https://www.instagram.com/accessibilitynl> [image: Logo Stichting Accessibility - Digitale toegankelijkheid voor iedereen] Op di 23 jul. 2019 om 20:29 schreef Jonathan Avila < jon.avila@levelaccess.com>: > The one item from Patrick that I disagree with -- but previously agreed > with -- was instructions stating what the asterisk means. H90 a sufficient > technique seems to guide us that the intention was the describe what the > asterisk means. > > Jonathan > > > On 23/07/2019 13:01, Gerard Copinga wrote: > > Hello, > > > > I've looked in the archives but could not really find an answer to my > > question, so I will ask it here. > > > > I have always understood that it was mandatory to indicate which form > > fields are required and which are not. If I read the understanding > > document of SC 3.3.2 it is also listed as a benefit: > > > > "Providing clear and unambiguous labels and instructions (including > > clear identification of required fields) can prevent users from making > > incomplete or incorrect form submissions, which prevents users from > > having to navigate once more through a page/form in order to fix > > submission errors." > > > > So I was under the impression that it was mandatory to clearly > > identify required fields. There is also a technique for this (H90 : > > https://www.w3.org/WAI/WCAG21/Techniques/html/H90 ). > > > > But there has been some discussion on this in my network. Can anyone > > explain to me if it is a MUST or a SHOULD. In other words, can I FAIL > > SC > > 3.3.2 (or 2.4.6?) in the following cases or not? > > There's probably a bit of judgement/subjectivity here, depending on the > situation... > > > 1) There is no visible indication of which form fields are required ; > > and some are required and some are not. > > I'd fail under 3.3.2 (I'd not ding it under 2.4.6 if the label is > otherwise descriptive enough of what's expected by the user, even if the > required-ness isn't clearly signposted, but arguably that my personal take > on it) > > > 2) There is no visible indication of which form fields are required ; > > and all are required (for instance a login form with username and > > password fields). > > I would not fail this under 3.3.2 nor 2.4.6, as it's clear from > context/habit that the fields are required. > > > 3) There is a visible indication by using a * (asterisk), but there is > > no explanation of the meaning of the * (asteriks). > > I would not fail this under 3.3.2 nor 2.4.6, as it's a fairly > common/broadly understood convention, though I would recommend for other > reasons (e.g. AT not announcing the asterisk depending on verbosity > settings) that it might not be ideal (prefer using spelled out > "(required)") > > > 4) There is no visible indication of which form fields are required ; > > and some are required and some are not. But after submitting the form > > there is a message at each required input field saying that the field > > is required. > > Fail under 3.3.2, as the point of 3.3.2 roughly is that it avoids this > sort of surprise/frustration. > > Of course, interpretations on this may vary, so this is purely my personal > take on it. > > P > -- > Patrick H. Lauke > > www.splintered.co.uk | https://github.com/patrickhlauke > http://flickr.com/photos/redux/ | http://redux.deviantart.com > twitter: @patrick_h_lauke | skype: patrick_h_lauke > >
Received on Monday, 29 July 2019 08:41:54 UTC