The 2026 Drupal Business Survey is open. Your response will help shape the future of the Drupal business ecosystem.A discussion at today's weekly meeting pointed out how we should address accessibility review for the code we're doing for Claro. Since a full a11y sign-off will be needed for merging into Drupal core and after discussing with @andrewmacpherson the more reasonable steps are:
For individual PRs in Claro:
- If there's an issue which has a11y notes, use our own discretion. If we feel they are all addressed, document what we have done, and go for the merge.
- If any component has never had a11y discussion to date, let's find those and fill in the review gaps. Tag them "needs accessibility review" and ping the #a11y channel in Slack.
- For more complex components (e.g. compound fields, anything with invisible labels, or components with custom JS), tread more cautiously and ask for a review. This also applies if bringing in 3rd-party JS libs which we don't already use in core. Tag them "needs accessibility review" and ping the #a11y channel in Slack.
| Comment | File | Size | Author |
|---|---|---|---|
| #11 | button-sizes.png | 23.96 KB | ckrina |
Comments
Comment #2
andrewmacpherson commentedYes, just confirming that was the private discussion we had on Slack. Good to have this recorded, so I can't complain about this later :-)
Comment #3
andrewmacpherson commented"accessibility" is the preferred tag. We're trying to avoid "a11y" as a lot of people don't understand the numeronym, and we don't want two lists to review.
Comment #4
andrewmacpherson commentedAdded a bit more about the "more complex components".
If merging something on your own discretion, please add some notes about how/what was done to address a11y.
Comment #5
modulist commentedWCAG 2.1 AAA specifies a minimum size of 44 x 44px for target areas. AAA goes beyond the legal minimum for compliance. If that size is not feasible, then I would recommend that we set a minimum of 36 x 36px for the admin UI, if not 24 x 24px.
Material Design sets their icons inside of a 24 x 24px square by default. See https://material.io/design/iconography/system-icons.html#grid-keyline-sh...
Comment #6
modulist commentedThe outline color for the focus and hover states are too close to the primary button color to be easily visible. I would recommend using something close Drupal's lime green (#7cbc48) as the outline color for the primary color.
Comment #7
saschaeggi@modulist thanks for the feedback. We'll have a look into it. Do icons which are just decoration also need to be > 24px?
Comment #8
andrewmacpherson commented@saschaeggi - by "an icon which is just decoration", you mean the icons which accompany a visible text label, in our current toolbar?
Note that the WCAG Target Size success criterion isn't about the size of the icon itself, but the size of the operable control as a whole. We'd need to assess those in context of the page as a whole. A 24px icon inside a button which had padding and borders adding up to 44px would satisfy WCAG Target Size. In the example I gave of icons in our current toolbar module design, the size of the icon doesn't matter, it's the height of the toolbar that matters. Currently it's 39px, which doesn't pass. The buttons from the contextual links module don't pass either.
This is at AAA, beyond our target of AA, so it can be triaged as nice-to-have. It's really just a formalization of an existing practice in mobile design. WCAG Target size has an exemption for targets that are inside of sentences, as that would disrupt the line height. So a help icon link at the end of a form description would be exempt.
Aside: why do we need four sizes of drop-down arrow? That seems a bit excessive, but it would be useful to know the intended context they will appear in.
Comment #9
andrewmacpherson commented#6 - the palette in [33017785] doesn't have a lime green - Claro isn't intended to match the Bluecheese theme of drupal.org afaik.
I agree the blue focus outline around a blue button is hard to see. It's too similar to Chrome's crappy user-agent style. I don't think we'll really solve the focus style with colour though. An offset outline would be clearer, but will need a polyfill for IE11 (and maybe Edge?)
The problem with a focus indicator that butts directly against the button, is it needs to be distinguishable from both the button itself, and the page background. An offset focus outline only needs to have contrast against the page background. I have a demo page to show outline-offset focus styles, try tabbing through all the controls there.
Comment #10
ckrinaI just posted a proposal for buttons in the buttons issue so we can discuss it there: https://www.drupal.org/project/claro/issues/3021087#comment-12931235
Comment #11
ckrinaAbout icons: so far the specification in Figma is just for the designs to create/export svgs and to design new icons. We'll take that into account when we define the proper style guide and we'll definitely add this WCAG info. Thanks!
About dropdowns, we have 3 sizes: normal, small, extra small. The normal is the one we can find in the save button on a node edit form. The other ones are the ones placed, for example, inside tables where we try to reduce its space&importance/priority.
Comment #12
modulist commentedIn Figma, the best way to create transparent icons with the correct target areas is to create 24px x 24px frames with no background, and often I will create all the states in various frames layered inside of a parent frame.
Comment #13
huzookaComment #19
finnsky commentedSeems it is related
https://www.drupal.org/project/drupal/issues/3293469#comment-14623171
Comment #21
mgiffordTagging for 2.5.5
Comment #24
quietone commentedReading the issue summary I think this can be closed now. Claro was added to core and there are numerous issues tagged 'Accessibility'.
Therefore closing this as fixed. If that is wrong I trust someone will re-open this.