Make WordPress Core

Opened 2 months ago

Closed 4 weeks ago

Last modified 4 weeks ago

#46899 closed defect (bug) (fixed)

Ensure that tables generated by the Settings API have no semantics

Reported by: greatislander Owned by: SergeyBiryukov
Milestone: 5.3 Priority: normal
Severity: normal Version:
Component: Administration Keywords: settings-api has-patch
Focuses: accessibility, administration Cc:


As per Slack discussion today, the <table> element that is output by do_settings_sections() should have a role="presentation" attribute to remove table semantics as it is only used for layout purposes.


Related Tickets:

Attachments (2)

46899.diff (586 bytes) - added by greatislander 2 months ago.
Patch from https://github.com/WordPress/WordPress/pull/401
46899.2.diff (20.7 KB) - added by greatislander 7 weeks ago.
Patch from https://github.com/WordPress/WordPress/pull/404

Download all attachments as: .zip

Change History (16)

#1 @greatislander
2 months ago

  • Keywords has-patch added; needs-patch removed

#3 @conner_bw
2 months ago

Note regarding the ARIA 1.1 none role: In ARIA 1.1, the working group introduced none as a synonym to the presentation role, due to author confusion surrounding the intended meaning of the word "presentation" or "presentational." Many individuals erroneously consider role="presentation" to be synonymous with aria-hidden="true", and we believe role="none" conveys the actual meaning more unambiguously.

Source: https://www.w3.org/TR/wai-aria-1.1/#none

#4 @afercia
2 months ago

@conner_bw thanks. WordPress needs to support also old browser / assistive technologies combinations that may not understand role=none.

#5 @afercia
2 months ago

@greatislander thanks for the patch! Worth noting 46899.diff will only have an effect on settings sections added by plugins. The core settings screens in WordPress don't use the Settings API, see #38734.

For the core tables, role="presentation" needs to be added to all the settings pages options-general.php, options-writing.php, options-reading.php, etc. plus the settings pages in the multisite part.

Note: There are other layout tables outside the settings pages (typically they have a form-table CSS class) but I'd say they're out of the scope of this ticket.

For some background, there are various pending tickets related to the Settings API. Some of them focus on the UI part, most notably #16413, #18801, and #39441. Also, a couple years ago @flixos90 and @afercia explored improvements to the Settings API in a plugin published on GitHub see https://github.com/wpaccessibility/settings-api-enhanced.

#6 @SergeyBiryukov
7 weeks ago

  • Version trunk deleted

Removing the trunk version, as this is not a regression in 5.2.

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

7 weeks ago

#8 @afercia
7 weeks ago

  • Component changed from Plugins to Administration
  • Keywords needs-refresh added
  • Milestone changed from Awaiting Review to 5.3

Discussed during today's accessibility bug-scrub and we'd like to try this for the next 5.3 release. The patch needs to b extended to other layout tables used in core.

#10 @greatislander
7 weeks ago

  • Keywords needs-refresh removed

@afercia Updated patch to cover every other instance of <table class="form-table"> that I could find on admin settings pages.

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

7 weeks ago

#12 @SergeyBiryukov
4 weeks ago

  • Owner set to SergeyBiryukov
  • Resolution set to fixed
  • Status changed from new to closed

In 45403:

Accessibility: Make sure layout tables across the admin are correctly linearized.

Adds role="presentation" to the <table> elements used for layout purposes.

Ideally, HTML tables should be used for tabular data. When tables are used for layout purposes, it's important to remove any native semantics so that assistive technologies can correctly announce the table content in a linearized fashion.

Props greatislander, afercia.
Fixes #46899.

#13 @afercia
4 weeks ago

For history and context: the addition of role="presentation" is a temporary improvement, pending decisions and progress on the proposal to entirely remove layout tables from WordPress. See #16413, #18801, #39441, and the explorations made on https://github.com/wpaccessibility/settings-api-enhanced.

I'm going to open a follow-up ticket to address some edge cases not covered in this ticket.

#14 @afercia
4 weeks ago

In 45416:

Accessibility: Improve settings tables and forms after [45403].

  • adds role="presentation" to the edit comment table
  • removes a few pointless <fieldset> elements
  • adds a few missing <label> elements
  • adds the CSS class class="td-full" to table rows spanning to multiple cells
  • adds explicit scope="row" attribute to the table headers in options-permalink.php: this table is better communicated as data table
  • uses consistent label association in the "Privacy Settings" page
  • in the installation page "Set up your database connection": associates descriptions to their inout fields using aria-describedby
  • improves the link to gravatar.com in the user-edit.php page

See #46899.
Fixes #47390.

Note: See TracTickets for help on using tickets.