[wp-trac] [WordPress Trac] #30486: Missing label associations throughout network admin

[WordPress Trac]

#30486: Missing label associations throughout network admin
-------------------------------------+-------------------------------------
 Reporter:  cfoellmann               |       Owner:  cfoellmann
     Type:  defect (bug)             |      Status:  assigned
 Priority:  normal                   |   Milestone:  4.2
Component:  Networks and Sites       |     Version:  4.0
 Severity:  normal                   |  Resolution:
 Keywords:  dev-feedback needs-      |     Focuses:  ui, accessibility,
  patch                              |  administration, multisite
-------------------------------------+-------------------------------------

Comment (by 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.

--
Ticket URL: <https://core.trac.wordpress.org/ticket/30486#comment:26>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform