Skip to content
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

Closed
goetsu opened this issue Oct 6, 2015 · 22 comments
Closed
Assignees

Comments

@goetsu
Copy link

goetsu commented Oct 6, 2015

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

@goetsu
Copy link
Author

goetsu commented Oct 26, 2015

example :

Description

This 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.

Examples

a 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>

Tests

Procedure

  • try to submit the form without providing any information, if error message appear to signal required fields check that this information was available before submitting the form in the accessible name programatically associated with the fields and with a visible text or cue positioned near the fields.
  • try to submit the form after filling text input and textarea with "test" content, if error message appear to signal wrong input format check that this information was available before submitting the form in the accessible name programatically associated with the fields and with a visible text or cue positioned near the fields.

Expected Results

If check #1 or check #2 are false, then this failure condition applies and the content fails this success criterion.

@jnurthen
Copy link
Member

Why is example #2 a failure?

@awkawk
Copy link
Member

awkawk commented Oct 26, 2015

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.

@jnurthen
Copy link
Member

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

@awkawk
Copy link
Member

awkawk commented Oct 26, 2015

Ah, right. Assuming all of the necessary accessibility support then #2 would be fine for 3.3.2.

@goetsu
Copy link
Author

goetsu commented Oct 27, 2015

Ok then change replace required with aria-required in example 2 if you prefer

@goetsu
Copy link
Author

goetsu commented Oct 27, 2015

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.

@jnurthen
Copy link
Member

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.

@goetsu
Copy link
Author

goetsu commented Oct 27, 2015

Update of the proposal to include specific format.

@jnurthen
Copy link
Member

jnurthen commented Dec 1, 2015

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.

@goetsu
Copy link
Author

goetsu commented Dec 3, 2015

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

@awkawk awkawk self-assigned this Dec 15, 2015
@joshueoconnor
Copy link
Contributor

I like this draft - good work.

@awkawk awkawk assigned marcjohlic and unassigned awkawk Dec 15, 2015
@srinivasuchakravarthula
Copy link

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.

@awkawk
Copy link
Member

awkawk commented Apr 12, 2016

Preparing to mark as deferred due to inactivity and group resource constraints (https://www.w3.org/WAI/GL/wiki/Handling_Issues).

@goetsu
Copy link
Author

goetsu commented Apr 12, 2016

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 ?

@joshueoconnor
Copy link
Contributor

@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.

@detlevhfischer
Copy link
Contributor

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?

@goetsu
Copy link
Author

goetsu commented Apr 13, 2016

@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

@marcjohlic
Copy link
Member

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.

@marcjohlic marcjohlic mentioned this issue Apr 20, 2016
@marcjohlic
Copy link
Member

Created Pull Request #180
#180
@joshueoconnor / @awkawk Believe this is ready for survey.

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. :)

@patrickhlauke
Copy link
Member

isn't there quite a bit of overlap here with 4.1.2 ?

@alastc
Copy link
Contributor

alastc commented Jun 10, 2019

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.)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

9 participants