Make WordPress Core

Opened 3 years ago

Last modified 6 weeks ago

#18801 accepted enhancement

Accessibility Enhancements to Settings API

Reported by: taupecat Owned by: taupecat
Milestone: Future Release Priority: high
Severity: normal Version: 3.2.1
Component: Options, Meta APIs Keywords: has-patch settings-api
Focuses: accessibility Cc:


I've only started working with the Settings API, but right off the bat I noticed two fairly major, but should be not too difficult to fix, accessibility issues.

1) The label/input field pairs are missing the HTML <label> tags that link the two.

Example: Field One <input id="field_one" name="field_one" type="text">
Should be rendered: <label for="field_one">Field One</label> <input id="field_one" name="field_one" type="text">

2) The settings pages themselves are laid out using a table. Tables should be reserved for tabular data, and not for page layout. CSS should be used for layout instead.

Thanks for your attention.

Attachments (2)

18801.diff (637 bytes) - added by sabreuse 21 months ago.
18801.2.diff (634 bytes) - added by sabreuse 21 months ago.

Download all attachments as: .zip

Change History (18)

comment:1 RyanMurphy3 years ago

Related to (duplicate of?): #16413, #18285

comment:2 taupecat2 years ago

  • Owner set to taupecat
  • Status changed from new to accepted

I've got some downtime at the moment, so I'm going to take a stab at patching this.

sabreuse21 months ago

sabreuse21 months ago

comment:3 sabreuse21 months ago

attachment:18801.2.diff provides a fallback to the ID of the settings field in the case where label_for isn't explicitly provided. (The first diff used the title instead; that was wrong.)

The second problem identified in the ticket, tables in settings output, is discussed in the related tickets in comment 1 -- it's a bigger problem than just this ticket, so I suggest handling the label issue first.

comment:4 sabreuse21 months ago

  • Keywords has-patch added

comment:5 azaozz21 months ago

The settings form elements that don't have <label> in the <th> have <fieldset> and <legend> with the same text. Those are usually multi-input, like radio buttons, that have individual labels.

Perhaps instead of <fieldset> and <legend> we can use aria-labelledby on them and point that to the <th>? That would avoid the repeating texts.

comment:6 unknowndomain16 months ago

  • Keywords settings-3.6 added

comment:7 unknowndomain16 months ago

  • Cc me@… added

comment:8 SergeyBiryukov16 months ago

  • Keywords settings-api added; settings-3.6 removed

comment:9 helen8 months ago

  • Milestone changed from Awaiting Review to 3.8

Should be done together with #16413, so moving to 3.8.

comment:10 matt5 months ago

  • Priority changed from normal to high

comment:11 helen5 months ago

  • Milestone changed from 3.8 to Future Release

comment:12 nacin3 months ago

  • Component changed from Accessibility to Administration
  • Focuses accessibility added

comment:13 helen2 months ago

  • Component changed from Administration to Options, Meta APIs

comment:14 ircbot2 months ago

This ticket was mentioned in IRC in #wordpress-ui by joedolson. View the logs.

comment:15 joedolson2 months ago

I'm looking at this ticket, and it seems very problematic to find a way to use the table header as a label if we don't have access to the user function in the callback. We can set something as an ID, but if we can't intercept the function to add a reference to that ID, I'm not sure what our options are, practically.

I'm going to take a look at the fieldset/legend issue raised by @azaozz as a separate ticket, but I'm not sure what our practical options are for labeling if there's no label_for key set.

comment:16 ircbot6 weeks ago

This ticket was mentioned in IRC in #wordpress-ui by _Redd. View the logs.

Note: See TracTickets for help on using tickets.