Opened 6 years ago
Last modified 6 years ago
#47505 accepted defect (bug)
Create a comprehensive input validation API for WordPress editor and administration interface
Reported by: |
|
Owned by: |
|
---|---|---|---|
Milestone: | Future Release | Priority: | normal |
Severity: | normal | Version: | |
Component: | Administration | Keywords: | needs-patch needs-unit-tests needs-design input-validation form-controls |
Focuses: | ui, accessibility | Cc: |
Description
Currently, WordPress lacks a comprehensive API for validating form input and alerting users to errors or missing fields. One example of how this can cause problems was captured by @conner_bw in #47018 -- failing to fill in the required ‘Name’ field when creating a new taxonomy term highlights the field in red but provides no textual message indicating that a required field is missing. As noted by @afercia:
there are at least two WCAG success criteria (1 is level A, the other one is level AA) that requires a clear identification of the item in error and clear suggestions for correction.
The lack of input validation mechanisms has also been noted as a shortcoming in Gutenberg (see tweet from @spacedmonkey about this).
In the Slack discussion of #47018, the Accessibility team agreed that the broader goal of researching and planning a comprehensive form validation API would be a valuable project that would benefit all users. This ticket should serve as a starting point for that exploration process. One example of how this could work shared during the discussion was something along the lines of Tenon’s React-based form validation library: https://www.tenon-ui.info/forms-full-demo
Two use cases that this API should cover:
- Required input is missing
- Required input is not the expected type
To be continued!
Change History (14)
#1
@
6 years ago
- Summary changed from Create a comprehensive form validation API for WordPress editor and administration interface to Create a comprehensive input validation API for WordPress editor and administration interface
This ticket was mentioned in Slack in #design by spacedmonkey. View the logs.
6 years ago
#5
@
6 years ago
Related: #47595 for the post comments form in the front end. Which leads us to: should the proposed API be used also for forms in the front end?
#6
@
6 years ago
Relevant standards:
WCAG Success Criterion 3.3.1 Error Identification
https://www.w3.org/TR/WCAG21/#error-identification
If an input error is automatically detected, the item that is in error is identified and the error is described to the user in text.
WCAG Success Criterion 3.3.3 Error Suggestion
https://www.w3.org/TR/WCAG21/#error-suggestion
If an input error is automatically detected and suggestions for correction are known, then the suggestions are provided to the user, unless it would jeopardize the security or purpose of the content.
#7
@
6 years ago
- Version trunk deleted
Note: removing version "trunk", as it's generally used to indicate regressions in trunk.
This ticket was mentioned in Slack in #accessibility by afercia. View the logs.
6 years ago
This ticket was mentioned in Slack in #accessibility by afercia. View the logs.
6 years ago
This ticket was mentioned in Slack in #accessibility by afercia. View the logs.
6 years ago
This ticket was mentioned in Slack in #accessibility by audrasjb. View the logs.
6 years ago
#13
@
6 years ago
- Milestone changed from Awaiting Review to Future Release
Moving to Future release as it will need some early work during the next release process.
I have a somewhat related ticket on the gutenberg repo - https://github.com/WordPress/gutenberg/issues/14644