Continuing our series of articles on how to test the new Success Criteria (SC) in WCAG 2.2.
Detailed conformance and testing information can also be found in KnowledgeBase, a digital accessibility repository available through TPGi’s ARC Platform. KnowledgeBase is maintained and consistently updated by our experts, and can be accessed by anyone with an ARC Essentials or Enterprise tier subscription. Contact us to learn more about KnowledgeBase or the ARC Platform.
Success Criterion 2.5.8 Target Size (Minimum) is about ensuring that interactive targets can be easily activated by pointer users, without accidentally hitting an adjacent target. When targets are small and close together, some users may find it very difficult to accurately hit the intended one.
This benefits pointer users who have limited mobility, such as hand tremors or quadriplegia. It also allows for the relative imprecision of virtual pointing devices and touchscreens, and may be helpful for some users with low vision.
Normative requirements
The size of the target for pointer inputs is at least 24 by 24 CSS pixels, except where:
- Spacing: Undersized targets (those less than 24 by 24 CSS pixels) are positioned so that if a 24 CSS pixel diameter circle is centered on the bounding box of each, the circles do not intersect another target or the circle for another undersized target;
- Equivalent: The function can be achieved through a different control on the same page that meets this criterion;
- Inline: The target is in a sentence or its size is otherwise constrained by the line-height of non-target 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 or is legally required for the information being conveyed.
This applies to all interactive elements that are implemented or modified by the author. It doesn’t apply to unmodified native controls like radios and checkboxes. However any author CSS that affects their target size, such as width or padding, would then bring them under the requirements of this SC, since they’re no longer not modified
. The same is true for all custom widgets or progressively-enhanced native widgets.
The exception for inline elements (constrained by the line-height of non-target text
) primarily refers to text links within a paragraph or list, where the link can’t be taller without disrupting the overall line spacing. Text content is harder to visually track if the lines are unevenly spaced, particularly for some users with cognitive or reading difficulties. However the exception doesn’t universally apply to all text links, only to those which actually are constrained in this way. That may be a judgment call, depending on the layout.
Page zoom is not a factor in target size. CSS pixels don’t change with zoom level, so an element that’s 16 by 16 at 100% zoom, is still 16 by 16 at 400% zoom. There’s no loophole for targets that could be larger if the user zooms.
The pointer-target size is not necessarily the same as the visible size. For example, a graphical button with a visible icon that’s 16 by 16, but has 4px padding on every side, adds up to a target size of 24 by 24. Composite widgets like sliders, which have an interactive thumb inside a larger track, should be considered a single target (i.e., the whole slider, not just the thumb).
The same applies to form controls that are inside their associated <label>, where the whole thing should be treated a single target. However in cases where they’re separate, an interesting anomaly can arise over whether they count as equivalent to each other. For example, when a label is associated with a radio control, clicking the label performs the same function as clicking the radio, so a sufficiently large label area would allow the radio itself to pass, even if it would otherwise fail. Conversely, controls such as sliders and drop-downs have additional interactivity, for which the label is not an equivalent.
Practical ambiguities
The name of this SC — Target Size (Minimum)
— is slightly confounding, because it’s not really about target size, it’s about target spacing. The minimum target size is simply a zero-spacing benchmark, which allows for targets to have no spacing if they’re sufficiently large.
In cases where targets are small, target spacing reduces the possibility of hitting the wrong one (which is the intent of this SC), even if it doesn’t reduce the possibility of not hitting the right one.
The basic principle remains the same — that interactive targets should be easy to discretely activate — but there has to be pragmatism for cases where design or functionality requires small targets, and that flexibility is provided by the SC’s target spacing exception.
So it’s a little bit cart before the horse, but it feels more visceral this way, and more significantly, it’s consistent with SC 2.5.5: Target Size (Enhanced).
However the target spacing exception also gives rise to a known loophole, since it allows for targets to be incredibly small, or even to have no size at all. This can’t be practically eliminated, because defining a smaller minimum size for that situation, would effectively reduce the minimum size for all situations. In other words, if the spacing exception defined its own minimum size, say 12 by 12 when it applies, then that 12px value would become the de-facto minimum target size.
Testing barriers
Testing for this SC benefits from the ability to make visual and spatial comparisons. This is not a hard barrier, but it’s not a particularly soft one either.
You could, in theory, do all the evaluations in your head, using data from the DOM inspector. The cognitive load this implies would be quite high, so it wouldn’t be easy, but it is theoretically possible.
More practically speaking then, this SC is not readily testable by auditors who have a vision impairment, or a cognitive impairment that affects spatial reasoning or mathematical abstraction.
Automated testing
This SC can be partly tested by automation:
- Targets which pass because they have sufficient size or spacing, determined by evaluating layout properties like width, height, and viewport coordinates.
- Targets which pass because they’re unmodified native widgets, determined by comparing a list of known widgets with information about their author CSS.
However manual checks would still be required:
- Equivalent controls and essential exceptions are human judgment calls.
- Evaluating the inline exception is not actually possible for automation, because it can’t determine whether the height of a target is constrained by its containing line-height. The computed value of
line-heightis not necessarily a number, it might be"normal", which isn’t useful here. And although you could measure and compare the rendered height of both elements, it wouldn’t prove that one constrains the other, simply because they’re the same. - Some interactive targets might not be identifiable, such as elements that are functional widgets but don’t have recognized markup like
roleortabindexattributes. Such elements would fail other SCs, but would also preclude automated testing of this one.
Manual testing
Manual testing can be performed in the following steps:
- Identify the presence of interactive targets on the page.
- Ignore those where (either):
- another control on the same page performs an equivalent function (and that control itself passes this SC);
- the target is constrained by the line-height of non-target text;
- the target is a browser or system widget that hasn’t been author sized;
- the small size is essential (e.g., games that test pointer precision).
- For remaining targets, verify that it has a pointer-target size of at least 24 by 24 CSS pixels.
- For remaining targets that are smaller than 24 by 24, and are not otherwise excepted, verify that the spacing is sufficient:
- create or abstract a visual representation of all such targets, where each has a 24px diameter circle centered over the target (target size bookmarklet may be helpful here);
- visually verify that none of the circles overlap each other;
- visually verify that none of the circles overlap any other target (whether or not that other target otherwise passes).
Yielding one of three expected results:
- Pass: All interactive elements meet the minimum size or spacing requirements, or an exception applies to those which don’t.
- Fail: Some interactive elements do not meet the minimum size or spacing requirements, and no exceptions apply.
- Not Applicable: There are no interactive elements.
