Closed Bug 493683 Opened 16 years ago Closed 4 years ago

Fire name/description change event when aria-labelledby/describedby content changes

Categories

(Core :: Disability Access APIs, defect, P3)

Product:
Core
Component:
Disability Access APIs
Type:
defect

Tracking

()

Status:
RESOLVED FIXED
Milestone:
87 Branch
Tracking Flags:
Tracking Status
firefox87 --- fixed

People

(Reporter: surkov, Assigned: Jamie)

References

(Blocks 2 open bugs)

Details

(Keywords: papercut, parity-chrome)

Attachments

(5 files)

Bug 493683 part 1: Rename HasNameDependentParent to HasNameDependent due to upcoming broader usage.
(deleted), text/x-phabricator-request
Details
Bug 493683 part 2: When an Accessible mutates, fire name change events on an Accessible labelled by it (or an ancestor thereof) via a relation.
(deleted), text/x-phabricator-request
Details
Bug 493683 part 3: When an Accessible mutates, fire description change events on an Accessible described by it (or an ancestor thereof) via a relation.
(deleted), text/x-phabricator-request
Details
Bug 493683 part 4: Add a PivotRule to match any local Accessible in the same document.
(deleted), text/x-phabricator-request
Details
Bug 493683 part 5: When aria-labell/describedby is set, set HasName/DescriptionDependent on the target subtree.
(deleted), text/x-phabricator-request
Details
Our AT's want to get name change event when name change is changed with one exception they don't need name change event if it's calculated from subtree.
Blocks: eventa11y
there is sub bug 507559 to fire name change events for window title changes.
Hi, can this issue be fixed recently?
(In reply to Xiao Yong Li from comment #3) > Hi, can this issue be fixed recently? what do you mean?
Our product is under accessibility certification process, Firefox doesn't fire a name change event and thus JAWS doesn't read the changed name on the button of our widget. If this issue can be fixed before release date (July 30th) we can declare our widget accessibility compliant, otherwise we need to file a deviation which means our widget is not completely accessible.
this bug is kind of generic and making a complete fix should regress our performance. Do you have use case?
We use dojo titlePane, this use case and problem are similar with bug#470082: https://bugzilla.mozilla.org/show_bug.cgi?id=470082.
(In reply to Xiao Yong Li from comment #7) > We use dojo titlePane, this use case and problem are similar with > bug#470082: https://bugzilla.mozilla.org/show_bug.cgi?id=470082. can you provide URL or attach a test case?
This is reference guide of dijit.TitlePane of dojo 1.8:http://dojotoolkit.org/reference-guide/1.8/dijit/TitlePane.html#programmatic-example Run any example and click the header of TitlePane. When a TitlePane is activated to open or close the associated panel the accessible name is changed, i.e. the prefix of title is a '+' if the pane is closed and '-' if the pane is open. However Firefox doesn't fire a name change event and thus JAWS doesn't read the new name on the button.
I can see accessible name like "I'm a TitlePanel too" and it's not changed at all. So the problem seems to be not about eventing. Does it what you see too?
The expand and collapse status marks ("+" and "-") changes alternately whenever the title being pressed. And these marks are inside a WAI-ARIA "button" role, so the accessible name of this "button" changes too.But Firefox doesn't fire a name change event and thus JAWS doesn't read the new name on the button.

This is affecting people in the real world. See NVDA issues https://github.com/nvaccess/nvda/issues/9387 https://github.com/nvaccess/nvda/issues/1626. This is a problem for the Facebook Notifications button (and the fact that this misbehaves was one reason for an NVDA performance improvement being backed out); see https://github.com/nvaccess/nvda/pull/9114#issuecomment-467665494. A similar problem applies to aria-describedby; see https://github.com/nvaccess/nvda/issues/9400.

Both of these test cases demonstrate the problem and work in Chrome, but fail in Firefox:

Label change (pressing the button should fire a name change event):
data:text/html,<div id="label">a</div><button aria-labelledby="label" onClick="label.textContent = 'b';">foo</button>

Description change (pressing the button should fire a description change event):
data:text/html,<div id="desc">a</div><button aria-describedby="desc" onClick="desc.textContent = 'b';">label</button>

In both cases, NVDA's virtual buffer does not update with the correct info because the appropriate events aren't fired.

Keywords: parity-chrome
Priority: -- → P3

Bug title feels too generic, because it's difficult to implement name change events whenever name is changed, but supporting aria-labelledby/described_by is doable. So I would change bug summary to reflect that. Regarding to implementation itself, it seems HasNameDependentParent logic should be extended to handle ID-referencing attributes.

Agreed. Thanks heaps for the implementation hint, Alex!

Summary: fire name change event whenever name is changed → Fire name/description change event when aria-labelledby/describedby content changes
Severity: normal → S3
Keywords: papercut
Assignee: nobody → jteh

HasNameDependent is now set on an Accessible (and thus its descendants) which has A LABEL_FOR relation.
When text mutations occur on such an Accessible, EventQueue::PushNameChange now queues a name change for the Accessible being labelled.

This uses a similar approach to HasNameDependent, introducing a new HasDescriptionDependent.
However, we don't fire events on ancestors, since a description is never computed from an Accessible's own subtree without an explicit described by relation.

Pushed by jteh@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/12e73301de8f part 1: Rename HasNameDependentParent to HasNameDependent due to upcoming broader usage. r=eeejay https://hg.mozilla.org/integration/autoland/rev/24847760402f part 2: When an Accessible mutates, fire name change events on an Accessible labelled by it (or an ancestor thereof) via a relation. r=eeejay https://hg.mozilla.org/integration/autoland/rev/cefb1c1d3f5e part 3: When an Accessible mutates, fire description change events on an Accessible described by it (or an ancestor thereof) via a relation. r=eeejay https://hg.mozilla.org/integration/autoland/rev/2a3f24bdb8e2 part 4: Add a PivotRule to match any local Accessible in the same document. r=eeejay https://hg.mozilla.org/integration/autoland/rev/2c9004c95a7a part 5: When aria-labell/describedby is set, set HasName/DescriptionDependent on the target subtree. r=eeejay
Regressions: 1689936
Blocks: 1699339
Regressions: 1703600
Regressions: 1700708
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: