Closed Bug 997752 Opened 11 years ago Closed 6 years ago

ARIA state changes from within shadow DOM don't trigger events

Categories

(Core :: Disability Access APIs, defect)

Product:
Core
Component:
Disability Access APIs
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED WORKSFORME

People

(Reporter: MarcoZ, Unassigned)

References

Details

STR: 0. In about:config, set the value of dom.webcomponents.enabled to "true", it is "false" by default. 1. Load http://www.heydonworks.com/accessible-web-component-with-aria/ 2. Tab to the "Some Info" button, which is announced by NVDA as "collapsed". 3. Press Space or Enter. Expected: Button should expand the content hidden by it, and state should change to "expanded". Actual: No change, either in accessibility tree or the button state. 4. Tab to the "More info", which is announced as "expanded". 5. Press Enter or Space to collapse. Result: Same as above. Neither the accessibility tree nor the state of the button change.
Note that this is also very important for Firefox OS accessibility, since that will start to rely on web components heavily soon, from what I hear.
More info: I also tried this with NVDA's browse mode off (Insert+Space to toggle), no change.
I do see correct state and correct state change events on the button on Nightly.
I see neither. To me, it looks like nothing happened to the button, even when I simulate a mouse click on it. I cannot visually verify if anything happens or not, or if just a11y isn't updated. The pref is definitely set to true, so the web components stuff is enabled. It's today's regular nightly build, running on Windows 8.1, but in Desktop mode.
how do you check events and states?
Considering I'm on PTO, I only used NVDA to check the virtual buffer, I even refreshed it, and what gets spoken as the focused item when tabbing. So the IA2 side of things definitely doesn't see *any* events or tree updates, or state changes on the buttons. Refreshing NVDA*s virtual buffer is done with Insert+F5. If the state changed without notifications, the new content should be visible, but it isn't. the a11y tree doesn't get changed.
Did you not enable the dom.webcomponents.enabled preference? I just turned it off, restarted nightly, and tried the example, and now I see the state changes and a11y tree updates. But as soon as I enable webcomponents again, which you are supposed to, it breaks again. So, be sure to enable the pref given in step 0 of comment #0.
With pref on I cannot even load the page, the browser crashes, crash reporter doesn't handle it. It was Nightly. Are you running on the Nightly?
Yes I am using the 2014-04-17 nightly, and don't see a crash when the pref is on.
This bug has morphed, and now appears as if the element is being completely rerendered when toggled. In browse mode, NVDA is silent, in focus mode, both button and state are spoken when toggling. Jamie, I believe this is similar in behavior to bug 659886 what NVDA is concerned, right?
Flags: needinfo?(jteh)
(In reply to Marco Zehe (:MarcoZ) from comment #10) > This bug has morphed, and now appears as if the element is being completely > rerendered when toggled. In browse mode, NVDA is silent, in focus mode, both > button and state are spoken when toggling. Jamie, I believe this is similar > in behavior to bug 659886 what NVDA is concerned, right? Correct. I actually suspect this has nothing to do with shadow DOM now and is instead related to our more general CSS a11y problems such as bug 659886. Confirming that would mean refactoring the code so that we can test it without use of shadow DOM.
Flags: needinfo?(jteh)
Confirmed; this is no longer a shadow DOM related bug. This code illustrates the problem now: data:text/html,<style>[aria-expanded="true"]:before {content: '\25be\0020';}"</style><button aria-expanded="false" onClick="this.setAttribute('aria-expanded', 'true');">Some info</button> Pressing the button causes the :before pseudo-element to appear, which cause the accessible to be re-created. Closing as wfm. Marco, would you mind putting the above test case in the appropriate bug or filing a new one as you feel appropriate?
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.