The "Tap targets are not sized appropriately" metric should be under Accessibility, not SEO

[proimage]

Describe the bug The "Tap targets are not sized appropriately" metric should be under Accessibility, not SEO.

To Reproduce Steps to reproduce the behavior:

1. Test any site with too-small tap targets.

Expected behavior I expected to find "Tap targets are not sized appropriately" categorized as an Accessibility metric, not an SEO one.

Screenshots If applicable, add screenshots to help explain your problem.

[robdodson]

I think both the a11y tests and SEO tests check for this. @connorjclark let me know if I'm mistaken. If that is the case, then maybe the LH folks had a good reason for surfacing it under SEO

[brendankenny]

tap-targets is not in the Lighthouse accessibility tests; currently (and historically) those have solely come from axe. There's not a strong reason for the delineation, we've just always deferred to axe for selecting a11y tests, and tap-targets came through the "mobile friendly" SEO recommendations.

Interestingly I don't see any discussion in the axe-core repo for any sort of tap/touch target rule. I wonder why...just less focused on the multi-device story?

[robdodson]

oh interesting. I guess that answers it then :D

[proimage]

Not sure what/who "axe" is; all I know is that from a common-sense POV, having inappropriately-sized (too small) tap targets is a literal example of something on a site not being sufficiently accessible for coarse pointers (aka "fingers"). It has nothing whatsoever to do with Search Engine Optimization (unless you consider SEO issues to be the things for which Google might penalizes a site in their rankings). ¯\_(ツ)_/¯

[adamraine]

@brendankenny do search engines rank pages based on tap target size, or was that just a general recommendation?

[brendankenny]

I don't have any more information than anyone else with access to a search engine, but at least at the time tap targets was being added to Lighthouse, that was the advice from Google. See Finding more mobile-friendly search results and the linked guides. Discussion way back in #4358 and #5846.

@proimage I do agree that tap target size is an accessibility issue--ensuring usable tap targets are exactly why it's part of the "mobile friendly" section--I was just explaining why it's not part of the (capital-A) Accessibility category in Lighthouse. Moving it there may be the right thing to do, but I'd like to have a discussion with the axe folks first about if there's a reason they haven't tackled this before.

[proimage]

Ok, well as this is hardly a mission-critical issue, I'll leave it in y'all's more than capable hands. I was just pointing it out. :)

[connorjclark]

Axe is working on a rule for target spacing here: https://github.com/dequelabs/axe-core/issues/2652

I'll compare the results between our two implementations.

In the meantime, we are going to hold off on adding this to the a11y category because we think it's valuable to keep the that code vetted by a11y experts ala axe.

[connorjclark]

I've read WCAG wrt target spacing, and found a few areas we may wish to fix in tap-targets first.

---

BTW, the relevant WCAG guidelines:

WCAG 2.1 https://www.w3.org/TR/WCAG22/#target-size-enhanced

(Level AAA)
The size of the target for pointer inputs is at least 44 by 44 CSS pixels except when:

Equivalent
The target is available through an equivalent link or control on the same page that is at least 44 by 44 CSS pixels;
Inline
The target is in a sentence or block of text;
User Agent Control
The size of the target is determined by the user agent and is not modified by the author;
Essential
A particular presentation of the target is essential to the information being conveyed.

WCAG 2.2 (draft) adds https://www.w3.org/TR/WCAG22/#target-size-minimum

Success Criterion 2.5.8 Target Size (Minimum)
Understanding Target Size (Minimum)|
How to Meet Target Size (Minimum)(Level AA) [New]
Targets have an area of at least 24 by 24 CSS pixels, except where:

Spacing: The target offset is at least 24 CSS pixels to every adjacent target;
Inline: The target is in a sentence or block of text;
Essential: A particular presentation of the target is essential to the information being conveyed.
NOTE
Targets that allow for values to be selected spatially based on position within the target are considered one target for the purpose of the success criterion. Examples include sliders with granular values, color pickers displaying a gradient of colors, or editable areas where you position the cursor.

EDITOR'S NOTE
Are there issues with internationalization when describing inline links?

EDITOR'S NOTE
Are there issues with pop-over content overlapping targets triggering failures?

---

OK, so here are some notes on where we differ.

The size of the target for pointer inputs is at least 44 by 44 CSS pixels except when:

WCAG suggests 44px as the threshold, but we (and Google at large) suggest 48px. I've reached out to internal peeps about why / possibly changing this

The target is available through an equivalent link or control on the same page that is at least 44 by 44 CSS pixels;

We don't do this... but we do something similar: we ignore overlapping elements if they are the same link.

code

The target is in a sentence or block of text;

Should be good here, but the comments suggest there are gaps in the implementation.

code

The size of the target is determined by the user agent and is not modified by the author;

(note: author here means website providing their own CSS. user can modify their browser UA to have smaller inputs and still comply)

We don't consider this at all.

A particular presentation of the target is essential to the information being conveyed.

Nothing we could do here.

Success Criterion 2.5.8 Target Size (Minimum)

This is most of the same above, except for a smaller (read: easier to meet) threshold. We could consider scaling the score accordingly based on making the 24px min but not the 44px min.

[paulirish]

Axe is working on a rule for target spacing here: dequelabs/axe-core#2652

ah. and 4 days ago a new PR just went up: feat(new-rule): Add WCAG 2.2 target-size rule by WilcoFiers · #3616 · dequelabs/axe-core

[adamraine]

We can use the axe target-size rule to add this advice to accessibility now.

impl: https://github.com/dequelabs/axe-core/blob/develop/lib/checks/mobile/target-size-evaluate.js

[adamraine]

Next action: Look at HTTPA for differences between our current tap-targets and the new target-size check from axe with the intention of upstreaming any issues we find to axe.

cc @jazyan

[icalrn]

WCAG suggests 44px as the threshold, but we (and Google at large) suggest 48px. I've reached out to internal peeps about why / possibly changing this

Sorry for jumping in, but has there been any new information about this?

Our team is struggling to decide whether to follow WCAG 2.2 SC 2.5.8 or Google's stricter tap target size recommendation for SEO. We're gravitating towards complying with WCAG since it's a formal, documented standard for web accessibility. We don't see any reason any search engine should penalize an interface that is deemed accessible by WCAG standard, but we would like to make sure whether doing so actually harms our SEO performance as the Lighthouse audit suggests.