Nvda: NVDA fails to read aira-label text for most elements

[G0dwin]

Steps to reproduce:

1. Turn on speech viewer
2. Open Firefox
3. Browse to https://codepen.io/Godwin/pen/KybVYL
4. Copy speech viewer log
5. Filter out anything that doesn't match /^\[\w+\]$/

Expected behaviour:

Unsure...

Actual behaviour:

Here is the resulting list of elements that were read:

li
marquee
meter
table

System configuration:

NVDA version: 2017.3

NVDA Installed or portable: Installed

Windows version: 10

Other questions:

Looking through Deque's test suites, I see that most screen readers have a similar support for the aria-label attribute: https://dequeuniversity.com/testsuite/aria/aria-label-aria-labelledby/results/

However, I have failed to find any documentation from the W3C on when screen readers should respect aria-label, so what is NVDA's logic behind the decision of whether or not an element's aria-label text is read? Is this a bug, a decision that NVDA came to, or an informed, documented decision from the W3C or another common group like this?

[LouisHQ]

I encountered a same issue with https://nvda.groups.io/g/nvda/topic/file_upload_form_field/3305279?p=,,,20,0,0,0::RecentPostDate%2FSticky,,,20,2,0,3305279

[feerrenrut]

One thing that should be considered in this test is what the browser does, many of these elements are empty, do you expect them to be rendered (visually or to a screen reader)?

Consider (a subset of) your test with some value inserted into these elements:

data:text/html,<div>!!!START!!!</div><a aria-label="[a]">link</a><br /><abbr aria-label="[abbr]">shorter</abbr><br /><address aria-label="[address]">home street</address><br /><area aria-label="[area]" alt="">some shape</area>

From which NVDA produces:

Browse mode
!!!START!!!
clickable
[a]
shorter
home street
[area]
some shape

A general guide from W3C is available and aria-label documentation you may also find the accessible name calculation interesting

[G0dwin]

Thanks @feerrenrut, ensuring items have content is important and changes the results.

When I re-run the test with content in each item this is the list of items where NVDA reads the aria-label:

• a
• aside
• blockquote
• button
• summary
• footer
• h1
• header
• hr
• iframe
• input
• keygen
• main
• meter
• nav
• ol
• section
• select
• option
• table
• textarea

There are some notable element missing from this list which I generally would have expected to have been picked up, most notable are div and span.

If for example we wanted to show a section of text as strike-through, highlighted, or otherwise visually different from surrounding text. Ignoring for the moment any better semantic HTML tags (which are also not included in the list), my first instinct would be do add a label to the text to ensure a screen reader picks up on the change:

<p>
  I wandered lonely as a
    <span class="mistake" aria-label="correction from">clam</span>
    <span class="correction" aria-label="corrected to">cloud</span>.
</p>

or:

<h1>To Do:</h1>
<ul>
    <li><span class="task complete" aria-label="Task completed">Get out of bed</span></li>
    <li><span class="task incomplete">Get dressed</span></li>
</ul>

However the label is not read for any of these cases. There are other ways (and better ways in these cases), but having a way to predict the behaviour before implementing a method would make life a lot easier.

The WCAG states that the aira-label attribute is used in "All elements of the base markup". They don't explicitly define what the base markup is but I assume that is all elements. MDN states:

This attribute can be used with any typical HTML element; it is not limited to elements that have an ARIA role assigned

Given this, it is difficult to understand why NVDA (and other screen readers) ignore the aria-label attribute for most elements.

[derekriemer]

in your example, the aria label would actually override the contents of the element with the text you provide, (because it is the label). For example,

<p> As the flowers <span aria-label="spelling error">Blumed</span>, The birds migrated back to their summer homes. <span aria-label="grammar error">My sister and me</span> watched in awe as a robin built her nest out as the snow softly fell on the late April morning.</p>

I think this should actually render as

As the flowers spelling error, The birds migrated back to their summer homes. grammar error watched in awe as a robin built her nest out as the snow softly fell on the late April morning.

Also, some elements, like <br/> would make no sense with a label.

[G0dwin]

It actually renders as:

As the flowers 
Blumed
, The birds migrated back to their summer homes. 
My sister and me
 watched in 
awe as a robin built her nest out as the snow softly fell on the late April morning.

The label is not read at all, I've tested this in Chrome and Firefox.

Again, I have some pretty poor examples here and there are better ways of making them screen reader accessible. I'm just trying to understand the logic behind when a label is read or not, it doesn't seem to be based in any W3C documentation.

[feerrenrut]

I can't speak for the history behind why 'div' and 'span' are not overridden by aria-label in this case. If I had to guess, I would say that it is because these are typically container elements. What I think happens in this case is that NVDA descends into the lowest child and reports from there. In the case where there is plain text here, NVDA can successfully report that to the user and has no need to traverse back up the tree.

If NVDA were to report the parent attributes (such as the aria-label on the span) where should it stop when there are many levels of container elements?
There is also the question of whether this is actually useful to NVDA users, is this actually a common pattern where useful information is lost?

Using the example given Derek (copy and paste into address bar of chrome or FF): data:text/html,<p> As the flowers <span style="color:red" aria-label="spelling error">Blumed</span>, The birds migrated back to their summer homes. <span style="color:blue" aria-label="grammar error">My sister and me</span> watched in awe as a robin built her nest out as the snow softly fell on the late April morning.</p>

After moving the NVDA browse mode cursor to the word "Blumed" and pressing NVDA+ctrl+z to invoke the NVDA python console I can get the following information about the hierarchy:

