Forum Discussion
Text hyperlink states not applying to some hyperlinks
Normally, I would just use a separate text box or a hidden shape on top for my hyperlinks, but as this module needs to comply with WCAG 2.2 AA, the text needs to be reflowable. When Accessible Text is enabled, the line-spacing is adjusted, so any additional shapes or textboxes would lose alignment.
Regarding the textlib-wrapper class, I believe this is used for textboxes when Accessible Text is enabled. Without Accessible Text enabled, the hyperlink states work fine. Seems that enabling Accessible Text, which converts all the text to 'accessible versions', is ironically making the text fail WCAG accessibility by removing some of the hyperlink states.
I see what you're referring to—I should have paid closer attention to your original post. When "Accessible Text" is enabled, only one or a few links work as expected, showing the hover state, while others do not. Unfortunately, there's no simple solution to this at the moment. This is something Articulate should address in a future update.
That said, I do have a workaround that involves JavaScript. The solution uses a "MutationObserver" to detect when "Accessible Text" is enabled (i.e., when Storyline enforces the "textlib" classes) and dynamically assigns the classes on the anchor (<a>) elements. The tricky part is to copy a class of anchor element that works and when "textlib" is available remove current class of all anchor elements and assign the working one. Switching "Accessibility Text" on and off will not break this functionality. While it's not ideal, it can help fix the issue in the meantime.
Nedim - can you please share your JavaScript solution in more detail here? Thank you.
Here we go, Kevin. Explanation is below - the script is in the attached .story file.
Explanation of the Script and How It WorksThe goal of this script is to dynamically target all <a> (anchor) elements when the Accessible Text option is activated on a slide. When this option is enabled, all anchor elements are automatically nested inside a div with the class .textlib-content-wrap, and each link is given a unique class.
To manage this behavior, I used the MutationObserver API — a browser feature that allows us to monitor changes in the DOM (Document Object Model). In this case, we’re specifically watching for the addition of anchor elements to the page.
How It Works?- Observation Setup:
The script selects all <a> tags inside elements with the class .textlib-content-wrap using document.querySelectorAll. It then loops through each of these links and sets up an IntersectionObserver to track when they come into view. - Visibility Handling:
When a link becomes at least 50% visible in the viewport, the handleVisibility function is triggered. This function removes all existing classes from the link and replaces them with a single, specific class (e.g., e9072a95-554e-45d0-8eda-3e63825a27ae). This class is typically copied from a working link to ensure proper styling or behavior (like hover effects) is preserved. - Why This Class Replacement?
After enabling Accessible Text, not all links retain their visual styles or interactivity. However, at least one of them usually behaves correctly. I use browser developer tools to inspect that "working" link, copy its unique class name, and paste it into the script where the new class is applied. This effectively replicates the working style across all links.
I’ve also attached a .story file with a simplified example and the JavaScript snippet. Below is a short tutorial on how to inspect a link and copy its class name for use in the script.
- Observation Setup:
Alistair Articulate should really find a solution for this. Since your posting in Feb, have you found an accessible fix to the hover issue? If so, can you please share it here? I did not see a answer on past version history builds or on the feature roadmap. Thanks.
