actionmenu: title attribute ignored on NVDA screen reader

Bug

I used my Windows desktop with the NVDA screen reader to get an idea of how non-Mac screen readers handle our use of the title attribute as a non-visual label on buttons. I found that the title attribute’s value is getting ignored, and the labels inside in this case are being read twice. This will cause confusion at worst and annoyance at best for users of NVDA.

Expected behavior

NVDA reads action menu with a non-visual label of “more options” to listener.

Actual behavior

The title attribute is not being read aloud, so the contents of the button are being read instead. The SVG icon’s aria-label as well as its parent wrapping aria-label of “More icon” are being read aloud twice as they are the contents of the <button> and no other way of setting the accessible name is provided.

Steps to repro

1. Install NVDA onto a Windows computer https://www.nvaccess.org/download/
2. Go to https://app.pluralsight.com/library/ in a browser
3. Find a course from the “Continue Learning” section by tabbing to it or hovering over it with your mouse (by default NVDA will read aloud what your mouse is hovering over).
4. Focus on or hover over the action menu for this course. NVDA will read aloud the element’s accessible name

Related packages

• actionmenu v3.2.1
• Any other packages that use title on as an HTML attribute

Code where this is used

Link to code from Prime Directive using this

Environment

• OS: Windows 10
• Browser version: Firefox 65.0
• Screen Reader: NVDA 2018.4.1

Enhancement Request

Use aria-label instead of title as the attribute for labeling buttons that have no text. titles are not an acceptable replacement to visual text for setting a <button>'s accessible name.

Today’s behavior

title as a non-visual label works in ChromeVOX and VoiceOver. This is likely because title as label is a common enough pattern that the Blink and WebKit teams have made it an acceptable way to set an accessible name for a certain elements. Worth noting - Google and Apple both make these browsers and the screen readers that work with them. This is not standard with the W3C’s suggestions with ARIA and likely will not be made universal. aria-label has the widest support for making non-visual labels.

The problem

Users are getting duplicate info from icons and the button’s “label” is not actually being read aloud. A screen-reader user will likely not be able to understand this menu.

The Value Add

WCAG AA compliance for non-visual labels

NVDA and JAWS make up the bulk of screen reader users. NVDA not supporting this method of labeling is a huge problem for any users of our applications that need assistive tech.

JAWS, if I recall correctly also does not support title as label, at least by default. We have yet to get our JAWS licenses (though those are on the way thanks to Maureen Botoman), so that will need to be tested as well to confirm.

The Tradeoffs

title as label seems to be used a lot across the design system. If we are using title as an invisible label anywhere else and not just on actionmenu, they will also need to be updated.

title is also a way to get a “tooltip”, so an alternative way of providing tooltips will be needed.

Note on Tooltips: I suggest checking out Tooltips & Toggletips by Heydon Pickering on his Inclusive Components blog for ways to make tooltips accessible.

This could potentially be a breaking change if I understand correctly, everyone using this package will need to migrate to a version that doesn’t use title, requiring the prop to change name.

Related literature on why title does not provide accessible labeling

• HTML5 Accessibility Chops: title attribute use and abuse by The Paciello Group
• Using the HTML title attribute by The Paciello Group
• The Trials and tribulations of the title attribute by Scott O’Hara
• HTML title attribute docs from MDN

[danethurber]

At the moment the Card.Action will pass through the aria-label. I’ll update the props to require an aria-label going forward. As we address other components this is a great amount of information to use when ensuring our accessibility support.

As for the issue on the home page, the team responsible will need to update their implementation to add the aria-label. I’ll make the proptype change and publish a new version and they can update when they can.

[andylincoln]

Different behavior with NVDA + Firefox using the same file: On page load, when the whole page is read, the aria-label is read and the tooltip is not, as I expected. However, the aria-label is not read upon TABing to the button, instead the title is the only thing that is read, so the aria-label is ignored in all other interactions.

The conclusion I have here is that a title as tooltip is acceptable as additional information, but not as a replacement for a label. <button> text, <label> or aria-label should be preferred for establishing the accessible name. I’d have to do more research to see if title gets counted as an “accessible description” here as defined by the Accessible Name and Description docs.