Why you shouldn';t apply actions to text blocks
March 19, 2018 12:00 AM
When I first started doing accessibility testing on Lectora courses years ago, I noticed cryptically labeled links appearing from time to time on pages. I eventually tracked the source of this issue down once I got my own copy of Lectora Publisher and was able to “look under the hood”.
The issue revolves around linking practices in Lectora. In standard HTML coding, links are applied to specific fragments of text; however, Lectora allows designers to attach actions not only to specific text fragments, but also to text blocks.
In short, do not apply hyperlinks (and other actions) at the text-block level; apply these to specific fragments of text. If you are already following this practice, then good for you. Keep up the good work! I’ve noticed as new Lectora designers begin to learn more about the capabilities at their disposal in Lectora, especially adding actions to elements, they can start applying actions to text blocks. This technique causes serious accessibility issues for screen reader users. If you are unconvinced or would like to know the details, keep reading.
When a text block is inserted into a page, the contents are wrapped in a undefined element (HTML id = text30238) is as follows; the style attributes have been omitted and are not relevant here:
undefinedspan class=”text30238Font1”undefinedspan class=”text30238Font2”undefined however, the resulting publish HTML page is not accessible when this is done.
When an action, for example, a Go To action linking to another location in the course or an external URL, is added to a text block, the internal HTML structure of the text block becomes:
undefinedspan class=”text30238Font1”undefinedspan class=”text30238Font2”undefined tag with the style “cursor:pointer.” This gives visual feedback to the learner that the text block is an active mouse click target, but how is this structure presented to a learner using a screen reader?
The link ( tag) is not properly labeled, so the link appears to the screen reader user as “text30238Object,” a totally meaningless label. The screen reader user would have no reason to suspect there is a relationship between the unlabeled link and the non-link text of the text block. Attaching actions to text blocks produces inaccessible content and should not be used.
This is an issue because of how the Lectora developers have chosen to implement this capability in the published HTML. This could easily be resolved if the Lectora developers were to add an aria-labelledby attribute to the tag and set its value to the contents of the text block. Of course, the relevant text block elements would need to have an id attribute to facilitate the labeling.
Until the Lectora developers resolve this issue, the simple solution is to apply actions only to specific text fragments.
Discussion (2)
I commented about the dangers of adding actions to text blocks in another thread regarding text-to-speech behavior with buttons. In a nutshell, the person was asking about how to get the system's TTS to read "text buttons" and one suggestion was creating a text block and adding the action.
The issue with doing so is that screen readers do not announce text blocks with actions as a button. Instead, they consider it an href with an "onUp" attribute and read it as such. HTML:
This does not convey what selecting the text block does unless it's explicitly stated in the text block. This also applies if you convert the text block to an image.
You CAN remove the "href" attribute from the text block if you MUST have the action on it. If you do, make sure the text block includes the instruction that it is clickable. Remove href attribute:
document.getElementById("text123anc").removeAttribute("href");
You could also do this using a class and a loop - Full credit to @TimK for helping me with this one awhile back on another project.
undefined
The fact that screen readers would not announce text blocks with actions as buttons is a trivial issue. Screen reader users understand that links and buttons are actionable elements. For many years now webpages have often employed graphics wrapped in an tag instead of a true button (undefined
Discussions have been disabled for this post