#54344 closed defect (bug) (fixed)
Required inputs on multisite site registration page lack required attribute
Reported by: |
|
Owned by: |
|
---|---|---|---|
Milestone: | 6.1 | Priority: | normal |
Severity: | normal | Version: | 5.8.1 |
Component: | Login and Registration | Keywords: | required-fields has-patch add-to-field-guide |
Focuses: | accessibility, multisite, ui-copy | Cc: |
Description (last modified by )
When a user attempts to create a new site on a WordPress multisite which allows registered users to create new sites (wp-signup.php), the signup page treats both 'site domain' and 'site title' as required fields, displaying an error message if either field is left blank. However, neither of the inputs has the required
attribute that would indicate that this is the case to users of assistive technology (Site Title input + Site Name/Domain input).
Second, while the site domain input has a label, the label does not include the URL content that is included in the address by default (the root URL for the subdomain or subdirectory installation). As a result, users of screen readers and other assistive technology may attempt to input the entire URL they wish to use for their site, resulting in an invalid value.
I'm willing and able to provide a simple patch to add the required attribute to the site domain and site title input fields, if that's considered a welcome addition to WP core.
Attachments (5)
Change History (29)
This ticket was mentioned in Slack in #accessibility by sabernhardt. View the logs.
3 years ago
#3
@
3 years ago
In addition to the input fields output by show_blog_form()
, wp-signup.php calls show_user_form()
which outputs a user name field and a user email field. Like the site name and site title fields, the user name and user email fields are required and would benefit from a required
attribute.
#4
@
3 years ago
- Keywords has-patch added; needs-patch removed
54344.diff adds a required attribute to the following form fields:
- blogname
- blog_title
- user_name
- user_email
This ticket was mentioned in Slack in #accessibility by ryokuhi. View the logs.
3 years ago
#7
@
3 years ago
- Milestone changed from Awaiting Review to 6.0
- Type changed from enhancement to defect (bug)
Hello @SteelWagstaff, and thanks again for reporting the issue.
Teh ticket was reviewed today during the accessibility Team's bug-scrub.
Given that the ticket already has a patch, we're milestoning it for 6.0.
#8
@
3 years ago
Looks like the required
attributes are included in the patch, but I agree that there should be some helpful text to prevent users from entering the entire URL for subdomains. The span.suffix_address
makes this clear to non-assistive users, but it should be made clear to all that only the subdirectory or subdomain should be entered.
This ticket was mentioned in Slack in #accessibility by ryokuhi. View the logs.
3 years ago
This ticket was mentioned in Slack in #accessibility by sabernhardt. View the logs.
3 years ago
This ticket was mentioned in Slack in #accessibility by ryokuhi. View the logs.
3 years ago
#15
@
3 years ago
Connecting the prefix or suffix to the blogname input field with aria-describedby
might be enough context to understand the field. (I plan to use aria-describedby
for other fields, too, in a patch for #40361.)
I'd also like to consider adding clear instructions within the labels, for example:
- 'Site Name (enter the subdirectory):'
- 'Site Domain (enter the subdomain):'
This ticket was mentioned in Slack in #accessibility by ryokuhi. View the logs.
3 years ago
#17
@
3 years ago
On Slack, @ryokuhi suggested adding "only" to the labels, as in:
- 'Site Name (enter the subdirectory only):'
- 'Site Domain (enter the subdomain only):'
#18
@
3 years ago
I think that can be tightened up to "Site Name (subdirectory only)" and "Site Domain (subdomain only)"; 'enter' is something that I think can be assumed in this context.
This ticket was mentioned in Slack in #accessibility by sabernhardt. View the logs.
3 years ago
#20
@
3 years ago
- Keywords needs-refresh added
If #40361 is committed first, then the patch would only need to add the required attributes and edit the text for the two labels. (Or commit them together.)
Thanks for the report!
You already noticed the related ticket:40361, with a larger scope, but this might be good to address separately (especially if the label text is improved).
Also related: #32510