Missing label associations throughout network admin

[cfoellmann]

There are several instances throughout the network admin where there are no proper associations between labels and their corresponding form fields.

<input> fields should have <label for=""> associated.

[joedolson]

Hi! Can you be specific? It can save an enormous amount of time if you can provide some guidance about specifics; screenshots of the fields or admin URL/screen locations, code references, anything. Thanks!

[cfoellmann]

unfinished-patch

[cfoellmann]

Following parts are presenting an issue:
​https://github.com/cfoellmann/WordPress/blob/ticket-30486/wp-admin/network/site-users.php#L272
+
​https://github.com/cfoellmann/WordPress/blob/ticket-30486/wp-admin/network/site-users.php#L305
These <select>s have the same id which is screwing with the labels. Would it be an issue to rename them?
Currently id="new_role_0" is used for both. Any suggestions?

[cfoellmann]

proposed id change

[afercia]

Just for reference: screenshot showing the 2 selects with same ID in /wp-admin/network/site-users.php?id={$blog['blog_id']}

[joedolson]

I don't see any issue with re-naming those IDs; this all seems good to me. These should definitely be labeled!

[cfoellmann]

will this id change effect the select and #19867 in any way?
No other possible issues as far as I can see.

[jeremyfelt]

Replying to cfoellmann:

will this id change effect the select and #19867 in any way?
No other possible issues as far as I can see.

I don't believe so. The only ID changed here is new_role_0 to split between new_role_adduser and new_role_newuser. This isn't in use yet anywhere in core.

Looks good, @cfoellmann. I updated the patch in 30486.diff to bring it current with trunk and address a couple things:

• In site-new.php, use the now existing (as of [30578]) IDs site-address, site-title, and admin-email IDs.
• In site-info.php, add labels for registered and last updated dates.

[jeremyfelt]

Refreshed in 30486.2.diff to avoid adding back the inline styles we removed previously.

[rianrietveld]

@jeremyfelt Thanks for this work :-) We found a few bugs:
In ms.php

<th><label for="blog_upload_space"><?php _e( 'Site Upload Space Quota '); ?></th>

Missing a </label>

In site-info.php, if the Domain and Path are already filled out the input field changes to <code> Then there are labels with no input fields assigned.

<th scope="row"><?php _e( 'Domain' ) ?></th> 
<th scope="row"><label for="domain"><?php _e( 'Domain' ) ?></label></th>
<td><code><?php echo $parsed['scheme'] . '://' . esc_attr( $details->domain ) ?></code></td>

[afercia]

In the accessibility testing meeting, noticed also some labels still missing: some parts of the network admin UI are actually from functions in main files like for example in dashboard.php:
wp_network_dashboard_right_now()
"Search Users" and "Search Sites", where we'd recommend to add visually hidden labels (with .screen-reader-text).

[afercia]

Just noticed also:

• the two readonly textareas in setup.php.
• in site-settings.php *for the main site*, besides Domain and Path there are also Siteurl and Home under the "Settings" tab that after the network is created, are just orphan labels without an associated input field

[jeremyfelt]

Thanks for the feedback @afercia and @rianrietveld!

@cfoellmann - I'll leave it to you. Looks like we can solve these last few things pretty easily.

[cfoellmann]

I think I have all issues addressed in this ​https://github.com/cfoellmann/WordPress/commit/51d0d0e67b985e82254a7740cf094bfc62f7d4f2

@afercia I am not sure about the screen-reader-text - What do you think?

[afercia]

@cfoellmann looks OK, you can see examples of visually hidden labels through all WP, e.g.: search posts

<label class="screen-reader-text" for="post-search-input">Search Posts:</label>

[ocean90]

Some input fields have a title attribute which I think can be removed when we add labels to the fields. Otherwise 30486.4.diff​ looks good. If we're going to remove the titles we should do it at the same time, in this case we need an updated patch.

[afercia]

Reviewed a bit the patch, in order to:

• remove some title attributes (found just 3?)
• add one aria-describedby
• avoid duplicated IDs: in site-settings there were 2 fields with conflicting IDs: "blog_upload_space", one of them is added via 'wpmueditblogaction' hook and is still there but with a new ID (name unchanged)

Outstanding issues:

• don't know exactly what to do with disabled fields with "SERIALIZED DATA", they have a label now but they're disabled... but they *may* be enabled
• besides the tables used for layout purposes, now many new labels (and many of the pre existing ones too) are inside th with scope="row". This is used in many places in WordPress but should be avoided. See details below.

Consider this example:
before, with missing labels

<th scope="row"><?php _e( 'Username' ) ?></th>
<td><input type="text" class="regular-text" name="user[username]" id="user_username" /></td>

Here, explicitly establishing a logical relationship between the th (using scope=row!) and the cell maybe was meant to have some sort of association between the "text" (not a label) and the form field. Worth noting that's not just the use of tables for layout purposes: it's about the header/cell relationship that should be used to establish relationships only between *data* not between text and form controls. Nothing new here, it's all about correct and semantic representation of tabular data. I'm not adding anything new to what the specs say.
Table headers are not meant for visual purposes. They're not "headings" or titles. They're meant to provide information about the type of data inside the related table cells. Any software, including screen readers, will get these relationships and use them to represent the data structure.

After, with the new labels:

<th scope="row"><label for="user_username"><?php _e( 'Username' ) ?></label></th>
<td><input type="text" class="regular-text" name="user[username]" id="user_username" /></td>

Now, we have a "double association". First, the th and td relationship (which is incorrect). Then, the label/field association. Any software will get this double thing and get confused. That's redundant and should be avoided. Screen readers (tested with NVDA) will read out the label twice, including table columns/rows information, e.g.:

table
Username row 1 column 2 <-- th/td relationship
Username edit has auto complete <-- label/field association
blank

Discussed with @helen and @michaelarestad on Slack and agreed to keep it as is for now, any thoughts more than welcome.

[afercia]

My bad, forgot to upload the updated patch. Sorry.

[afercia]

Updated patch fixes a missed-missing label for the delete user -> reassign select.
I would also propose to improve the accessibility level adding aria attributes where appropriate, for example using existing description paragraph as target for "aria-describedby" and adding some new descriptions, some of them hidden with .screen-reader-text.
Tried also to improve semantics, e.g. adding fieldsets for checkboxes and radio buttons groups.

[afercia]

Thanks to the accessibility user testing group coordinated by Rian Rietveld, and special thanks to Anna Natorilla :) we spotted a couple more missing labels:

• in /wp-admin/my-sites.php the "primary site" select doesn't have a valid label
• in all the users list tables (not just in the network): the select checkbox label for attribute value does not match the id attribute value of the checkbox

See updated patch.

[rianrietveld]

Accessibility testing results at: ​https://make.wordpress.org/accessibility/2015/02/16/missing-label-associations-throughout-network-admin-accessibility-user-test-result/

[jeremyfelt]

Great work everyone. I've read through 30486.7.diff a handful of times and am comfortable with where its at. Let's land this.

I'm having trouble finding an existing ticket right now, but per ​this conversation we should address the <th><label> issue associated with our table layouts at some point.

[jeremyfelt]

I mistyped a ticket number. :)

Fixed in [31517]

[SergeyBiryukov]

Replying to jeremyfelt:

I'm having trouble finding an existing ticket right now, but per ​this conversation we should address the <th><label> issue associated with our table layouts at some point.

Related: #16413, #18801.