Improve accessibility

Somehow this got overlooked from 1.x->2x->3.0.0.

Testing to see if this change can be made in https://git.drupalcode.org/project/glossify/-/blob/3.x/templates/glossif...

The link example in https://dequeuniversity.com/library/aria/tooltip looks like it would be easy to implement in https://git.drupalcode.org/project/glossify/-/blob/3.x/templates/glossif...

The use of a tooltip role in https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Roles/to... looked promising, but then https://sarahmhigley.com/writing/tooltips-in-wcag-21/ says "While it's not a bad idea to add it to the tooltip element, it doesn't seem to do much good either. The tooltip role does not appear to affect screen reader announcements in any meaningful way".

At this point, I'm not sure what the right way to fix this is, but I'm also noticing that the tool-tip only link doesn't work in mobile. Clicking on the underlined term just selects it.

Thank you very much for the implementation, folks!

Now I'm wondering if we should really solve that on our own or better use a more accessibiliy friendly tooltip library? What do you think and is one out there?

Would this improve the situation maybe? ✨ Support tippy.js by submodule Active

I started a fork where I was creating a custom implementation, but I had to step away before fully completing it. Between then and now, my thinking has evolved and I agree it makes probably makes more sense to leverage an existing library.

When I was previously working on this for a government client, we ended up using the USWDS tooltip component within our styleguide to meet WCAG 2.2 criteria. It was pretty straightforward to add the necessary class to the `glossify-tooltip` twig template and have it work as expected:

{#
/**
 * @file
 * Markup for inline tooltips.
 *
 * Available variables:
 * - word: the text where the tooltips applies to.
 * - tip: the tooltip text.
 * - tip_raw: the tooltip text in its raw format.
 * - langcode: the tooltip language code.
 *
 * @ingroup themeable
 * @see src/07-utility/_glossify.scss
 */
#}
<span tabindex="0" {% if tip %} title="{{ tip }}" {% endif %} class="glossify-tooltip-tip usa-tooltip" data-position="top" {% if langcode %} lang="{{ langcode }}" {% endif %}>{{ word }}</span>

But I'm not sure how easily the one component can be pulled in separate from the full USWDS library, which would be a lot for a contrib module.

I haven't used the tippy.js library before, but do we know how it reads with VoiceOver? When we were testing the USWDS component in conjunction with the tooltip component, we went through a LOT of iteration to make it useful to a screenreader user.

On a separate note, another thing we ended up creating (which I'm hoping to recontrib back here) is a custom block that gathers up all the Glossified terms on a page and added them to a "Glossary" block at the bottom of the page. This is another technique that WCAG indicates improves accessibility, so maybe between that and the updated tooltip implementation, that should go a long way to improve the accessibility.

Thanks @inregards2pluto!

Feel free to create a MR with the changes proposed!
Regarding tippy.js / floating-ui it would be great if these libraries could be checked for accessibility, as they are very widely used, with huge impact. I'm not sure which one is enough for our needs and it seems tippy.js is built on top?

Regarding the block: This should be a submodule then. Feel free to also provide a MR for that.

Let me update my branch to use the tippy.js library and I'll do some testing. I'll report back in a bit :)

Please mind ✨ Support tippy.js by submodule Active . Separate approaches in separate branches are also fine!

Chiming in, as an accessibility check of one site showed that glossified links should have an "aria-label attribute set that shows the purpose of the link", so something like "Glossary definition for " I guess.
This string should be customizable and translatable, as implementations might differ. Some might call it glossary, some dictionary, other lexicon, etc.