Closed Bug 1277201 Opened 6 years ago Closed 2 years ago

When html:details is opened or closed, fire a STATE_CHANGE event


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




Tracking Status
firefox49 --- wontfix
firefox71 --- fixed


(Reporter: MarcoZ, Assigned: morgan)


(Blocks 1 open bug)



(2 files)

This is spun off bug 634004. Due to some reframing, possibly related to bug 1261484, the accessible for the html:summary element is being recreated instead of just the contents in the html:details element behing shown or hidden. The accessible needs to remain the same for screen readers to pick up state changes from STATE_COLLAPSED to STATE_EXPANDED and vice versa. Automatic announcement of this state change does not work until we stop recreating this accessible.
Attached patch WIP patchSplinter Review
This is the part of the patch for bug 634004 that didn't land, because it effectively doesn't do anything yet. As soon as the Open state of the details element is toggled, both the details and summary elements' accessibles are being recreated instead of the state toggled and the tree just updated with the newly inserted or removed content. Leaving this here for safekeeping and to demonstrate which direction this should go. No tests yet.
Priority: -- → P3
Depends on: 1285862
No longer depends on: 1261484

CC'ing Eitan, as soon as your accessible recreation patch lands, this should be updated and augmented with a test so it can complete our details/summary implementation. I've confirmed that with your try build, the accessibles no longer get recreated. However I am not sure, with this 3 year old patch, if this is still the way we cause layout to fire events in accessibility, or if there's a new mechanism by now.

Flags: needinfo?(eitan)

We should hopefully not be recreating accessibles here anymore.

Not related: I don't like the nsAccessibilityService interface added in this patch. We can simply watch for an attribute change of open to know when the details is opened or closed.

Flags: needinfo?(eitan)
Blocks: htmla11y

Handle this in DocAccessible::AttributeChangedImpl, probably just before this block:

If we're handling the open attribute, fire a state change event for state expanded. Example of how to do that here:

Add a test! This is tricky because current state change event tests were written well before JS promises existed, so we have this complicated framework called eventQueue. The test should probably go in accessible/tests/mochitest/events/test_aria_statechange.html. You'll want to do an expanded state change test similar to the aria-expanded test (but toggling open attribute on a details element instead of aria-expanded):

One thing to note is that the open attribute is set on the details element, but the state change event should fire on the summary Accessible, not the details Accessible.

If you're really struggling with eventQueue, you could create a new promise-based test file (we're moving towards promise-based tests anyway). Examples of those are accessible/tests/mochitest/events/test_announcement.html and accessible/tests/mochitest/events/test_focus_removal.html. Also, in accessible/tests/mochitest/events/test_focus_aria_activedescendant.html, I combine both eventQueue and promise-based tests (because I didn't want to split into a new file but didn't want to deal with eventQueue for newer tests), but that's fairly obscure.

Assignee: nobody → mislam
Assignee: maliha.rh → mreschenberg
Pushed by
Fire a STATE_CHANGE event when a details element is opened or closed. r=eeejay
Closed: 2 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla71
Regressions: 1580583
You need to log in before you can comment on or make changes to this bug.