• Resolved mickhele

    (@mickhele)


    I receive this issue about the WCAG validation:
    “This element with a role of “tooltip” does not have an accessible name”

    This the explanation of the Stark validator tool:

    The div element with role="tooltip" lacks an accessible name, preventing screen readers from identifying its purpose. This violates accessibility guidelines.Solution

    Provide an accessible name to the tooltip element using either aria-labelledby or aria-describedby.

    Using aria-labelledby (if the tooltip’s content is a concise label):

    <button id="myButton">Hover Me</button>
    <div role="tooltip" class="anww-tooltip" style="position: absolute; background: white; color: rgb(30, 30, 30); font-size: 16px; border: 1px solid black; padding: 5px 10px; z-index: 9999; display: none; pointer-events: auto; box-shadow: rgba(0, 0, 0, 0.1) 0px 4px 6px; max-width: 200px; white-space: nowrap;" aria-labelledby="myButton">
    This is a tooltip!
    </div>

    Using aria-describedby (if the tooltip provides additional information):

    <button id="myButton">Hover Me</button>
    <div role="tooltip" class="anww-tooltip" style="position: absolute; background: white; color: rgb(30, 30, 30); font-size: 16px; border: 1px solid black; padding: 5px 10px; z-index: 9999; display: none; pointer-events: auto; box-shadow: rgba(0, 0, 0, 0.1) 0px 4px 6px; max-width: 200px; white-space: nowrap;" aria-describedby="myButton">
    This is a tooltip with extra info!
    </div>
    • aria-labelledby: The tooltip labels the element.
    • aria-describedby: The tooltip describes the element, providing additional context.

    Alternatively, add aria-label for a self-contained tooltip.

    <div role="tooltip" aria-label="This is a tooltip" class="anww-tooltip" style="position: absolute; background: white; color: rgb(30, 30, 30); font-size: 16px; border: 1px solid black; padding: 5px 10px; z-index: 9999; display: none; pointer-events: auto; box-shadow: rgba(0, 0, 0, 0.1) 0px 4px 6px; max-width: 200px; white-space: nowrap;">This is a tooltip!</div>