>>> from pprint import pprint
>>> n = nav
>>> pprint(n.devInfo)
["name: u'spelling error'",
 'role: ROLE_SECTION',
 'states: ',
 'isFocusable: False',
 'hasFocus: False',
 'Python object: <NVDAObjects.IAccessible.ia2Web.Ia2Web object at 0x06EF3EF0>',
 "Python class mro: (<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: None',
 'location: (398, 201, 64, 22)',
 "value: u''",
 "appModule: <'appModuleHandler' (appName u'chrome', process ID 3804) at address 6d34f50>",
 "appModule.productName: u'Google Chrome'",
 "appModule.productVersion: u'63.0.3239.84'",
 "TextInfo: <class 'NVDAObjects.IAccessible.IA2TextTextInfo'>",
 'windowHandle: 723278L',
 "windowClassName: u'Chrome_RenderWidgetHostHWND'",
 'windowControlID: 1418470944',
 'windowStyle: 1445986304',
 'windowThreadID: 10068',
 "windowText: u'Chrome Legacy Window'",
 "displayText: u''",
 'IAccessibleObject: <POINTER(IAccessible2) ptr=0xafd4b04 at 6eee990>',
 'IAccessibleChildID: 0',
 'IAccessible event parameters: windowHandle=723278, objectID=-4, childID=-231',
 "IAccessible accName: u'spelling error'",
 "IAccessible accRole: u'SPAN'",
 'IAccessible accState:  (0)',
 'IAccessible accDescription: None',
 "IAccessible accValue: u''",
 'IAccessible2 windowHandle: 723278',
 'IAccessible2 uniqueID: -231',
 'IAccessible2 role: IA2_ROLE_SECTION',
 'IAccessible2 states: IA2_STATE_OPAQUE (1024)',
 "IAccessible2 attributes: u'display:inline;tag:span;explicit-name:true;'"]
>>> pprint(n.children[0].devInfo)
["name: u'Blumed'",
 'role: ROLE_STATICTEXT',
 'states: ',
 'isFocusable: False',
 'hasFocus: False',
 'Python object: <NVDAObjects.IAccessible.ia2Web.Ia2Web object at 0x0700D830>',
 "Python class mro: (<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: None',
 'location: (398, 201, 64, 22)',
 "value: u''",
 "appModule: <'appModuleHandler' (appName u'chrome', process ID 3804) at address 6d34f50>",
 "appModule.productName: u'Google Chrome'",
 "appModule.productVersion: u'63.0.3239.84'",
 "TextInfo: <class 'NVDAObjects.IAccessible.IA2TextTextInfo'>",
 'windowHandle: 723278L',
 "windowClassName: u'Chrome_RenderWidgetHostHWND'",
 'windowControlID: 1418470944',
 'windowStyle: 1445986304',
 'windowThreadID: 10068',
 "windowText: u'Chrome Legacy Window'",
 "displayText: u''",
 'IAccessibleObject: <POINTER(IAccessible2) ptr=0x8f89744 at 6feb710>',
 'IAccessibleChildID: 0',
 'IAccessible event parameters: windowHandle=723278L, objectID=-4, childID=-235',
 "IAccessible accName: u'Blumed'",
 'IAccessible accRole: ROLE_SYSTEM_STATICTEXT',
 'IAccessible accState:  (0)',
 'IAccessible accDescription: None',
 "IAccessible accValue: u''",
 'IAccessible2 windowHandle: 723278',
 'IAccessible2 uniqueID: -235',
 'IAccessible2 role: ROLE_SYSTEM_STATICTEXT',
 'IAccessible2 states: IA2_STATE_OPAQUE (1024)',
 "IAccessible2 attributes: u'display:inline;'"]

One option for text-nodes (using definitions from W3C Accessible Name and Description: Computation and API Mappings 1.1) is to also announce or replace with the properties of the parent node. Careful thought would have to be put into this, there is a real risk of too much verbosity.

[PratikP1]

A useful exercise here would be to come up with examples and patterns where aria-label should not be announced. There is no question that, many times, aria is used in too many places without regard to its appropriateness, resulting in too much verbiage. However the question is whether NVDA should determine appropriateness. The best, but perhaps not the easiest, way to deal with this situation is to expose aria-label in all cases while letting the user turn off the functionality on an app by app basis. Microsoft and Google are determined to bring progressive web apps through the Microsoft app store and via Chrome. This functionality will most likely be useful.

[LJWatson]

It is worth noting that aria-label will not work with most/many HTML elements (including those in the original test case included above). This short note on using aria-label, aria-labelledby, and aria-describedby has more information.

[MelSumner]

I think this issue should be closed as not valid (@LJWatson gave the reference that the issue author should read instead).

[Invisibility]

We found a workaround. Instead of

<span role="text" aria-label="[span]"></span>

we have:

<span role="text" aria-label="[span]">
    <svg class="hidden-element-accessibility" height="1px" width="1px"/>
</span>

where hidden-element-accessibility has this definition:

.hidden-element-accessibility {
  float: left;
}
.hidden-element-accessibility:focus {
  outline: none;
}

[alvaromontoro]

I am experiencing a similar issue in which aria-label is ignored or doesn't work as expected. Using aria-label in a <section> (one of the valid cases from the Paciello page linked above) like this:

<section aria-label="List section">This is a random text</section>

NVDA's behavior is different depending on the browser:

• IE ignores the aria-label and reads the whole content of the section: "This is a random text"
• Chrome/Firefox read the aria-label followed by the whole content of the section: "List section. This is a random text."

The IE behavior could be the result of caching, but is the behavior from Chrome/Firefox the one to be expected in this case? (and please let me know if I should open a different ticket for this)

[Sheepu-dev]

I am facing the same issue in my application as NVDA is not reading aria-label property on a div or span, how can I fix this issue without changing the HTML control?

[feerrenrut]

As mentioned already this issue is invalid, and will be closed. A good description of expected behavior is provided here: short note on using aria-label, aria-labelledby, and aria-describedby