Opened 4 years ago
Last modified 5 months ago
#40361 assigned defect (bug)
Improvements for wp-signup.php and wp-activate.php markup and CSS
Reported by: |
|
Owned by: |
|
---|---|---|---|
Milestone: | Future Release | Priority: | normal |
Severity: | normal | Version: | |
Component: | Login and Registration | Keywords: | has-screenshots good-first-bug has-patch |
Focuses: | accessibility, multisite | Cc: |
Description (last modified by )
Splitting this out from #23197.
First time trying to customize the network registration screens and noticed a few issues.
Bugs that should be addressed, also related to accessibility:
- labels not correctly associated (see screenshot)
- mixed use of explicitly and implicitly associated labels: explicitly associated ones should be preferred
- text not wrapped in semantic elements, often just within
<div>
s - an
<ul>
list (noemail-tips) output within a paragraph - buttons have a very unique styling, pretty inconsistent with the default WP styles. They don't use the .button CSS class so loading the .buttons.css stylesheet won-t have any effect; the body element also would need a wp-core-ui CSS class
- indentation: spaces instead of tabs
Possible improvements, maybe to split out in separate tickets:
- I'm not sure to understand why wpmu_signup_stylesheet() and wpmu_activate_stylesheet() output inline styles, maybe it's just for historical reasons; ideally, deprecate them or move the styles to login.css
- wp-activate fails to output a proper document <title> tag, not sure this can be solved (see #23197)
- when customizing the registration/activation screens, it's very difficult to distinguish all the screens for styling purposes: there's
$stage
that can be used to some extent, for example to add CSS classes on the body but it doesn't cover all the cases. Ideally, there should be an easy way to add CSS classes for each step or they should be built-in
Two labels for the same element, the first one should be a fieldset legend together with the sentence "Allow search engines...":
Attachments (1)
Change History (19)
This ticket was mentioned in Slack in #accessibility by afercia. View the logs.
4 years ago
#4
in reply to:
↑ description
@
4 years ago
#5
@
4 years ago
- Keywords good-first-bug added
- Milestone changed from Awaiting Review to Future Release
The first part related to markup and CSS could be ideal for a good first bug. Moving to future release.
#7
@
4 years ago
- Keywords reporter-feedback removed
@allisonplus thanks! I was referring to the buttons in the signup form, the ones you get on a multisite installation when you register on the front-end.
P.S. The form changes depending on the registration option enabled.
#9
follow-up:
↓ 13
@
4 years ago
- Keywords has-patch added
- Owner set to allisonplus
- Status changed from new to assigned
Assigning ownership to mark the good-first-bug
as "claimed".
This ticket was mentioned in Slack in #accessibility by afercia. View the logs.
3 years ago
This ticket was mentioned in Slack in #core-multisite by flixos90. View the logs.
3 years ago
#13
in reply to:
↑ 9
@
3 years ago
I'm unable to replicate this on my end multi-site-wise so if someone else is able to, please feel free to transfer ownership.
This ticket was mentioned in Slack in #accessibility by afercia. View the logs.
2 years ago
#15
@
2 years ago
@jeremyfelt anyone in the Network and Sites team willing to have a look at this for 5.2?
This ticket was mentioned in Slack in #core-multisite by jeremyfelt. View the logs.
2 years ago
#17
@
14 months ago
Don't know if this is the appropriate place for this, but we had an a11y issue filed in our WordPress based project noting that the wp-signup.php page lacks a main landmark role. See https://github.com/pressbooks/pressbooks/issues/1786 & https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Roles/Main_role. Is that in scope for already planned work?
Replying to afercia:
This was previously fixed in #13638 and #24960, looks like it was reintroduced at some point.