Viewing 8 replies - 1 through 8 (of 8 total)
  • Thread Starter mickhele

    (@mickhele)

    This is the fix that I used waiting an update for the plugin:

    <script>
    (function () {
    'use strict';

    var TIP_ID = 'anww-tip';
    var DEFAULT_TEXT = 'apre una nuova finestra';
    var wired = false;
    var tipObserver = null;

    function isElement(node) {
    return node && node.nodeType === 1 && typeof node.matches === 'function';
    }

    function patchTip(tip) {
    if (!tip) return;
    if (!tip.id) tip.id = TIP_ID;

    var txt = (tip.textContent || '').trim() || DEFAULT_TEXT;
    tip.setAttribute('aria-label', txt);

    var a = document.activeElement;
    if (isElement(a) && a.tagName === 'A' && a.target === '_blank') {
    a.setAttribute('aria-haspopup', 'true');
    a.setAttribute('aria-describedby', TIP_ID);
    }
    }

    function wireTip(tip) {
    if (!tip) return;
    patchTip(tip);

    if (tipObserver) tipObserver.disconnect();
    tipObserver = new MutationObserver(function () {
    requestAnimationFrame(function () { patchTip(tip); });
    });
    tipObserver.observe(tip, { childList: true, characterData: true, subtree: true });
    }

    function hookOnce() {
    if (wired) return;
    var tip = document.querySelector('div.anww-tooltip[role="tooltip"]');
    if (!tip) return;

    wired = true;
    wireTip(tip);

    ['focusin', 'mouseenter'].forEach(function (evt) {
    document.addEventListener(evt, function (e) {
    if (isElement(e.target) && e.target.matches('a[target="_blank"]')) {
    patchTip(tip);
    }
    }, true);
    });

    ['focusout', 'mouseleave'].forEach(function (evt) {
    document.addEventListener(evt, function (e) {
    if (isElement(e.target) && e.target.matches('a[target="_blank"]') &&
    e.target.getAttribute('aria-describedby') === TIP_ID) {
    e.target.removeAttribute('aria-describedby');
    }
    }, true);
    });
    }

    document.addEventListener('DOMContentLoaded', hookOnce);

    var bodyObserver = new MutationObserver(function () {
    var tip = document.querySelector('div.anww-tooltip[role="tooltip"]');
    if (tip) {
    bodyObserver.disconnect();
    hookOnce();
    }
    });
    bodyObserver.observe(document.body, { childList: true, subtree: true });
    })();
    </script>
    Plugin Support williampatton

    (@williampatton)

    Hey @mickhele,

    Thanks for pointing this out and flagging it for our attention. I will take a look into this today and try to get a solution in the plugin.

    It is a little nuanced because the MDN says this about role=”tooltip” which seems to suggest that if an accessible name is added (such as via an aria-label) then the label only will be read and the contents of the tolltip won’t. Which if setting the lable to the same as the content will be fine but otherwise would hide the contents.

    The accessible name of a tooltip can come from the contents. While, in theory, they could come from an aria-label or aria-labelledby, in most cases, using ARIA properties to provide a tooltip with an accessible name is not recommended.

    Tooltips provide additional information, generally with no direct interaction on the tooltip itself. They are generally associated with the content they’re defining via an aria-describedby with the id of the primary element. Therefore, if the tooltip has an accessible name explicitly set, that name is exposed as the primary element’s description rather than the contents of the tooltip, meaning the tooltip contents may never be discovered by a screen reader user.

    MDN https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Reference/Roles/tooltip_role

    I’ll figure out the best option here and get it into the plugin as soon as I can. Again thanks for flagging it for me to look into and resolve. Using describedby may be the best option here but still wanting to do more research and confirm.

    Plugin Contributor Amber Hinds

    (@alh0319)

    Hi @mickhele,

    I want to chime in here that what you’re seeing in Stark is a false positive. First of all, the accessible name on the tooltip div comes from its text content, which is “opens a new window”.

    If what Stark is flagging is that it thinks the the visual tooltip text is not connected with the element and thus is not being announced, that is also incorrect. The tooltip text is already being read out to screen reader users because we have added it to the aria-label.

    Our plugin adds an aria label to the link that includes the text that is shown in the tooltip already. Here’s an example:

    Screenshot of the following link (available in a code block) being inspected in browser dev tools.
    <a href="https://make.wordpress.org/accessibility" target="_blank" rel="noreferrer noopener" aria-label="Accessibility in WordPress, opens a new window" data-nww-processed="true">Accessibility in WordPress<i class="anww-external-link-icon" aria-hidden="true"></i></a>

    When a screen reader encounters this link, they will hear “Link. Accessibility in WordPress, opens a new window”.

    If you use aria-labelledby on the link to reference the tooltip, you will lose the actual text of the link as this will override the aria-label on the link.

    If you use aria-describedby on the link referencing the tooltip, you will get duplicate announcements. Users will hear “Link. Accessibility in WordPress, opens a new window opens a new window”. Here is a video showing the duplicate announcements.

    Automated testing tools are great, but not all recommendations that they provide are correct. In this case this is a false postive you should just ignore in your testing tool.

    Thread Starter mickhele

    (@mickhele)

    Thank you Amber for your clarification.

    Unfortunately, the accessibility market is currently quite confusing (at least from my perspective); I have not come across any analysis tool (excluding overlay widgets from the start, which I do not even consider) that offers a clear and accurate overview of a website’s accessibility level. Not even ‘axe DevTools’, which is the most recognised by experts in the field.

    I realise that achieving accessibility primarily requires direct/manual intervention, but at the very least, having an accurate list of issues would be the minimum expectation. It’s like buying car insurance without being sure you are actually insured.

    Making a website accessible in a schematic way is one thing, but working on a website styled like Apple’s is an entirely different matter.

    In any case, thank you for reporting this false positive. It will remove Stark from the monitoring tools due to its unreliability.

    Hey everyone, just wanted to reply that I think what’s happening here is that the tooltip is initially rendering as empty (no text content). Once hovering on the element, the tooltip does populate with text content (“opens in a new window”). So if you ran the scan before hovering on the element, it does correctly point out that the tooltip is without an accessible name.

    Plugin Contributor Amber Hinds

    (@alh0319)

    Some number of false positives or items that require human review and assessment are expected in any tool. There’s a fair bit of layered assessment of HTML, ARIA, and website functionality that automation is just not capable of yet.

    If you’re looking for a different testing solution for WordPress, you might try our Accessibility Checker plugin. As far as guidance on learning the nuance of accessibility testing, the WordPress Accessibility Meetup may be helpful to you.

    Have a good day!

    Thread Starter mickhele

    (@mickhele)

    Okay, but I suggest you apply a fix like the one I provided earlier to make the plugin ‘false positive’ proof.
    In any case, thank you, @alh0319, for the information and the invitation to the meetups, which I will definitely attend in the future, given that website accessibility is becoming increasingly important in my work.

    Plugin Support williampatton

    (@williampatton)

    Hi there,

    I just wanted to note here for posterity that I created an internal card on our development board for this plugin about the issue with the tooltip starting out with empty content and only being filled when it’s first viewed.

    I don’t have any ETA on when a fix will be released but it’s being tracked and will get looked at and worked on in due time.

    Thanks for pointing that out.

Viewing 8 replies - 1 through 8 (of 8 total)

You must be logged in to reply to this topic.