Tooltips in Webform use a <span> element with role="tooltip" and tabindex="0", which is keyboard-focusable but not an interactive element.
When using Tippy.js with interactive: true, the library automatically adds aria-expanded to the trigger.
This causes an accessibility violation because aria-expanded is not valid on non-interactive elements like a <span> with role="tooltip".
This issue is flagged by accessibility tools such as Siteimprove.
ARIA attribute unsupported or prohibited
aria-expanded on spanWhy is this an issue?
An ARIA attribute has been specified that is either not supported or is prohibited, on this type of element.
ARIA attributes provide information about the behavior of interactive elements. For example, they can be used to tell screen-reader users whether a checkbox is checked
aria-checked=trueor uncheckedaria-checked=false.Unsupported ARIA attributes will not deliver the intended user experience and may even break the usability of your site.
WCAG 2.2: Understanding Success Criterion 4.1.2: Name, Role, Value
WCAG 2.2: Technique ARIA5: Using WAI-ARIA state and property attributes to expose the state of a user interface component
Siteimprove Alfa: Technical documentation for rule SIA-R18How to fix this issue:
Use supported states and properties only.
AND
Use non-prohibited states and properties only.
<span> with role="tooltip" is rendered as the help icon.aria-expanded="false" to that element.aria-expanded on the <span> as an invalid ARIA attribute.
Explicitly disable the automatic addition of aria-expanded in the Tippy.js configuration by setting:
aria: { expanded: null }
This prevents Tippy.js from injecting the aria-expanded attribute, resolving the accessibility violation while still allowing tooltips to be triggered from a <span>.
Alternative approach 1: Replace the <span> element with a <button> element to improve semantic accessibility. A <button> is a natively interactive element and is compatible with attributes like aria-expanded, making it a better choice when tooltips are triggered via focus or click.
Alternative approach 2: Add role="button" to the <span> element to ensure the aria-expanded attribute can be used within a permitted context. We must also manually implement additional keyboard accessibility features to bring it inline with proper <button> tag standards. This includes things like adding a tabindex="0" and handling Enter/Space key events) so it behaves like a native button.
webform.element.help.js.None. Tooltip behavior remains unchanged visually.
None.
None.
| Comment | File | Size | Author |
|---|---|---|---|
| webform-prevent-aria-expanded-on-tooltip-span-0.patch | 480 bytes | marthinal |
Show commandsStart within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
changes
Comments
Comment #2
jwilson3Comment #3
jrockowitz commentedI am not sure this is resolvable. Changing the tooltip's HTML tag will cause visual regression on the sites targeting the SPAN tags. You might have to use the patch AS-IS.
Comment #4
jwilson3My understanding is that the patch specifically does not change the tag. (Changing the tag to a
<button>was proposed as the "proper" alternate solution, but the approach in the patch as currently written does not change the tag, just removes the inappropriate aria-expanded.Comment #7
jrockowitz commentedThe patch removes the expanded attribute which I think improves the accessiblity for screen readers.
Even though a machine/automated review says the tag + attributes is invalid, it does not mean we should remove the attribute to pass an automated test.
Comment #8
jwilson3This is true, but the ARIA5 rules say that to be able to use the
aria-attributes, you have to have an element with the correct role. By default,<span>has no semantic meaning—it's effectivelyrole="presentation"orrole="none"in ARIA terms unless styled or scripted to behave otherwise. In this caserole="tooltip"is applied, but that doesnt supportaria-expanded.aria-expandedis only valid on elements that can be expanded or collapsed, like menus, dropdowns, trees, accordions, etc.A tooltip is not something that expands or collapses on its own—it's shown/hidden based on hover/focus or JS logic. So
aria-expandedhas no semantic meaning in this context and will be ignored by assistive tech.If keeping
aria-expandedis the goal, then ideally we'd switch to a<button>, but as previously stated, that could break themes that (incorrectly) target the<span>directly instead of using a class. It would also likely change the expected behavior in that the user would need to make a click action to make the tooltip apppear/disappear. Changing the tag—and potentially breaking CSS— and changing the behavior would probably be considered an API change requiring a major version bump.Therefore, to resolve the issue, switch to a button-like click behavior, but keep screen readers and machines happy, and avoid a major bump, we could add role="button" to the
<span>and ensure it behaves like a native button, including being focusable (tabindex="0") and keyboard-interactive (handling Enter/Space key events to open/close the tooltip). We can then create a follow-up to remove all the extra code and convert it to a<button>in Webform version 7.Alternatively, I suggest keeping the existing tooltip behavior (i.e. appear on hover/focus) but properly following the ARIA Tooltip pattern or the toggletip pattern from inclusive-components.design, neither of which make use of the aria-expanded attribute.
References:
WCAG 2.2: Technique ARIA5: Using WAI-ARIA state and property attributes to expose the state of a user interface component
W3C ARIA Authoring Practice Guide: Tooltip Pattern
Comment #9
jrockowitz commentedSince this was researched and the conclusion was to remove the aria-expanded, I think we should commit this patch AS-IS.
Comment #12
jrockowitz commentedComment #14
jwilson3Thank you Jacob! 🙏