'title' attribute value should not be read when 'aria-label' is available in [Chrome] and [Firefox]

[sahirboghani]

Steps to reproduce:

1. Open Chrome or Firefox
2. Browse to http://pauljadam.com/demos/title-aria-label.html
3. Scroll to bottom of page
4. Hover over last input box

Expected behavior:

IE only reads out the 'aria-label' when both 'aria-label' and 'title' are on an html element. Chrome and should do the same.

Actual behavior:

Chrome and Firefox read the 'aria-label' then the 'title'.

System configuration:

NVDA version: NVDA 2017.3

Windows version: Windows Server 2016

[sahirboghani]

Maybe only read the 'title' in addition to the 'aria-label' if the values of the two are different?

[feerrenrut]

Thank you for providing a test case.
By "hover" I assume you mean with the mouse?
Could you elaborate on why you think that title should not be reported when aria-label is present?

The title attribute gets mapped to description, and the aria-label attribute gets mapped to name. It's typical for NVDA to report both name and description since there is often extra information that is useful to the user.

Whether title is exposed as description is something that will likely need to be decided on between the standards groups and the browsers.

From my own testing, with Chrome version: 63.0.3239.84 (Official Build) (64-bit) and using the above test case:

1. tab to the text input box
2. both "aria-label Attribute" and "Title Attribute" announced by NVDA.

The NVDA dev info for this object shows that these values come from the name and description:

name: u'aria-label Attribute'
role: ROLE_EDITABLETEXT
states: STATE_FOCUSABLE, STATE_EDITABLE, STATE_FOCUSED
isFocusable: True
hasFocus: True
Python object: <NVDAObjects.Dynamic_EditableTextWithAutoSelectDetectionEditorIa2WebIAccessible object at 0x06DF7A30>
Python class mro: (<class 'NVDAObjects.Dynamic_EditableTextWithAutoSelectDetectionEditorIa2WebIAccessible'>, <class 'NVDAObjects.behaviors.EditableTextWithAutoSelectDetection'>, <class 'NVDAObjects.behaviors.EditableText'>, <class 'editableText.EditableText'>, <class 'NVDAObjects.IAccessible.ia2Web.Editor'>, <class 'NVDAObjects.IAccessible.ia2Web.Ia2Web'>, <class 'NVDAObjects.IAccessible.IAccessible'>, <class 'NVDAObjects.window.Window'>, <class 'NVDAObjects.NVDAObject'>, <class 'baseObject.ScriptableObject'>, <class 'baseObject.AutoPropertyObject'>, <type 'object'>)
description: u'Title Attribute'

See the computation of name and description fields as prescribed by WAI-ARIA 1.1 spec. Also relevant is the accessible name for roles description

[sahirboghani]

@feerrenrut Yes, "hover" with the mouse. The reason I think title should not be reported when aria-label is present because there is a parity in behavior in Chrome/Firefox vs IE/Edge.

The specific case I'm referring to is when title and aria-label have the same value. In that situation, NVDA says the same thing twice, which (I believe) in incorrect behavior. Thoughts on that conditional change?

Thanks!

[feerrenrut]

Yes, repeating information is not very helpful. However, I think this is a web authoring error. Are you suggesting that when the values for title and aria-label match only one is reported when using IE/Edge? Are they both reported in IE / Edge when they do not match?

While we might be able to detect and improve this situation, doing so would actually make it harder for accessibility testing of web sites. It makes the problem less apparent. So there is the question of whether we should.

[BerGer23]

The W3C spec prohibits the usage of the title attribute when there is an aria-label:

The last resort is to use text from a tooltip attribute (such as the title attribute in HTML). This is used only if nothing else, including subtree content, has provided results.

[isidorn]

@feerrenrut hi, vscode developer here.
We are hitting issues which seem to be a duplicate of this - more details can be found here microsoft/vscode#51992
But the point is that data is duplicated since both the title and the aria-label are being read out.
VoiceOver on mac handles this case properly and does not read the title when aria-label is present.
Is this a bug on NVDA or is there something we could do on the vscode side to fix this?

Thanks a lot

[derekriemer]

But the point is that data is duplicated since both the title and the aria-label are being read out.

This is a bit confusing. To be clear, what is happening is the following: the description property is being read, and the name. The description can be turned off by users, but we want to ensure that the description is reported as well. We aren't using title to calculate name here, but the description is equivalent to a tooltip. Tooltips are suplimental info, and ideally shouldn't be the same as the name. Take the example of a button which says "remove", and when the user hovers over the remove button, it says "Removes the addon from the system" This info is provided through the description for the user.

[deap82]

I came here facing the same issue and just wanted to share my point of view as I have it top of mind.

As the title attribute is also rendered as a visible tooltip that is available for sighted users it might not be "design appropriate" to have a very long descriptive text as sigthed users are also able to take in the visual context of the element.

For a screen reader user it makes sense to provide more context.

Elaborating on the example from @derekriemer I believe "Remove" is often enough as tooltip for sighted users, while "Removes the addon from the system" would be better for screen reader users.

