You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: site/src/content/docs/foundation/form-validation.mdx
+38-38Lines changed: 38 additions & 38 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -11,47 +11,41 @@ extra_js:
11
11
---
12
12
import { getDocsRelativePath } from'@libs/path'
13
13
14
-
## Accessibility
15
-
16
-
Ensure that all form components have an appropriate accessible name so that their purpose can be conveyed to users of assistive technologies by using a `<label>` element linked, or—in the case of buttons—to include sufficiently descriptive text as part of the `<button>...</button>` content.
17
-
18
-
For situations where it’s not possible to include a visible `<label>` or appropriate text content, there are alternative ways of still providing an accessible name, such as:
19
-
20
-
-`<label>` elements hidden using the `.visually-hidden` class
21
-
- Pointing to an existing element that can act as a label using `aria-labelledby`
22
-
- Providing a `title` attribute
23
-
- Explicitly setting the accessible name on an element using `aria-label`
24
-
25
-
If none of these are present, assistive technologies may resort to using the `placeholder` attribute as a fallback for the accessible name on `<input />` and `<textarea>` elements.{/* The examples in this section provide a few suggested, case-specific approaches. */}
26
-
27
-
While using visually hidden content (`.visually-hidden`, `aria-label`, and even `placeholder` content, which disappears once a form field has content) will benefit assistive technology users, a lack of visible label text may still be problematic for certain users. Some form of visible label is generally the best approach, both for accessibility and usability.
28
-
29
14
## How it works
30
15
16
+
OUDS Web provides custom feedback styles that apply custom colors, borders, focus styles, and background icons to better communicate feedback. to use them, you’ll need to add the `novalidate` boolean attribute to your `<form>`. This disables the browser default feedback tooltips, but still provides access to the form validation APIs in JavaScript.
17
+
31
18
Here’s how form validation works with OUDS Web:
32
19
33
20
- HTML form validation is applied via CSS’s two pseudo-classes, `:invalid` and `:valid`. It applies to `<input />`, `<select>`, and `<textarea>` elements.
34
21
- OUDS Web scopes the `:invalid` and `:valid` styles to parent `.was-validated` class, usually applied to the `<form>`. Otherwise, any required field without a value shows up as invalid on page load. This way, you may choose when to activate them (typically after form submission is attempted).
35
22
- To reset the appearance of the form (for instance, in the case of dynamic form submissions using Ajax), remove the `.was-validated` class from the `<form>` again after submission.
36
-
{/* for [server-side validation](#server-side) */}
37
-
- As a fallback, `.is-invalid` class may be used instead of the pseudo-classe `:invalid`. It doesn't require a `.was-validated` parent class.
38
-
- All modern browsers support the [constraint validation API](https://html.spec.whatwg.org/multipage/form-control-infrastructure.html#the-constraint-validation-api), a series of JavaScript methods for validating form controls.
39
-
- Feedback messages shouldn't use the browser defaults (different for each browser, and unstylable via CSS) but our custom feedback styles with additional HTML and CSS.
23
+
- As a fallback, `.is-invalid` class may be used instead of the pseudo-class `:invalid` for [server-side validation](#server-side). It doesn't require a `.was-validated` parent class.
24
+
- All modern browsers support the [constraint validation API](https://html.spec.whatwg.org/multipage/form-control-infrastructure.html#the-constraint-validation-api), a series of JavaScript methods for validating form controls. You may provide custom validity messages with `setCustomValidity` in JavaScript.
40
25
- Feedback messages should use our custom feedback styles with additional HTML and CSS, rather than the browser defaults (which differ for each browser and can't be styled via CSS).
41
-
- You may provide custom validity messages with `setCustomValidity` in JavaScript.
42
26
43
27
With that in mind, consider the following demos for our custom form validation styles and optional server-side classes.
44
28
45
-
## Custom styles
29
+
## Accessibility
46
30
47
-
For custom OUDS Web form validation messages, you’ll need to add the `novalidate` boolean attribute to your `<form>`. This disables the browser default feedback tooltips, but still provides access to the form validation APIs in JavaScript.
31
+
OUDS Web's form elements are designed to be accessible in particular by always using a `<label>` linked to a form element (beware though to use the right `id`). This allows assistive technologies to convey the purpose of each form field to users.
48
32
49
-
Try to submit the form below; our JavaScript will intercept the submit button, add `.was-validated` to the `<form>`, and you’ll see the `:invalid` and `:valid` styles applied to the fields. For invalid fields, it also associates the invalid feedback/error message with the relevant form field using `aria-describedby` (noting that this attribute allows more than one `id` to be referenced, in case the field already points to additional description/helper text).
33
+
You must take care to specify the validation rules for each field using an appropriate attribute like `required`, `pattern`, `min`, `minLength`, etc. This allows assistive technologies to understand the validation requirements for each field and communicate them to users. The form fields will be marked as `:invalid` if the user input doesn't meet the specified validation rules.
50
34
51
-
Custom feedback styles apply custom colors, borders, focus styles, and background icons to better communicate feedback.
35
+
To make your form validation accessible, you also have to ensure that any feedback messages are properly associated with the relevant form field using `aria-describedby` when the field becomes invalid. This is important for users of assistive technologies, as it allows them to understand what went wrong and how to fix it.
36
+
37
+
## Client-side
38
+
39
+
Try to submit the form below; our JavaScript will intercept the submit button, add `.was-validated` to the `<form>`, and you’ll see the `:invalid` and `:valid` styles applied to the fields. For invalid fields, it also associates the invalid feedback/error message with the relevant form field using `aria-describedby` (noting that this attribute allows more than one `id` to be referenced, in case the field already points to additional description/helper text).
@@ -177,7 +171,13 @@ We recommend using client-side validation before server-side validation. If serv
177
171
For invalid fields, ensure that the invalid feedback/error message is associated with the relevant form field using `aria-describedby` (noting that this attribute allows more than one `id` to be referenced, in case the field already points to additional description/helper text).
178
172
179
173
<Examplecode={`<form novalidate>
180
-
<fieldset class="control-items-list mb-2xlarge">
174
+
<p>
175
+
This form simulates server-side validation with custom validation styles.
0 commit comments