![(please configure the [header_logo] section in trac.ini)](/chrome/site/your_project_logo.png){kind=logo}
Opened 5 weeks ago
Closed 7 days ago
#65454 closed defect (bug) (fixed)
Improve accessibility of the setup-config.php page (and install.php)
| Reported by: | afercia | Owned by: | afercia |
|---|---|---|---|
| Priority: | normal | Milestone: | 7.1 |
| Component: | Upgrade/Install | Version: | |
| Severity: | normal | Keywords: | has-screenshots has-patch a11y-visible-labels |
| Cc: | Focuses: | accessibility |
Description (last modified by )
On a fresh install of WordPress, the first page users will get is the setup-config.php page. That's the page with the big select element to choose the default language. See attached screenshot.
On this page:
- The HTML element misses the
langattribute. The lang attribute is necessary for assistive technology, most notably screen readers, to correctly announce the page content. - The big select element has a visually hidden label
Select a default language. There is no good reason to make this label visually hidden. Without a visible label, the UI doesn't tell users what to do on this page. The cognitive load to parse the page and understand the next step is pretty high and a visible label would make everything much clearer.
As a general rule, for best accessibility and usability, labels should only be visually hidden for very good reasons e.g. hard space constraints and such.
Re: the lang attribute, this page should hanle it much like wp-login.php does by using language_attributes() with two caveats:
- It appears
get_language_attributes()doesn't handle well the case whereget_option( 'html_type' )may befalseand end up returning both alangand anxml:langattribute, which is not what we want. - When using
language_attributes(), the handling of thedirattribute and the related CSS class on the setup page should be refactored.
Attachments (2)
Change History (13)
This ticket was mentioned in PR #12163 on WordPress/wordpress-develop by @afercia.
5 weeks ago
#2
- Keywords has-patch added
#3
@
5 weeks ago
In the linked PR:
- Uses
language_attributes(). which also handles thedirattribute as well as thelangattribute. - Makes the select element label visible. See attached screenshot for comparison.
- Changes the visually hidden H1 heading to
Welcome to WordPress, to avoid duplication with the (now visible) label.
Note that on this page the strings aren't really translatable.
Only the 'Continue' button text is, in a way, translated as in: when a language other than English is selected, the button text is updated via JavaScript. See third image in the screenshot. The actual translation comes from the .org API https://api.wordpress.org/translations/core/1.0/. If we want to make also the visually hidden H1 and label change on the fly when users select a language, their translations should be added to the API. Personally, I'd think it would be a bit overkill.
#4
@
5 weeks ago
Reminder that to test the setup-config.php page your installation should not have a wp-config.php file. Either move it away from your WP directory or temporarily rename it so that you can restore it later.
The language chooser select should be tested also in the install.php page.
#5
@
5 weeks ago
- Milestone Awaiting Review → 7.1
- Summary Improve accessibility of the setup-config.php page → Improve accessibility of the setup-config.php page (and install.php)
This ticket was mentioned in Slack in #accessibility by joedolson. View the logs.
4 weeks ago
#9
in reply to: ↑ description
@
3 weeks ago
Thanks for raising these accessibility concerns. I agree with both points.
Adding the lang attribute to the HTML element is important for screen readers and other assistive technologies, especially since this is the very first page users encounter during installation. Aligning its implementation with wp-login.php by using language_attributes() makes sense, provided the edge cases around get_option( 'html_type' ) and the unintended xml:lang output are addressed.
I also agree that the language selector would benefit from a visible label. Since there aren't significant space constraints on this screen, keeping the label visible would improve clarity and reduce cognitive load for all users, while also following accessibility best practices.
Refactoring the handling of the dir attribute and the corresponding CSS class alongside these changes also seems like a sensible approach to keep the implementation consistent.
#10
@
11 days ago
- Owner set to
- Status new → assigned
I addressed first code review feedback on the linked PR https://github.com/WordPress/wordpress-develop/pull/12163.
Anyone else welcome if they have a chance to have a look.
Related: #63008