Closed Bug 474340 Opened 17 years ago Closed 16 years ago

Change aria-grab to aria-grabbed

Categories

(Core :: Disability Access APIs, defect)

x86
Windows XP
defect
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla1.9.1b4

People

(Reporter: aaronlev, Assigned: davidb)

References

(Blocks 1 open bug)

Details

(Keywords: access, verified1.9.1)

Attachments

(1 file)

aria-grab has been changed to aria-grabbed and been given values that are more consistent with things like expanded/checked/pressed/selected. Currently: aria-grab, mapped to "grab" object attribute true:Indicates that the element has been "grabbed" for dragging. supported:Indicates that the element supports being dragged. false:Indicates that the element does not support being dragged. Proposed: aria-grabbed, mapped to "grabbed" object attribute true: element has been grabbed false: element has not been grabbed (but is grabbable) undefined (default): element is not grabbable, same as attribute not present or "" In addition, for backwards-compat, we should still expose grab attribute as we did before. We should map aria-grabbed values to "grab" as follow: true->true false->supported undefined,"" or not present->false
Do we really want to still support the deprecated way? If so, let's do it in a way that can be easily removed later.
I'll give this one a shot.
Assignee: nobody → david.bolter
Status: NEW → ASSIGNED
Wow, the user agent implementation guide doesn't currently talk about grab* at all. (http://www.w3.org/WAI/PF/aria-implementation/) I'm wondering if this is all dhtml author managed or if we need to do something ourselves. Aaron, adding the aria_grabbed atom is easy, and it is only used when looking for our sort of "last chance" reasons to build accessibles in nsAccessibilityService::GetAccessible (see also HasUniversalAriaProperty). If you can tell me why we need backwards compat, I'll try to figure out where to do the mapping from one aria attribute to another.
It's all author-managed. The UA guide doesn't need to say something about it, because it talks about what to do about generic attributes (map the to object attributes minus the aria- prefix and for NMTOKEN treat "undefined" as not present). Or at least I hope it says those things -- please check. We need backwards compat for JAWS 10, but if neither Dojo nor anything else we can find uses aria-grab then I'm game for skipping backwards-compat.
Attached patch simple fix.Splinter Review
Thanks Aaron, I would much rather go with simplicity, and consider backwards compat if someone asks for it.
Attachment #360726 - Flags: review?(marco.zehe)
Attachment #360726 - Flags: review?(marco.zehe) → review+
So there's some outreach necessary then. Otherwise people just discover it (or don't) when we ship and their code breaks. The main ones I'd be concerned with are YUI, JQuery UI, GWT and Dijit.
OK. I've done some outreach and this patch can be pushed. We can add backwards compat if others ask for it, thanks.
(In reply to comment #4) > The UA guide doesn't need to say something about it, because it talks about > what to do about generic attributes (map the to object attributes minus the > aria- prefix and for NMTOKEN treat "undefined" as not present). Or at least I > hope it says those things -- please check. It does.
Pushed on David's behalf in changeset: http://hg.mozilla.org/mozilla-central/rev/3e0f3d82822d
Status: ASSIGNED → RESOLVED
Closed: 16 years ago
Resolution: --- → FIXED
Comment on attachment 360726 [details] [diff] [review] simple fix. ARIA 1.0 change.
Attachment #360726 - Flags: approval1.9.1?
Attachment #360726 - Flags: approval1.9.1? → approval1.9.1+
Pushed to mozilla-1.9.1 on David's behalf in changeset: http://hg.mozilla.org/releases/mozilla-1.9.1/rev/ddf10d23da1c
Keywords: fixed1.9.1
Target Milestone: --- → mozilla1.9.1b4
Verified fixed in Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b4pre) Gecko/20090422 Shiretoko/3.5b4pre (.NET CLR 3.5.30729)
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: