Improve HTML semantics in Site Health Info tables

[audrasjb]

In Site Health Infos screen /wp-admin/site-health.php?tab=debug, tables should use the semantic HTML element <th> instead of a regular <td> table cell. The current implementation is stricto sensu valid because of the presentation role, but I don't think these tables are used only for presentation at the first place: these are merely classic tabular data :) So let's get rid of the presentation role and add regular table markup.

For instance, currently we have:

<table role="presentation">
	<tbody>
		<tr>
			<td>Version</td>
			<td>6.8</td>
		</tr>
		<tr>
			<td>Site Language</td>
			<td>en_US</td>
		</tr>
	</tbody>
</table>

The correct markup should be:

<table>
	<tbody>
		<tr>
			<th scope="row">Version</th>
			<td>6.8</td>
		</tr>
		<tr>
			<th scope="row">Site Language</th>
			<td>en_US</td>
		</tr>
	</tbody>
</table>

Note 1: The scope attribute may be overkill here, as stated in WCAG implementation notes: ​https://www.w3.org/TR/WCAG20-TECHS/H63.html.

For simple tables that have the headers in the first row or column then it is sufficient to simply use the TH elements without scope.

My own opinion is that it doesn't hurt to add it, but that's also why I'm adding the accessibility focus on this ticket.

Note 2: By using <th>, the font size will increase from 13px to 14px. If we don't want that, we'll have to add a specific CSS rule for this implementation.

[hbhalodia]

Hi @audrasjb, I would like to work on this ticket.

Thank You,

Trac Ticket : https://core.trac.wordpress.org/ticket/62880

Trac ticket: https://core.trac.wordpress.org/ticket/62880

[hbhalodia]

Hi @audrasjb, ​https://github.com/WordPress/wordpress-develop/pull/8209 - has fix for the font-size and also remove role="presentation" which was an initial ask.

We can update this PR, if we do not want 13px font size to th and keep it as 14px and also for scope="row", if we intended to remove this on discussing with accessibility team.

[audrasjb]

Hi @hbhalodia and @rvouill,

Thanks for the PRs!

Moving this ticket for 6.8 consideration.

[rvouill]

Hi @audrasjb and thank you for the feedback on my first core contribution

Thanks for contribution.

Closing in favour of #8209

The changes looks good to me.

Hi @sabernhardt, Can you please review the PR, I have updated the PR with the requested changes.

Thank You,

This looks good to me.
@sabernhardt any further request before committing this changeset?

[sabernhardt]

I finally looked into the history: #46725 and its ​preceding Slack discussion indicated a preference for adding role="presentation" to treat these simple tables as layout. This needs more discussion before committing a change in another direction.

[audrasjb]

Pinging @joedolson: I think we really should treat these tables as real HTML tables.

[joedolson]

I'd like to hear an opinion from a full-time screen reader user on this. I read over the discussion from the last time we talked about this, and while I'm still inclined to believe that, I think that an actual user should make the final call.

Practically speaking, this *is* a data table, it's just an extremely simple data table. If we're going to override the semantics, let's get a second opinion this time.

@alexstine If you have any time to give an opinion, that would be much appreciated.

[audrasjb]

If we're going to override the semantics, let's get a second opinion this time.

@joedolson Maybe I get your comment wrong, but I don't think we're going to override the semantics. We would rather avoid overriding the semantics and threat this table as it is: tabular data :)

This would allow people to navigate between cells as they would with regular tabular data.

[joedolson]

@audrasjb I wasn't speaking in relation to your proposed change; more that if I'm going to argue in favor of keeping things as they are, I'd like to get a screen reader user's opinion, first.

[alexstine]

@joedolson Is there anything to test at this point? I am hesitant to ever override native semantics unless there is a clear reason to do so.

[audrasjb]

@alexstine then if overriding the native semantics is bad (which is my opinion), we should just commit this changeset, right?

[joedolson]

@audrasjb I think let's go ahead and restore this table to native semantics. It is different from the other cases where we've marked tables as presentational, so I think this makes sense.

[audrasjb]

Yes it sounds logical to me as well 👍

[audrasjb]

In 59859:

Site Health: Improve HTML semantics for tables used in Site Health debug tab.

This changeset removes the presentation role from the Site Health debug tab tables to switch them into regular data tables, and updates the related stylesheet to keep the previously used styles.

Props audrasjb, hbhalodia, rvouill, mukesh27, sabernhardt, joedolson, alexstine.
Fixes #62880.

[afercia]

I think the main point from #46725 was that if this data has to be treated as tabular data then the columns should have table headers. This is mentioned in the very first sentence of the ticket description on #46725:

we've discussed if these tables should be treated as data tables (and thus have proper table headers)

I'm not opposed to remove the presentation role but then why we're not adding headers for the columns?

Is the 'horizontal' relationship provided by scope="row" sufficient?

[joedolson]

I think that the horizontal relationship is probably sufficient. Having a thead element is necessary for a table that has data organized in columns, but practically speaking this table really only depends on the rows. We could add headers, but they would be extremely generic, e.g. "Test" and "State" or something to that effect. I think that data is too generic to be semantically valuable. (This was one of the arguments for keeping this presentational in the first place: any relevant heading would be too generic to be useful.)

Allowing this to have some tabular relationships but not requiring it to have less meaningful relationships still seems like a reasonable solution.

I think that adding headings would just be satisfying semantic purity, but not actually providing meaningful context for the user.