Starting with Web Content Accessibility Guidelines (WCAG) 2.1 level AAA, the target size criterion is becoming more and more of a relevant to the web.
Right now, a minimum version of it is set in the recommendation candidate for WCAG 2.2 level AA.
Validating the AAA level is not necessary for XWiki since it’s not a specialized software, however we aim at validating the AA level. Even if this recommendation is not yet official, I think adding it to our code style now is important.
What is target size?
The size (height, width) of the target for pointer inputs.
Those can be links, buttons, dropdown, …
What are current recommendations?
A lot of recommendations exist (Apple, Microsoft, Google), with different units. However here I’ll only describe the WCAG ones mentionned above.
Minimum (AA): The target size is at least 24*24 CSS pixels.
High standard (AAA): The target size is at least 44*44 CSS pixels.
This can be a huge increase to accessibility AND usability. Using a button that’s too small can be difficult for:
users with motor issues
users with pointing devices different than a mouse, for example touchscreens
optical mouse users (imprecision of the device)
mouse users with the wrong dpi
Ever tried to click on a small button on a webpage when on the subway or in the back of a car?
Having too small of a target can be troublesome, even if in the end you still manage to click the right target. That’s what Fitt’s law describes. By making sure the target size is high enough, we can keep high throughput for any user action on the interface and effectively make the interface easier to navigate through.
Exceptions in the recommendations
These rules on target size are very simple, but you might have noticed that it’s not convenient or applicable to all cases. WCAG recommendations highlight these exceptions to the rule:
Inline: The target is inline, then its height is constrained by line-height.
Spacing: There is enough non targettable space around the target so that we could grow it the required size without overlapping any other target. The target can be smaller then.
Equivalent: Two targets have the same function, only one of them needs to have the required size.
User agent control: Target size determined by the user.
Essential: The target presentation is essential for the info being conveyed (up to interpretation…).
I also propose we add a couple skin variables to make following those recommendations easier:
@target-size-minimum = 24px
@target-size-required = 44px
Conclusion
What do you think of this proposal?
I’m not sure whether we should just include a link to the WCAG SC (as done above) or explicitely state the sizes and then include the link for more details.
I’m looking forward to your feedback and opinions on these matters!
Okay, so if this is approved I’ll add the section about the exceptions. I’ll also probably add a link to the WCAG definitions for more details because some of these exceptions can be tricky and what I wrote here is just an easy to understand summary.
Yup, forgot to link this PR, and the jira issue is a bit lost among Resources at the end
+1 to update our CSS best practices to use minimum 24px for any target size. Introducing @target-size-minimum = 24px makes sense.
Regarding the 44px target size, I don’t think we can apply this everywhere. It make sense for buttons but we have lots of targets that use just an icon (e.g. a font icon) where the 44px size might be too much (we would have to also increase the spacing, font-size, etc.). You can probably consider these icon targets as in-line (so excluded from the rule) but it’s not always the case. I can think of:
the caret for Bootstrap drop-downs
hamburger / kebab / more actions menu
expand tree node
open drop down tree in breadcrumbs
like page and add page tags
comment & attachment actions
pagination
in-place edit pencil
etc.
I feel that there are more exceptions than the cases where the rule applies, so I’d rather mention when we should use the 44px minimum target size than when we shouldn’t. I mean, instead of listing the exceptions, it may be simpler / clearer to list the cases where 44px target size make sense, e.g. for stand-alone buttons (that have a label).
Regarding the LESS variable name, I find @target-size-required confusing. If it’s “required” then why isn’t used for all targets and why is there a lower minimum allowed. You even used must for the 24px which implies a requirement, and should for 44px which implies a recommendation. Why not @target-size-recommended?
For carets (caret for Bootstrap drop-downs, open drop down tree in breadcrumbs, expand tree node), I agree, it’ll be some trouble even making them 24px so 44px is out of the question (at least for now). They are tied to a label that’s usually some text, and we don’t want to make the tree twice as large with a lot of empty space in the middle just for the sake of having 44px caret boxes. For some others, they are already almost the right size, and not strictly limited by anything for their size (hamburger / kebab /more actions menu, comment and attachment actions, in place edit pencil) so I think we should aim at fixing them eventually. 44px is not actually that big (see the picture below). The last kind are currently small (like page and add page tags, pagination), and keeping them at 24px might be better because we don’t want them to be too prominent. However I think we can have a discussion about them and in my eyes the ease of use increasing the size would bring outweighs the loss of focus on the “main” content.
I don’t see how to define “positively” (without relying on the exceptions) the elements this rule is applied on. And I think it’s a better idea to apply it “by-default” (everything is 44px but exceptions) instead of applying it “by-necessity” (everything is whatever, and I check if it’s in the domain of this rule) in new pieces of UI. It’d be easier this way rather than having to “patch” UIs at the end to take accessibility into account. This point’s stakes are similar to the ones of shift left testing.
About the example you gave, I don’t agree with it since this rule is especially important for groups of buttons. It’s way more difficult to click one button in a group (one wrong click would bring me somewhere else) rather than by itself. Standalone buttons can fall under the exception “spacing” because they are not next to other pointer elements.
In fact, exceptions are so wide in their definitions that they could cover a very large range of pointer targets. In the end it comes down to the goodwill of the developers in a lot of cases. And even with goodwill, it can be easy to skip a recommendation/rule if we don’t start with the idea in mind and it creates problems once everything else is done.
+1, this name was awkward and I like @target-size-recommended better too
The size of the target for pointer inputs must be at least 24 by 24 CSS pixels, see exceptions below.
The size of the target for pointer inputs should be at least 44 by 44 CSS pixels, see exceptions below.
Exceptions:
The target is inline, then its height is constrained by line-height.
There is enough non interactive space around the target so that we could grow it the required size without overlapping any other target. The target itself can be smaller in this case.
Two targets have the same function, only one of them needs to have the required size.
Target size is determined by the user.
The target presentation is essential for the information being conveyed (up to interpretation…).
