WordPress.org

Make WordPress Core

Opened 6 years ago

Closed 5 years ago

Last modified 5 years ago

#30486 closed defect (bug) (fixed)

Missing label associations throughout network admin

Reported by: cfoellmann Owned by: cfoellmann
Milestone: 4.2 Priority: normal
Severity: normal Version: 4.0
Component: Networks and Sites Keywords: has-patch
Focuses: ui, accessibility, administration, multisite Cc:

Description

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.

Attachments (9)

ticket-30486.diff (9.9 KB) - added by cfoellmann 6 years ago.
unfinished-patch
ticket-30486_2.diff (10.1 KB) - added by cfoellmann 6 years ago.
proposed id change
30486.diff (9.7 KB) - added by jeremyfelt 6 years ago.
30486.2.diff (2.6 KB) - added by jeremyfelt 6 years ago.
30486.3.diff (9.5 KB) - added by jeremyfelt 6 years ago.
30486.4.diff (10.7 KB) - added by cfoellmann 6 years ago.
30486.5.diff (12.2 KB) - added by afercia 6 years ago.
30486.6.diff (26.7 KB) - added by afercia 5 years ago.
30486.7.diff (28.2 KB) - added by afercia 5 years ago.

Download all attachments as: .zip

Change History (43)

#1 @joedolson
6 years ago

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
6 years ago

unfinished-patch

#2 @cfoellmann
6 years ago

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
6 years ago

proposed id change

This ticket was mentioned in Slack in #design by cfoellmann. View the logs.


6 years ago

This ticket was mentioned in Slack in #accessibility by cfoellmann. View the logs.


6 years ago

#5 @cfoellmann
6 years ago

  • Keywords has-patch dev-feedback added

#6 @afercia
6 years ago

  • Component changed from Administration to Networks and Sites
  • Version changed from trunk to 4.0

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

This ticket was mentioned in Slack in #core by cfoellmann. View the logs.


6 years ago

#8 @joedolson
6 years ago

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

#9 @cfoellmann
6 years ago

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

This ticket was mentioned in Slack in #accessibility by cfoellmann. View the logs.


6 years ago

#11 @SergeyBiryukov
6 years ago

  • Milestone changed from Awaiting Review to 4.2

@jeremyfelt
6 years ago

#12 @jeremyfelt
6 years ago

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
6 years ago

#13 @jeremyfelt
6 years ago

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

@jeremyfelt
6 years ago

This ticket was mentioned in Slack in #accessibility by rianrietveld. View the logs.


6 years ago

#15 @rianrietveld
6 years ago

@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>

#16 @afercia
6 years ago

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).

#17 @afercia
6 years ago

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

This ticket was mentioned in Slack in #core by jeremyfelt. View the logs.


6 years ago

#19 @jeremyfelt
6 years ago

  • Owner set to cfoellmann
  • Status changed from new to assigned

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.

#20 @cfoellmann
6 years ago

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?

Last edited 6 years ago by cfoellmann (previous) (diff)

#21 @afercia
6 years ago

@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>

@cfoellmann
6 years ago

This ticket was mentioned in Slack in #core by drew. View the logs.


6 years ago

#23 @ocean90
6 years ago

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.

#24 @DrewAPicture
6 years ago

  • Keywords needs-patch added; has-patch removed

This ticket was mentioned in Slack in #design by afercia. View the logs.


6 years ago

#26 @afercia
6 years ago

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
6 years ago

#27 @afercia
6 years ago

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

#28 @afercia
5 years ago

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
5 years ago

#29 @afercia
5 years ago

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.

@afercia
5 years ago

This ticket was mentioned in Slack in #core-multisite by jeremyfelt. View the logs.


5 years ago

#32 follow-up: @jeremyfelt
5 years ago

  • Keywords has-patch added; dev-feedback needs-patch removed

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.

#33 @jeremyfelt
5 years ago

  • Resolution set to fixed
  • Status changed from assigned to closed

I mistyped a ticket number. :)

Fixed in [31517]

#34 in reply to: ↑ 32 @SergeyBiryukov
5 years ago

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.

Note: See TracTickets for help on using tickets.