Being able to differentiate text like that seems very helpful to me and generally it would be a whole lot easier and more "separation of concerns" if aria-label could always be used as the spoken text for any element that has it (which of course is out of scope for this particular issue).

To me this means that the suggestion of only reading both if they differ is not relevant, I would prefer the point @BerGer23 is making by referencing the W3C spec.

As it is now when I want sighted users to see a short tooltip, I'll have to author my html by having two elements, one with the title attribute and aria-hidden="true" and another using a "visually-hidden"/"screen-reader-only" type of css class where I can put a longer text for screen readers.

On another note; why does NVDA even have differences between browsers? If the browsers get the exact same html from my site, why does NVDA behavior differ?

[taylorchasewhite]

Agree with @BerGer23 and @deap82 in reference to the WAI guidelines.

Here's the dilemma I found myself looking into:
We have a navigation region with links in it, much like Google search results navigation region at the bottom of each page.

The anchor element has the page number in it (e.g. '1', '2', '3'). The tooltip has 'Page #' in it (e.g. 'Page 1', 'Page 2', 'Page 3').

NVDA reads the following '2 link page 2' (name, type, description). A web developer has no way in this scenario to both maintain a singular '#' as the anchor text, keep a tooltip, and have NVDA not read duplicate information out.

If I add an aria-label, it will read 'Page 2 Link Page 2', which is also incorrect. I can add an aria-label and drop the tooltip to arrive at 'Page 2 Link', but this is a bad solution because we lose the tooltip in order to achieve a nice accessibility experience.

[Malvoz]

Keeping @BerGer23's comment in mind, I think the suggestion in #7841 (comment):

Maybe only read the 'title' in addition to the 'aria-label' if the values of the two are different?

is a good starting point.

The W3C Maps for HTML Community Group has currently implemented web maps from 12 different tools where 9 of them have at least 1 component where both aria-label and title are identical.

[MarcoZehe]

Firefox suppresses the AccDescription, of which the title attribute is usually the primary source, if the AccName is the same. So if the name is from aria-label, but the title is also provided for tooltips for sighted people, and these two are identical, Firefox strips out the AccDescription.

JAWS adopted this behavior also for other cases, such as Chromium, or Windows 32 apps. Orca on Linux does the same for ATK.

I believe there are enough reasons for NVDA to be proactive here and suppress the AccDescription if the AccName is identical. It would reduce verbiage for us users in many more circumstances. Advertising for each and every authoring error or what we perceive as such, is much more cumbersome and stressful than making this change in NVDA. There won't be any information loss if these two are identical, so NVDA may as well strip AccDescription in those cases.

[isidorn]

100% agree with @MarcoZehe
It would be great if we get this fixed in NVDA.

[feerrenrut]

I agree this would be better for end users. For a11y testers using NVDA, there could be an argument to preserve this behavior behind a option (so they can more easily detect this case). Though if all screen readers accept and work around this issue, then it might as well be the standard.

[isidorn]

All screen readers that I tried (VoiceOver and Orca) do not duplicate read the title and the aria-label.
So yes I think it would be great if we get this fixed in NVDA as we are getting more and more issues in VS Code regarding this.

fyi @jhomme

[jhomme]

Hi,
It's a long known issue that the title attribute does not behave properly with screen readers. If the title attribute is different from either the ARIA label or the on-screen label in the label tag, NVDA should read it. Otherwise, it should ignore it.

[carmacleod]

It's not always aria-label with title that can cause name and description to be identical. This can also happen with text content and title when an element gets its name from its content.

For example, I found a case where a listbox option's name and description are identical (in Chrome and chromium Edge).
Here's the code (this was for an option in a listbox, but it could also have been for a treeitem in a tree, tabs in a tablist, or even a cell in a table):

<div role="option" title="An example option that is really long to show how long text is handled">
  <div class="combo-item__option">An example option that is really long to show how long text is handled</div>
</div>

The author used the CSS magic of text-overflow: ellipsis; overflow: hidden; white-space: nowrap; to visually truncate the text and add ... when the listbox is too narrow. The text content is still all there - it is only the visual rendering that has the ellipsis. The title was added so that sighted users can hover to see the full option text.

I wouldn't even call this case an author error - it's just an unfortunate side effect of the weirdness of the title attribute (i.e. it's a name if there's no other name, but it's a description if there's already a name).

Since NVDA reads both name and description, it ends up double-speaking when they're identical, as they are in this case.

As @MarcoZehe pointed out in #7841 (comment), Firefox (wisely) doesn't expose the description if it's identical to the name (no matter where the name comes from).

So for NVDA to avoid double-speaking, there seem to be 2 choices:

1. try to convince Chrome/Edge (maybe others) to do as Firefox has done (I didn't check Opera, old Edge, Internet Explorer, ...),
2. simply not speak the description when it is identical to the name (guaranteed to work in all browsers, and seems like a good idea anyhow).

[isidorn]

Agree with the above. Also note that Screen Reader Orca on linux already does what is suggested under 2.

[isidorn]

Fixed via #12888
@feerrenrut we should close this

[feerrenrut]

There are many variations described on this issue. I'm going to close this issue (due to the merging of #12888). Please create a new issue to describe any variations that are not addressed.