Accessibility issues with expand/collapse buttons in WebHelp Responsive output

[rjcbop]

We've noticed that the span elements used to display the expand/collapse buttons for expandable elements, such as sections and articles, have the aria-label attribute set to 'expand' or 'collapse' (in English). When using the keyboard to tab to one of these span elements, a screen reader (such as NVDA) announces that it's a button and speaks only the word 'expand' or 'collapse', so the user has no information about what content is associated with the expand or collapse action.

We have topics that contain many expand/collapse buttons, and the lack of more information about what the button is associated with will make it difficult for screen reader users to easily navigate the content. This is even more apparent if a screen reader user brings up a dialog that lists all buttons on a page, since that list will simply contain the text 'expand' or 'collapse' for each of the expand/collapse buttons.

In a post (post48716.html?hilit=wh_expand_btn#p48716) from 2018, another user had asked about whether there's a way to include the actual trigger text in the span element, for example including the section title in a span element for expanding/collapsing a section. Since we're involved in a companywide mandate to make our products accessible, we've gone ahead and written some custom javascript to embed the appropriate trigger text inside the span element that represents the button. The span element for the visible button is then added as a child to this span element (we added javascript code and CSS to handle this), as in the following sample:

<span class="wh_expand_btn" role="button" aria-expanded="false" tabindex="0">
<span class="av_wh_expand_icon" aria-hidden="true"/>
Trigger text:
</span>

We're wondering if the Oxygen team is aware of this accessibility issue and perhaps has this on a road map?

Regards

[radu_pisoi]

Hi,

Thank you for reporting this!

Indeed, adding the element title for the expandable/collapable sections using the "aria-*" attributes represents an improvement toward the current implementation.

Making the WebHelp output accessible is important for us, so we'll try to include this fix in the next version.

[rjcbop]

Thanks for the response!

[rjcbop]

We've also discovered that the tooltips generated from <shortdesc> elements in the DITA source are not keyboard accessible and are not read by a screen reader. We've been able to fix both of these issues in our custom javascript but were not sure if you might already have something in your road map about this .

Specifically, in the case of keyboard accessibility, we added the focusin and focusout methods to the tooltip elements (mimicking what you have for the mouseenter and mouseleave methods in the toc-loader.js file).

In the case of screen reader accessibility, we added the aria-describedby attribute to the element associated with the tooltip (setting the value to a randomly generated integer) and then setting the id attribute of the tooltip element to that value. For example:

<div class="title">
<a href="href-value" aria-describedby="tooltipID">Link text</a>
<div class="wh-tooltip" id="tooltipID">
<p class="shortdesc">Tooltip text</p>
</div>
</div>

Regards