Adapt Learning Community: Accessibility: Conversion of Aria Labels

I'm building content for an accessibility remediation and testing service provider. They have put SCORM packages generated using the Adapt framework through their own extensive screenreader testing. One of the very first comments they have is to do with aria-label attributes for box menu items being replaced with an injected child span element with the aria-label info. I found the JS where the injection is happening. /src/core/js/libraries/jquery.a11y.js ...

My client prefers that the aria-label not be stripped from the div.menu-item>div.menu-item-inner and that the injection of the <span> not happen. They want the upper level item to receive focus, not the span.

According to my client:

the span acting as the aria-label receives keyboard focus. Only actionable items should receive keyboard focus.

Obviously, I can hack the framework to prevent this behavior, but because my client is so informed about screen readers, I'm wondering what the rationale is for this functionality. Is this default behavior? Is it default jQuery behavior? Also, what is the most elegant way to prevent the injection of these spans (possibly just on the box menu page)?

Thanks for any information or assistance.

Amy

For starters, this span and tabbing behaviour is [almost] entirely my fault. There are a few reasons for it.

When we started putting accessibility features into Adapt we had a lot of very bad html +/ aria usage and a lot of issue that don't arise in flat, barely interactive websites.

Nested roles and labels:
When specifying `role` and `aria-label` attributes on a tag, some screen readers assume that the content of the tag should not be read and will instead defer to the `aria-label` only as an override.
In Adapt we have lots of structural containers that needed appropriate labeling but which also contain content that should be read (page, article, block and component). The simplest solution at the time was to force all predefined roles from their parents and into a new, self contained span that would read accordingly without blocking sub nodes from the screen reader. This is currently being phased out and replaced with handlebars helpers to make the behaviour clearer. In my next accessibility push I will be attempting to remove the automated `aria-label` to `span` behaviour.

Tabbing:
The reasons for the tabbing behaviour are numerous. Adapt courses are often to be accessed in a linear fashion, they have lots of interactive elements that need to be completed for the learner to proceed and those elements tend to be a combination of text and form input elements (mcq, text input, matching etc). The tabbing mimics the voiceover or jaws screen reader cursor, all of text in Adapt, plus a lot of hidden text currently follows the screen reader cursor 1:1 down the page. By framing accessibility functionality in this way it has allowed us to simplify the effort required to make any course accessible as tabbing and reading are unified.

> the span acting as the aria-label receives keyboard focus. Only actionable items should receive keyboard focus.

With regard to the comment from your client, we have had no other client or customer I'm aware of mention this behaviour as a distinct point of concern. Most screen reader users will be using up/down keys to direct the screen reader cursor or use headers to navigate the page content rather than going straight for the tab key. We do have some issue with where the headers are located in the DOM relative to other content and providing the learner for enough information to allow them to get a good overview of the learning content and completion in the fastest way possible. Again this work is outstanding and should be completed in my next accessibility push.

Moving forward:
There are a load of other issues with accessibility in Adapt. I am currently working for Kineo and with S.A.P., utilizing their accessibility testing teams to propose, discuss and fund the work need for removing the 'enable accessibility mode' button. I'm working on simplifying the behaviour where necessary and removing features from Adapt that aren't needed for accessibility (for various reasons) or which get in the way of providing a more natively accessible course.

References:

Summary of tabbing
https://frontendmasters.com/courses/web-accessibility/tabbable-elements/
Testing of nested aria roles
https://www.powermapper.com/tests/screen-readers/headings/aria-role-heading-nested/
Navigation by heading
http://accessibility.psu.edu/headingshtml/

Show parent | Reply

Oliver, thanks for your response. I completely agree regarding tab navigation of pages and the fact that users often use headings to navigate content. No point of contention there. Though it's also true that my client has run into some cases where tabbing is happening instead of the arrow nav dictated by WCAG. Within form elements, for example, dropdown menus, cell-to-cell navigation in tables, radio buttons in a group) where navigation of the child elements should happen with arrow keys and not tabs if we're really going to conform to WCAG 2.0.

For anyone looking for a way to prevent the span behaivor comes across this issue, change `isAriaLabelFixEnabled: true` in `core/js/accessibilty.js` to `false`. The default with this fix disabled is for the aria-label to remain applied to the parent div.

Show parent | Reply