-
Notifications
You must be signed in to change notification settings - Fork 257
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
failure for not identify required fields and input format before submit #121
Comments
example : DescriptionThis failure ensures that people with visual, motor or cognitive disabilities will recognize required fields and input format before to submit the form to minimize input errors. Fields that are required or that need specific input format are frequently formatted in fixed, distinctive ways, and authors may feel that just providing visual formatting of the fields will be sufficient to identify them. However, this information must be be available programatically and visually and it must be available before submitting the form. Examplesa form with three fields of which one required field and one with a specific format Failure example 1 : no information on required field and specific input format:<p>
<label for="name">Name</label>
<input type="text" id="name">
</p>
<p>
<label for="city">City</label>
<input type="text" id="city">
</p>
<p>
<label for="date">Date of birth</label>
<input type="text" id="date">
</p>
</form> Failure example 2 : visual information only<form>
<p>Field with * are mandatory</p>
<p>
<label for="name">Name</label>
<input type="text" id="name">*
</p>
<p>
<label for="city">City</label>
<input type="text" id="city">
</p>
<p>
<label for="date">Date of birth</label>
<input type="text" id="date">(yyyy/mm/dd)
</p>
</form> Failure example 3 : programatically associated information only<form>
<p>
<label for="name">Name</label>
<input type="text" aria-required="true" id="name">
</p>
<p>
<label for="city">City</label>
<input type="text" id="city">
</p>
<p>
<label for="date">Date of birth</label>
<input type="text" id="date" aria-label="Date of birth (yyyy/mm/dd)">
</p>
</form> TestsProcedure
Expected ResultsIf check #1 or check #2 are false, then this failure condition applies and the content fails this success criterion. |
Why is example #2 a failure? |
I'd say that example 1 fails 1.3.1 but not 3.3.2, example 2 fails 3.3.2 but not 1.3.1, and example 3 fails both. |
Why does #2 fail? The default rendering of required on many browsers includes an indication that the field is required. In these cases it is fine for 3.3.2 IMO |
Ah, right. Assuming all of the necessary accessibility support then #2 would be fine for 3.3.2. |
Ok then change replace required with aria-required in example 2 if you prefer |
Or a class="required" and a JavaScript associated with that classname to make the field required. My point with that failure proposal is to make more clear that not mentioning required status of fields in an accessible manner (visually and programmatically) PRIOR to submit is a failure. |
I'm fine with either of those so long as it is made clear in the failure example that there is not CSS indicating that the field is required based on that attribute. The test procedure also needs changing to be Check#1 AND Check #2 are false then failure condition applies, not an OR. |
Update of the proposal to include specific format. |
We need to ensure that this does not fail content where this information is not known ahead of time. There are instances where fields are required only based on complex business logic which is ONLY available on the server following a form submit. This is the same for everyone so don't see how this could possibly be an accessibility violation. |
i'm not against this exception if you think it's needed but be careful because you can apply "the same for everyone" argument even for presence of label or the whole SC 3.3. SC 3.3 exist in WCAG to help user to avoid mistake because people with disabilities are more likely than others to make mistakes |
I like this draft - good work. |
Absolutely agreed. I do as well think that it's essential to notify required fields before submit. Specially it is helpful when there are more fields to deal with. Now that there are enough techniques to indicate required fields to users, I think we should make it as a requirmenet. Good work on the draft. |
Preparing to mark as deferred due to inactivity and group resource constraints (https://www.w3.org/WAI/GL/wiki/Handling_Issues). |
so the draft is looking good but it still get deferred ? I don't get it, what is the formal process to move that draft to an official technique ? |
@goetsu look at the current techniques and try to find one that mirrors as closely as possible your suggested technique and then that can be submitted to the group.Try to get it into a as 'close to finished' version and take care with ensuring things like the test procedure are very clear etc. I also see that @marcjohlic is listed on this one - were you going to work together? NOTE: @goetsu that the deferred state again (In this case as I think it is a useful failure technique) means that it can be dealt with in future versions. |
Has the example content changed since comments were made? Does #2 still refer to failure example 2? in this case I don't understand @jnurthens comment "Why does #2 fail? The default rendering of required on many browsers includes an indication that the field is required". I guess it pertains to #3, correct? |
@joshueoconnor I don't know why @marcjohlic is listed here, the problem is that there isn't any failure right now for 3.3.2 so I can't mirrors it and for the techniques itself there is already https://www.w3.org/WAI/GL/2016/WD-WCAG20-TECHS-20160105/H90 https://www.w3.org/WAI/GL/2016/WD-WCAG20-TECHS-20160105/G184 and https://www.w3.org/WAI/GL/2016/WD-WCAG20-TECHS-20160105/G89 @detlevhfischer yes I chane the example number 2 and 3 since the comment of @jnurthen and aria-required do not provide visual indication |
I'm listed here just as a WG member that raised their hand to work on getting this submitted. It's definitely been a resource constraint issue - however, I'm planning to work on this one today - and get the pull request submitted. |
Created Pull Request #180 Note: I will be floating around in the Caribbean next week and will not be on the 4/28 WG call to make edits if this is surveyed then. :) |
isn't there quite a bit of overlap here with 4.1.2 ? |
Unless someone puts their hand up to work on this, I'll close it soon. (It's so old the previous PR was in XML, so it would need re-doing and updating to deal with whatever the issues were from 3 years ago.) |
I think we need a failure to cover the case where no information is given to identify required fields and input format before submit because for me that a clear violation of SC 3.3.2
The text was updated successfully, but these errors were encountered: