1725916 - Setting aria-description on an element should be enough to expose the element in the accessibility tree

Status: RESOLVED FIXED

(Core :: Disability Access APIs, enhancement, P1)

Description

[Michael Curran]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Firefox/91.0

Steps to reproduce:

Entered the following data URI into the location bar:

data:text/html,<p>This <span aria-description="Collaborater is editing">is</span> a test.</p>

And investigated the resulting accessibility tree of the document with either NVDA object navigation (simple review mode off) or by using Inspect from the Windows SDK.

Actual results:

The accessibility tree contained the document, and inside that a paragraph, with the text "This is a test" inside that.

Expected results:

On Windows, The "is" of "this is a test" should have been inside an IAccessible2 object with a role of textFrame, and a accDescription of "Collaborater is editing".

Note that if the testcase is changed to also set aria-label, the accessible object for the span does appear.

I would expect that setting aria-description should be enough to ensure the element is exposed in the accessibility tree, as long as aria-hidden is not True or display is not None of course.

The motivation behind this bug is for NVDA to support the new ARIA annotations features in ARIA 1.3: https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Annotations

Comment 1

[James Teh [:Jamie]]

Fixing this raises the issue of Gecko's lack of support for the description-from object attribute.

The proper fix for this bug would cause the description object attribute not to be exposed, which was always a bug. However, I know NVDA now depends on this. I can write a patch which both fixes this bug and keeps the description object attribute, but we should figure out a transition strategy for that.

If I read the code right, NVDA won't fall back to description-from even if description isn't present, as it doesn't call the superclass. That makes backwards compatibility a bit tricky. We could:

1. Expose description-from and keep description for a few releases; or
2. Just expose description-from and get rid of description straight away. That would break NVDA + Firefox for annotations right now, but if annotations aren't being used in the wild yet, maybe that doesn't matter.

There's also the question of which values NVDA absolutely requires for description-from. I could probably implement description-from:aria-description without too much trouble. Implementing all the rest is a lot harder, though. What's the minimum we can get away with in the short term?

Mick, thoughts?

Comment 2

[Michael Curran]

I don't believe we have any current plans to support more than just aria-description for the description-from value, at least not within this ARIA annotations project. So as a minimum just supporting description-from:aria-description would be great.
As for removing the description IA2 attribute: I think this is fine. If we know this is on your radar, then we can either ensure that lack of description falls back to checking for description-from or we completely remove the check for description all together. There is no real-world cases at the moment anyway that I am aware of.

Comment 3

[James Teh [:Jamie]]

Attachment: Bug 1725916: Ensure an Accessible is created if aria-description is set.

Comment 4

[James Teh [:Jamie]]

Mick, note that this patch fixes the bug here, but does not add description-from. For now, we keep the buggy description object attribute. I filed bug 1726087 for description-from. I'm not sure when I'll get to that yet.

Comment 5

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/40d991086c1f
Ensure an Accessible is created if aria-description is set. r=eeejay

Comment 6

[Marian-Vasile Laza]

https://hg.mozilla.org/mozilla-central/rev/40d991086c1f