Buttons are smaller than the minimum target size

[karlgroves]

Buttons are smaller than the minimum target size

• Severity: Low
• Affected Populations:
  • Low-Vision
  • Motor Impaired
• Platform(s):
  • All / Universal
• Components affected:
  • Global

Issue description

Many of the buttons in the site are smaller than the recommended 44px by 44px. This is the case for all buttons in the components tested where no minimum size has been specified.

All actionable elements (apart from inline links and native widgets) should have a minimum size of 44px square, because smaller targets may be difficult for users who have a motor impairment and can't use a pointer accurately. Small targets are also more difficult for users on touch devices, since fingers are not very accurate pointers.

Issue Code

    /* example: toolbar button */

    .components-icon-button {

        ...

        padding: 8px;

        margin: 0;

        ...

    }

    /* example: Publish button */

    .edit-post-header .components-button.editor-post-publish-panel__toggle, ... {

        margin: 2px;

        height: 33px;

        line-height: 32px;

        font-size: 13px;

    }

    .edit-post-header .components-button.editor-post-publish-panel__toggle {

        padding: 0 12px 2px;

    }

Remediation Guidance

Increase the size of the targets. Most are already around ~35px in size, so techniques such as increasing their vertical padding or simply setting a minimum height (as shown in the Recommended Code) will allow controls to meet their minimum target sizes.

Recommended Code

    /* example: toolbar button */

    .components-icon-button {

        ...

        min-height: 44px

        ...

    }

    /* example: Publish button */

    .edit-post-header .components-button.editor-post-publish-panel__toggle {

        min-height: 44px;

    }

    /* AM, PM buttons */

    .components-button.is-button {

        padding: 0 10px 1px;

    }

    /* Move back/ front to month buttons*/

    .components-datetime__date .DayPickerNavigation_button__horizontalDefault {

        padding: 2px 8px;

        top: 20px;

    }

Relevant standards

• 2.5.5 Target Size (Level AAA)

Note: This issue may be a duplicate with other existing accessibility-related bugs in this project. This issue comes from the Gutenberg accessibility audit, performed by Tenon and funded by WP Campus. This issue is GUT-5 in Tenon's report

[afercia]

Worth noting WordPress aims to be compliant with level AA. Target size is level AAA. Not saying it's not important though 🙂

[kjellr]

We discussed this in today's #design triage. (A WordPress.org slack login may be necessary to view this link).

In general, we totally agreed that there are some too-small buttons. 😄 We'd love to see those get bigger, and would welcome some exploration. Some of those (like the AM/PM buttons) are used in a tiny space, so we'll need to see how it effects everything else in the area. I believe some of these also use standard core button sizes (like the Publish button for instance). So those would need to be addressed globally.

[melchoyce]

Screenshots from full report:

[davewhitley]

@afercia Just making sure — there's not a AA guideline for target size, is that correct?

[afercia]

@davemart-in the 44 by 44 pixel target size is a WCAG 2.1 level AAA success criterion https://www.w3.org/TR/WCAG21/#target-size

In the first drafts of WCAG 2.1 it was level AA, then moved to AAA in the final recommendation 🤷🏻‍♂️

WordPress aims for a level AA. That said, it would be great to explore bigger buttons anyways 🙂 see previous comments.

See also conversations on the ongoing core CSS admin changes related to buttons and heights where a very good point was made to explore grid based sizes: https://core.trac.wordpress.org/ticket/34904#comment:94 (and following comments)

For the other form controls heights, see: https://core.trac.wordpress.org/ticket/47477

[enriquesanchez]

This issue was discussed during the Design team's Gutenberg triage meeting (requires registration).

We noted that the recent updates to Gutenberg's design (G2) have made progress here. Most of the block toolbar buttons are now 48px by 48px. There are still some buttons, such as the ones on the editor toolbar, that are still below the 44px guideline.

Pinging @jasmussen and @pablohoneyhoney to see if there's been any thought about increasing the target size of the remaining buttons.

[pablohoneyhoney]

Thanks for the ping @enriquesanchez

The new iterations of the top bar have a 60 height, with buttons and icons on 36.

[enriquesanchez]

The new iterations of the top bar have a 60 height, with buttons and icons on 36.

Thanks @pablohoneyhoney! Any plans on making the button's target size bigger? Maybe match the block toolbar's 48px by 48px?

[jasmussen]

The bigger the button, the easier it is to hit, that's a good classic design principle that matters even if we don't have to achieve AAA recommendation of 44px minimum. This was also a driving principle of the block toolbar, which benefits greatly. I'd love to have the design handbook revisited to just note that as a best practice.

Any plans on making the button's target size bigger? Maybe match the block toolbar's 48px by 48px?

Not visually — it's important to balance the visual weight of the buttons also. But we could explore making the tappable hit-area bigger, this is what is done to buttons in the block toolbar, and I've noted that in https://github.com/WordPress/gutenberg/issues/20575#issuecomment-610795160

[paaljoachim]

I brought up this issue during a Gutenberg Design Triage. I feel that @jasmussen comment addresses the concern.

Is there anything else we need to address here?

[folletto]

I feel it would be worth creating a new issue that is the exploration Joen mentions, and close this more broad discussion which is also harder to follow.

Otherwise “we could explore making the tappable hit-area bigger” will have no follow-up.

[afercia]

This issue is part of the WPCampus accessibility audit on Gutenberg. I'd kindly ask you to not close it and instead reference it in the new issue, pending explorations. As accessibility team, we would like to track all the WPCampus issues so that they should be closed only when the underlying problem is "solved", in a way or another.

[paaljoachim]

What is the next actionable step?

It would be great with a status update on this issue. Thanks!