Revisions diff markers: enforce 24×24px minimum target size (WCAG 2.5.8)

[R1shabh-Gupta]

What?

Part of #77530

Ensures revision diff marker buttons meet the WCAG 2.5.8 minimum target size of 24×24 CSS pixels.

Why?

Diff marker buttons in the revisions can shrink to as small as 12px by 4px, which falls well below the WCAG 2.5.8 minimum target size of 24 × 24 pixels.

How?

1. Increase the width of the .revision-diff-markers column from 12px to 24px.
2. Add minHeight: '24px' to the button’s inline style.

Testing Instructions

1. Open a post or page with at least two saved revisions.
2. Open the Revisions panel from the editor toolbar.
3. Inspect any .revision-diff-marker button in DevTools. Computed width should be 24px and computed height should be at least 24px, regardless of how small the corresponding block is in the document.

Screenshots or screencast

Before	After

Use of AI Tools

None

[t-hamano]

Thanks for working on this!

I understand that increasing the button size is necessary from an accessibility perspective, but increasing the height may cause buttons to overlap. I'm concerned this might actually make it harder to read.

trunk	This PR

As an intermediate approach, how about using pseudo-elements?

.revision-diff-markers {
	.revision-diff-marker {
		// Expand the hit area to 24px without resizing the visible marker.
		&::before {
			content: "";
			position: absolute;
			inset: 0;
			min-height: 24px;
			top: 50%;
			transform: translateY(-50%);
		}

cc @joedolson @ellatrix @WordPress/gutenberg-design

[R1shabh-Gupta]

Hi @t-hamano, thanks for taking the time to review this PR.

I tested the pseudo-element approach and recorded a short comparison to make the differences clearer. For anyone from the design team following along, here is a side-by-side view of how both approaches behave visually:

Current implementation (24×24px minimum size)

Screen.Recording.2026-04-27.at.6.08.41.PM.mov

Pseudo-element approach

Screen.Recording.2026-04-27.at.10.39.19.PM.mov

One subtle issue I noticed with the pseudo-element approach is related to interaction. When two markers with small heights are close together, clicking in the space between them can sometimes trigger either marker, which may feel a bit unpredictable.

There is a slight visual difference in the selected marker’s color that helps indicate which one is active, so this may mitigate the issue to some extent. It is easier to notice in the video than to describe precisely, but it is another detail worth considering.

[t-hamano]

One subtle issue I noticed with the pseudo-element approach is related to interaction. When two markers with small heights are close together, clicking in the space between them can sometimes trigger either marker, which may feel a bit unpredictable.

Yes, I have the same concern. Let's hear other contributors' opinions.

[jameskoster]

Stronger designs for hover and selected marker states would probably help. Maybe the marker could scale a little on hover/selection?

[joedolson]

An increase on hover state wouldn't solve the accessibility issue - the purpose of the minimum target size is to make it easier for users to place their pointer on the target, and if it only enlarges on :hover, then that goal isn't met. This type of concern is particularly for people with mobility issues that effect precision, like cerebral palsy, essential tremor, or parkinson's.

I think that the overlapping regions using pseudo-elements would have the same problem. The WCAG guideline requires that no other target can be within the 24x24 target circle, so overlapping regions would still be a problem, as it makes it difficult to hit the intended target.

It seems like it would be possible to prevent the buttons from overlapping by expanding the vertical scale to when necessary;

[t-hamano]

It seems like it would be possible to prevent the buttons from overlapping by expanding the vertical scale to when necessary;

It's likely possible, but it might require complex logic to avoid button collisions. Note has such processing.

For the first improvement, how about widening only the width to 24px?

[R1shabh-Gupta]

I’ve removed the minHeight styles as they were causing overlapping issues in some cases. For now, I’ve updated the implementation to widen only the width to 24px as a more conservative improvement.

[github-actions]

The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the props-bot label.

If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message.

Co-authored-by: R1shabh-Gupta <rishabhwp@git.wordpress.org>
Co-authored-by: t-hamano <wildworks@git.wordpress.org>
Co-authored-by: jameskoster <jameskoster@git.wordpress.org>
Co-authored-by: joedolson <joedolson@git.wordpress.org>

To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook.

[t-hamano]

Personally, I think even just widening the width to 24px would be a significant improvement, and we could ship it like this for now. We might be able to address the button conflicts in a follow-up update. What do you think?

[R1shabh-Gupta]

That sounds good to me. Widening the width to 24px feels like a good incremental improvement.

Just a quick check, would you prefer that I update the PR title and description to reflect the current scope?

[joedolson]

Widening the width at least helps; it will still be a minimum well below the WCAG standards, however. That said, it's only possible for it to be that narrow, it's not a certainty.

It would be nice to see an improvement before 7.0 that at least prevented it from being below 24x24 as long as the space is available.

[joedolson]

I'm merging this PR in; I think that this is a very important change, and although this doesn't 100% solve the problem, it will fix it in the majority of cases, and can be worked on incrementally after wards.

Thank you!

[github-actions]

I just cherry-picked this PR to the wp/7.0 branch to get it included in the next release: 19c0148

[ellatrix]

I don't like this change at all. Why can't we do something on focus? Plenty of applications have small ticks on in the scroll area for marking changes. Why do we have to be different?

[joedolson]

Ticks for marking changes can be any size; ticks for navigating to changes need to meet specific WCAG guidelines covering target size. And yes, there are a lot of applications that fail those requirements - I don't see that as a reason to imitate them.

[ellatrix]

These ticks are just a progressive enhancement, we already have the text diff just as before that should be navigable. I added these ticks as an extra, subtle, visual hint.

[joedolson]

Removing the buttons that make them navigation targets would also meet the requirements.

[ellatrix]

What about links/anchors?

[joedolson]

It doesn't make a difference what type of target it is; the guidelines govern any target.