Adds topic required form fields to the Web forms section #210
Conversation
|
|
"Both are fine, as long as you are consistent within the form and if possible also withing all forms on your website." Change "withing" to "within". |
|
@GaryJones, @michaelhastrich, @jaapwiering |
|
@joedolson can you have a read too? |
|
|
||
| # Indicate required fields in forms | ||
|
|
||
| Clearly indicate to the user whether a form field is required to fill out or not. |
There was a problem hiding this comment.
Simplify: "Clearly indicate to the user whether a form field is required."
The rest of the sentence is unneeded.
| # Indicate required fields in forms | ||
|
|
||
| Clearly indicate to the user whether a form field is required to fill out or not. | ||
| Then the user knows which information they must provide to submit a form. |
There was a problem hiding this comment.
"Then the user can tell what information they must provide..."
In principle, while making this accessible should make it more probable that a user will know what they need, it technically only makes it possible for them to know it. So I don't like saying "they will know this", just that "they can know this".
|
|
||
| Both are fine, as long as you are consistent within the form and, if possible, also within all forms on your website. | ||
|
|
||
| Always place the explanation of how you indicate this above the form, so the user knows beforehand what to expect when completing it. |
There was a problem hiding this comment.
Maybe: "Always explain how you are indicating required fields above the form..."
| Clearly indicate to the user whether a form field is required to fill out or not. | ||
| Then the user knows which information they must provide to submit a form. | ||
|
|
||
| You have two options: |
There was a problem hiding this comment.
This seems awkward as a list. As a sentence, I might go with:
"You can either add a visual indicator for all required fields, or add a visual indicator for all optional fields."
I'm just not convinced that a list of two items is helping the reader.
| nav_order: 3 | ||
| --- | ||
|
|
||
| # Option 2: Marking only the non-required form fields |
There was a problem hiding this comment.
Omit "the": "Marking only non-required form fields"
Question: do we want to say "non-required" or "optional"? I feel that optional is clearer and easier to read. Having the variants be "required" and "non-required" means that you have to read more carefully to be sure whether you're looking at the right instructions. This is something consistent through these docs.
|
|
||
|
|
||
| {: .alert } | ||
| **Note for developers**: for screen reader users the indication if a field is required must be added in the code with a form field. Read [Mark if a form field is required for screen readers]({{site.baseurl}}/docs/topics/forms/required/required-screen-readers/) about how to do this. |
There was a problem hiding this comment.
The construction "if a field is required must be added in the code with a form field" is confusing; I think that could be clarified. It could also be omitted: I think it would be sufficient here to say "Screen readers have specific needs for discovering required fields. Learn how to indicate required fields for screen readers."
|
|
||
| # Mark a required form field for screen readers | ||
|
|
||
| Screen reader users will have the field announced as required by the HTML attributes `aria-required` or `required` on the form field. |
There was a problem hiding this comment.
Simplify: "Screen readers announce form fields as required if they have the HTML attributes aria-required or required."
|
|
||
| The disadvantage of using `required` is, that it triggers the [client-side form validation](https://developer.mozilla.org/en-US/docs/Learn_web_development/Extensions/Forms/Form_validation) of the browser. | ||
|
|
||
| At the time of writing, this validation does not meet WCAG accessibility guidelines. The error messages are not specific enough, they disappear after a few seconds, and they currently lack sufficient screen reader support. |
There was a problem hiding this comment.
Very technically, browser validation does meet WCAG guidelines, but only because of the exceptions about the appearance and behavior of the interaction being governed by the user agent and not modified by the author. So I'd argue that this should say "is not accessible", rather than "does not meet WCAG".
There was a problem hiding this comment.
In the Netherlands this is a hard WCAG fail for several SC, I, will add more info and resources why this is not reliable enough at the moment.
|
|
||
| At the time of writing, this validation does not meet WCAG accessibility guidelines. The error messages are not specific enough, they disappear after a few seconds, and they currently lack sufficient screen reader support. | ||
|
|
||
| If you decide to use `required`, also use `novalidate` on the form element to prevent the browser's form validation from kicking in and enable you to handle validation server-side. |
There was a problem hiding this comment.
Add: "You can write your own custom client-side validation, as long as you ensure that it's accessible!"
There was a problem hiding this comment.
I don't agree, will add more info and resources why this is not reliable enough at the moment.
Related issue: #160
Preview: https://wpaccessibility.org/pr-preview/pr-210/docs/topics/forms/required/.
The page required is now a section with 4 pages: