Right now, we're just using placeholder roles (e.g "ROLE_AUTOCOMPLETE"). The role map should be updated to use UA roles.

This is basically going by the role comparisons (between ATK/MSAA and UA) done at http://wiki.mozilla.org/index.php?title=Accessibility/Comparisons:Roles The roles I cannot decide on (yet), I'll make AXUnknown.

I'm using the knowledge gathered from the comparisons, but there are still some question marks. Any input appreciated. * ROLE_ALERT Are we talking dialogs, or can this be something on a webpage? * ROLE_CLIENT Is this useful? If there's one per iframe, or one per window, can we merge it (internally) with some other similar role? * ROLE_INDICATOR * ROLE_SPLITBUTTON * ROLE_GLASS_PANE * ROLE_HTML_CONTAINER * ROLE_INTERNAL_FRAME * ROLE_VIEWPORT * ROLE_EMBEDDED * ROLE_EDITBAR * ROLE_PARENT_MENUITEM Anyone know what these are, and how they're used? * ROLE_SECTION By the way, how do we determine what a section is? Thanks!

Also look at http://msdn.microsoft.com/library/en-us/msaa/msaaccrf_4nub.asp?frame=true and http://developer.gnome.org/doc/API/2.0/atk/AtkObject.html > * ROLE_ALERT Can be an alert window or part of a web page that appears to provide an alert. See http://www.mozilla.org/access/dhtml/alert > * ROLE_CLIENT It's not really useful, but I'm not sure how any merging would occur or what that would gain us. > * ROLE_INDICATOR Unused for the moment. Can be used for the slider thumb. > * ROLE_SPLITBUTTON Like a "Back" button in the toolbar with a dropdown child button. > * ROLE_GLASS_PANE Just treat as any panel > * ROLE_HTML_CONTAINER I don't think we'll use this -- can treat as document > * ROLE_INTERNAL_FRAME Don't know > * ROLE_VIEWPORT Seems redundant with other roles > * ROLE_EMBEDDED We should remove this from nsIAccessible > * ROLE_EDITBAR Unused for now -- just a textfield > * ROLE_PARENT_MENUITEM It's a menuitem that has child menuitems > Anyone know what these are, and how they're used? > > * ROLE_SECTION a <div>

Here's the initial version of the role conversion table from XP roles to mac-only roles. I've used the comparison tables as my initial data. Then I filled in the holes -- mostly using the AXUnknownRole for many roles, and AXGroupRole for many different kind of panes/sections etc. AXGroupRole seems to be used a lot in Safari to for things on webpages (probably stuff like DIVs); it's not that descriptive, but at least it's not totally "unknown", so it will do for now for some elements.

Here are some Obj-C++ changes that are needed in order to not use the hardcoded role names such as "mozRootAccessible" and "mozDocAccessible" for the root and doc accessibles. * I just threw out the mozDocAccessible (obj-c) class since I don't use it for anything right now. * There's a small hack needed to mozRootAccessible, so that it 1) returns the right "official" role to ATs while still 2) being distinguishable for ChildView. ChildView needs to be able to tell if an element is a root accessible.

Comment on attachment 238202 [details] [diff] [review] Changes needed to throw out old, hardcoded roles. >+- (id)accessibilityAttributeValue:(NSString*)attribute >+{ >+ // Handle the role attribute (before mozAccessible does it for us). >+ // mozAccessible would return whatever our |role| impl returns, which in our case >+ // is "mozRootAccessible". >+ // However, we can't use that as our official role, if an AT asks us. >+ // We still want |role| to return "mozRootAccessible" because that's how >+ // ChildView can recognize the root accessible. >+ if ([attribute isEqualToString:NSAccessibilityRoleAttribute]) { >+ return [super role]; >+ } >+ >+ // not the role attr, so let the superclass take care of it. >+ return [super accessibilityAttributeValue:attribute]; >+} >+ I was impressed. Does object-c++ hasn't virtual functions mechanism? It's not nice if you will override accessibilityAttributeValue method for every object that will be inhirited from mozAccessible. Question. If I have inheritance chain: base -> middle -> top. If I use 'super' before method in top class then method will be called for base or for middle?

(In reply to comment #6) > (From update of attachment 238202 [details] [diff] [review] [edit]) > > >+- (id)accessibilityAttributeValue:(NSString*)attribute > >+{ > >+ // Handle the role attribute (before mozAccessible does it for us). > >+ // mozAccessible would return whatever our |role| impl returns, which in our case > >+ // is "mozRootAccessible". > >+ // However, we can't use that as our official role, if an AT asks us. > >+ // We still want |role| to return "mozRootAccessible" because that's how > >+ // ChildView can recognize the root accessible. > >+ if ([attribute isEqualToString:NSAccessibilityRoleAttribute]) { > >+ return [super role]; > >+ } > >+ > >+ // not the role attr, so let the superclass take care of it. > >+ return [super accessibilityAttributeValue:attribute]; > >+} > >+ > > I was impressed. Does object-c++ hasn't virtual functions mechanism? It's not > nice if you will override accessibilityAttributeValue method for every object > that will be inhirited from mozAccessible. Objective-C methods are virtual by default. Note that mozRootAccessible is a *subclass* of mozAccessible. So if I override something in mozRootAccessible, that will override the mozAccessible method, only for the mozRootAccessible-object. > > Question. If I have inheritance chain: base -> middle -> top. If I use 'super' > before method in top class then method will be called for base or for middle? > [super foo] will call 'foo' on the first superclass that implements the method. So in our case, that is mozAccessible.

I have too many questions instead notes. Probably some questions about role using is more targeted to Aaron. Can you give me a link on man controls references, where I can see how they look? The accessiblbe doc assumes I know about controls. What's difference between 'irrelevant' and 'unused'? If nsRoleMap.h contains roles for for OS X only then it doesn't make sence to write 'on OS X' every time. What does 'windows are always native' comment mean? > NSAccessibilityMenuBarRole, // ROLE_MENUBAR. (irrelevant on OS > X; the menubar will always be native and on the top of the screen.) If ROLE_MENUBAR has related mac's role then why is it irrelevant? > NSAccessibilityUnknownRole, // ROLE_ALERT Does it mean mac 3d party softwares can't handle alert messages? > @"AXHelpTag", // ROLE_TOOLTIP. 10.4+ only, so > we re-define the constant. Does mac haven't predefined constant for this role? I don't see NSAccessibilityGroupRole in http://developer.apple.com/documentation/Accessibility/Conceptual/AccessibilityMacOSX/index.html?http://developer.apple.com/documentation/Accessibility/Conceptual/AccessibilityMacOSX/OSXAXRoleReference/chapter_7_section_2.html#//apple_ref/doc/uid/TP40001078-CH211-DontLinkElementID_8. Where can I find it? It seems ROLE_DOCUMENT doesn't match exactly to NSAccessibilityGroupRole. What's specific element with ROLE_DOCUMENT has in difference from NSAccessibilityGroupRole? What elements has ROLE_PAGETAB, ROLE_PROPERTYPAGE role? > NSAccessibilityUnknownRole, // ROLE_INDICATOR If mac hasn't element for ROLE_INDICATOR then how slider widgets are handler by mac accessibility? Probably should NSAccessibilitySliderRole be used? What's difference between ROLE_COMBOBOX and ROLE_DROPLIST? > NSAccessibilityProgressIndicatorRole, // ROLE_PROGRESSBAR It looks like ROLE_PROGRESSBAR is used for determined and undetermined progressbars but mac provides different roles for these progressbars. Why NSAccessibilityProgressIndicatorRole was choosed? > NSAccessibilityUnknownRole, // ROLE_DIAGRAM Can't NSAccessibilityImageRole handle ROLE_DIAGRAM (and probably ROLE_ANIMATION)? > NSAccessibilityPopUpButtonRole, // ROLE_BUTTONDROPDOWN Docs says: "Pop-Up Button Role. An accessibility object of the pop-up button role is a pop-up menu." Why this role can be used for ROLE_BUTTONDROPDOWN? How is ROLE_BUTTONDROPDOWNGRID used? > NSAccessibilityUnknownRole, // ROLE_IPADDRESS What controls is used this role? If control is editable control then probably is Text Field Role more suitable? > NSAccessibilityUnknownRole, // ROLE_CANVAS Does Drawer Role not work here?

(In reply to comment #7) > (In reply to comment #6) > > (From update of attachment 238202 [details] [diff] [review] [edit] [edit]) > > > > >+- (id)accessibilityAttributeValue:(NSString*)attribute > > >+{ > > >+ // Handle the role attribute (before mozAccessible does it for us). > > >+ // mozAccessible would return whatever our |role| impl returns, which in our case > > >+ // is "mozRootAccessible". > > >+ // However, we can't use that as our official role, if an AT asks us. > > >+ // We still want |role| to return "mozRootAccessible" because that's how > > >+ // ChildView can recognize the root accessible. > > >+ if ([attribute isEqualToString:NSAccessibilityRoleAttribute]) { > > >+ return [super role]; > > >+ } > > >+ > > >+ // not the role attr, so let the superclass take care of it. > > >+ return [super accessibilityAttributeValue:attribute]; > > >+} > > >+ > > > > I was impressed. Does object-c++ hasn't virtual functions mechanism? It's not > > nice if you will override accessibilityAttributeValue method for every object > > that will be inhirited from mozAccessible. > > Objective-C methods are virtual by default. Note that mozRootAccessible is a > *subclass* of mozAccessible. So if I override something in mozRootAccessible, > that will override the mozAccessible method, only for the > mozRootAccessible-object. Sorry, I misreaded the code. Why does mozRootAccessible override 'role' method, why 'role' returns rather the "mozRootAccessible" than role from nsRoleMap.h and why do you like to use native gecko role instead of role of mozRootAccessible?

(In reply to comment #9) > (In reply to comment #7) > > (In reply to comment #6) > > > (From update of attachment 238202 [details] [diff] [review] [edit] [edit] [edit]) > > > > > > >+- (id)accessibilityAttributeValue:(NSString*)attribute > > > >+{ > > > >+ // Handle the role attribute (before mozAccessible does it for us). > > > >+ // mozAccessible would return whatever our |role| impl returns, which in our case > > > >+ // is "mozRootAccessible". > > > >+ // However, we can't use that as our official role, if an AT asks us. > > > >+ // We still want |role| to return "mozRootAccessible" because that's how > > > >+ // ChildView can recognize the root accessible. > > > >+ if ([attribute isEqualToString:NSAccessibilityRoleAttribute]) { > > > >+ return [super role]; > > > >+ } > > > >+ > > > >+ // not the role attr, so let the superclass take care of it. > > > >+ return [super accessibilityAttributeValue:attribute]; > > > >+} > > > >+ > > > > > > I was impressed. Does object-c++ hasn't virtual functions mechanism? It's not > > > nice if you will override accessibilityAttributeValue method for every object > > > that will be inhirited from mozAccessible. > > > > Objective-C methods are virtual by default. Note that mozRootAccessible is a > > *subclass* of mozAccessible. So if I override something in mozRootAccessible, > > that will override the mozAccessible method, only for the > > mozRootAccessible-object. > > Sorry, I misreaded the code. Why does mozRootAccessible override 'role' method, > why 'role' returns rather the "mozRootAccessible" than role from nsRoleMap.h > and why do you like to use native gecko role instead of role of > mozRootAccessible? > It calls mozAccessible's |role| method (which will look up the role in nsRoleMap.h) I want to use a native role because the role name "mozRootAccessible" doesn't exist, it's just something I made up for testing purposes.

Please note that if some role is wrong, it's very easy to improve these constants as we go. (In reply to comment #8) > I have too many questions instead notes. Probably some questions about role > using is more targeted to Aaron. > > Can you give me a link on man controls references, where I can see how they > look? The accessiblbe doc assumes I know about controls. Sorry, I can't know a reference about this. You can try screenshots on google, but there really is no good substitute to using the OS ... :/ > > What's difference between 'irrelevant' and 'unused'? If nsRoleMap.h contains > roles for for OS X only then it doesn't make sence to write 'on OS X' every > time. It's essentially the same thing, just different words... > > What does 'windows are always native' comment mean? That the accessibility of windows are always handled by the system, so those roles will never be used. > > > NSAccessibilityMenuBarRole, // ROLE_MENUBAR. (irrelevant on OS > X; the menubar will always be native and on the top of the screen.) > > If ROLE_MENUBAR has related mac's role then why is it irrelevant? Because it is handled by the system. On OS X, the menubar is not on every window (like on win/linux), it is always at the top, and you cannot make "your own" menubar. The role is used by the system. > > > NSAccessibilityUnknownRole, // ROLE_ALERT > > Does it mean mac 3d party softwares can't handle alert messages? Windows/Alerts are handled by the system. There's no role (yet) for AJAX-style alerts. > > @"AXHelpTag", // ROLE_TOOLTIP. 10.4+ only, so > we re-define the constant. > > Does mac haven't predefined constant for this role? There's a NSAccessibilityHelpTagRole constant defined but only in the 10.4 headers and later. We are compatible with 10.3, so we can't use the constant, but we can use its value. That way we're not relying on the headers to be there... > I don't see NSAccessibilityGroupRole in http://developer.apple.com/documentation/Cocoa/Reference/ApplicationKit/Protocols/NSAccessibility_Protocol/Reference/Reference.html > It seems ROLE_DOCUMENT doesn't match exactly to NSAccessibilityGroupRole. > What's specific element with ROLE_DOCUMENT has in difference from > NSAccessibilityGroupRole? > > What elements has ROLE_PAGETAB, ROLE_PROPERTYPAGE role? XUL tabs. You can use LXR to see exactly what tags they are used for. > > NSAccessibilityUnknownRole, // ROLE_INDICATOR > If mac hasn't element for ROLE_INDICATOR then how slider widgets are handler by > mac accessibility? Probably should NSAccessibilitySliderRole be used? ROLE_INDICATOR is still unused, according to LXR. That's why I asked Aaron in comment 2 what it did. See comment 3 for the response. It's not a slider, if it is only the "thumb" (dragging part) of a scrollbar, for example.. so we'll use unknown for now. > What's difference between ROLE_COMBOBOX and ROLE_DROPLIST? Not sure.. > > NSAccessibilityProgressIndicatorRole, // ROLE_PROGRESSBAR > It looks like ROLE_PROGRESSBAR is used for determined and undetermined > progressbars but mac provides different roles for these progressbars. Why > NSAccessibilityProgressIndicatorRole was choosed? Not sure what you mean. Is there really XP roles for both undetermined/determined progressbars? > > NSAccessibilityUnknownRole, // ROLE_DIAGRAM > Can't NSAccessibilityImageRole handle ROLE_DIAGRAM (and probably > ROLE_ANIMATION)? I guess they could... although a diagram is more describing the content and doesn't have to be an "image", as I understand it... > > > NSAccessibilityPopUpButtonRole, // ROLE_BUTTONDROPDOWN > Docs says: "Pop-Up Button Role. An accessibility object of the pop-up button > role is a pop-up menu." > Why this role can be used for ROLE_BUTTONDROPDOWN? I think a buttondropdown is similar to a popupbutton: you get like a "menu" but with other buttons. Am I wrong? > How is ROLE_BUTTONDROPDOWNGRID used? As there is no substitute for it on OS X, I'm not sure which role to use yet. It's better to use unknown for now, and adjust when we can test it more. > > NSAccessibilityUnknownRole, // ROLE_IPADDRESS > What controls is used this role? If control is editable control then probably > is Text Field Role more suitable? Aaron said it's unused so far. It seems to be windows only. I have no idea what it is, so I'll use unknown. > > NSAccessibilityUnknownRole, // ROLE_CANVAS > Does Drawer Role not work here? No, a drawer is like a child window - it doesn't have anything to do with drawing/painting.

Comment on attachment 238201 [details] [diff] [review] Initial mac-only rolemap I have a feel not all mac roles are related right with mozilla roles. But idea to use predefined constants instead string is right. I guess you should write many tests to see how these relations are going. But all inconsistents can be fixed in follow-up bugs.

This patch avoid the ugly role-method hack, and simply implements a |isRoot| method in the mozAccessible protocol. Alex, please review the accessible/ part.

Comment on attachment 238613 [details] [diff] [review] Changes needed, v2 Josh, I'm updating a few lines of a11y code in nsChildView to reflect a simple change: there's now a |-(BOOL)isRoot| method that can be called on all mozAccessibles, instead of comparing role names with hardcoded strings. Please review the widget/ part. Thanks!

Comment on attachment 238613 [details] [diff] [review] Changes needed, v2 Accessible part looks good (though, at my sight the other one is too). My formal r+.

Checked in to trunk.