Accessibility Enhancements to Settings API

[taupecat]

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.

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

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

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.

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.