Closed Bug 551684 Opened 10 years ago Closed 10 years ago
No statechange event for aria-expanded on native HTML elements, is fired on ARIA widgets
STR: 1. Open above URL. 2. Focus on the "Archive" heading. 3. Press ENTER to collapse or expand. Expected: state-change should inform screen reader that the state has changed from collapsed to expanded. This heading uses aria-expanded to indicate whether the archive list is visible or not. Actual: No announcement. Further investigation shows that NVDA picks up the state change (although it doesn't announce it, but it updates) when the widget is an ARIA widget, but not if it is a native heading. I will attach a testcase to demonstrate this.
The first is a div with a role of "button". When pressing ENTER, NVDA doesn't speak the change, but when asking, it will pick up the different state. With the heading below, which is a native HTML:h3, this change is only picked up after pressing Insert+F5 to refresh the buffer.
Assignee: nobody → bolterbugz
According to spec, aria-expanded is listed in section 6.4. Global States and Properties. That said, I think we should fire this change. I'll work up a patch, and try to drive this in spec or at least in the implementation guide.
The simplest fix is to remove the bail out in nsDocAccessible::ARIAAttributeChanged when there is no role attribute. This would actually be my preference; since we have the info, why not expose it... we just need to make sure other browsers do the same.
Attachment #432210 - Flags: feedback?(marco.zehe) → feedback+
Comment on attachment 432210 [details] [diff] [review] WIP I tested with this patch and it does fix the bug. NVDA's virtual buffer gets the new state, NVDA just doesn't announce it automatically. The difference to the blog URL is that there is probably no reorder event which triggers the automatic announcement like on the blog, because the testcase doesn't add or remove any DOM nodes. It simply changes the attribute's value in both cases.
1) The spec link please 2) I wonder if states are updated properly (iirc we had related bug)
(In reply to comment #6) > 1) The spec link please The important one (so that browsers are interoperable): http://www.w3.org/WAI/PF/aria-implementation/ - We help drive this. The spec: http://www.w3.org/WAI/PF/aria/ Note, my personal plan for ARIA 2.0 is to see if we can blow away a lot of the restrictions about what properties can go with what roles etc. I think we need a more flexible system on the web. > 2) I wonder if states are updated properly (iirc we had related bug) Not sure.
So actually, according to the implementation guide currently, we must fire aria-expanded events (4.8.1. State and Property Change Events).
(In reply to comment #7) > > 2) I wonder if states are updated properly (iirc we had related bug) > > Not sure. I mean state change events doesn't have lot of sense if state is wrong.
(In reply to comment #7) > (In reply to comment #6) > Note, my personal plan for ARIA 2.0 is to see if we can blow away a lot of the > restrictions about what properties can go with what roles etc. I think we need > a more flexible system on the web. this is fine while it makes sense. For example, I don't see lot of sense to fire state change events for aria-expanded changes on textbox. I mean it doesn't make sense to process DOM notifications and fire accessibility events for some stuffs. (In reply to comment #8) > So actually, according to the implementation guide currently, we must fire > aria-expanded events (4.8.1. State and Property Change Events). I read this as we should fire state change events when ARIA widget has proper role. So it's not the same with the bug summary. Personally I find reasonable to allow aria attributes on native elements with proper accessible role. Technically the patch is not the same. It goes with your personal plans :) It should be related with bug 526315 and unfinished proposal - https://wiki.mozilla.org/Accessibility/ARIAConflictsWithNativeMarkup I would suggest to get an agreement (at least between us) on this issue before we land the patch.
(In reply to comment #10) > I would suggest to get an agreement (at least between us) on this issue before > we land the patch. Of course. CC'ing Jamie too.
Here are the current "Global States and Properties" applicable to any element regardless of whether a role is applied: * aria-atomic * aria-busy (state) * aria-controls * aria-describedby * aria-disabled (state) * aria-dropeffect * aria-flowto * aria-grabbed (state) * aria-haspopup * aria-hidden (state) * aria-invalid (state) * aria-label * aria-labelledby * aria-live * aria-owns * aria-relevant
Note bug 474294 has some background. Note, I can accept it might be too soon to push my simple flexible agenda but not sure...
Note to self: file a bug about separating some role based behaviours out of our aria specific map.
Marco: NVDA doesn't report the state change because these are not focusable elements and NVDA only reports state changes for the currently focused element. This is a bit of a tricky issue because one tends to think of the buffer cursor as being a kind of "focus", even though the control underneath it may not necessarily be focused.
Treat grabbed and expanded as important statechange event worthy even without role="foo". Note, no new tests yet (we have some already for dragndrop).
Attachment #433995 - Flags: feedback?(surkov.alexander) → feedback+
Comment on attachment 433995 [details] [diff] [review] patch looks correct I look forward for the end version of the patch
Comment on attachment 434529 [details] [diff] [review] patch 1 (with tests) fine with me, r=me
Attachment #434529 - Flags: review?(surkov.alexander) → review+
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Verified fixed in Mozilla/5.0 (Windows; U; Windows NT 6.1; de; rv:1.9.3a4pre) Gecko/20100405 Minefield/3.7a4pre (.NET CLR 3.5.30729)
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.