Hey, So while working on https://bugzilla.gnome.org/show_bug.cgi?id=634642 I've run in to n issue with the way we present the position in a menu. Originally We would look at all the children of the items parent and try to gues what the correct position was. We have to gues, because the menu contains spacer objects that people don't really want counted. The problem with this that we often get it wrong in the bug Attila provided the example of the message list in thunderbird, I noticed the edit menu in firefox. When I started using attributes (posinset and setsize) mozilla gives us to fix the mentioned bug we started using the attributes to figure out where we are in a menu too. That would be fine accept Mozilla menus seem to have a concept of groups of options (I'm not sure of the technical term that applies) for example in the file menu print and print preview are a group, and the options related to opening pages tabs and closing pages and tabs are another group. The attributes we ue to get our position in the list are based on the "item groups" so for the first six items in the file menu you see position x of 6 then if you keep going down to the next group you see y of 3 etc. I'm not sure if there is a reason these attributes work this way or not, or if they could be changed to reflect the number of selecttable items in the menu which I believe is the number people want here. https://developer.mozilla.org/en/Accessibility/AT-APIs/Gecko/Attrs#Group_Attributes makes it seem like these attributes are doing what they should, but the definition of a "group" isn't very clear, so perhaps the menu could be considered the "group". I'll probably see what Mozilla people think about this, but in the mean time this is the way the world will almost certianly be through firefox 4 and xulrunner 2.0. The following is a discussion I had with Jamie one of the nvda developers about what they do with this situation. < tbsaunde> fer: now we have the problem in orca that people want the total number of things in the menu not just that part < Jamie> tbsaunde: that is a huge can of worms < Jamie> tbsaunde: technically, that should include separators, but people never want those < Jamie> we've had this argument with NVDA users before :) <@fer> Jamie: I only tested it closed < tbsaunde> Jamie: yup, I know, orca used to get the parent, then look through all the children, but that's very slow for say a thunderbird message box, so we want to use the attributes, but the easiest way to do that results in using them for menus too < tbsaunde> Jamie: what did nvda do? < Jamie> fer: ok, but when it's closed, there are two objects in question: the select itself and the options < Jamie> fer: I assume you're asking me about the options <@fer> Jamie: yes < Jamie> tbsaunde: we use the position info from the API, which in your case is the attributes < Jamie> tbsaunde: we used to use the child count provided by MSAA< but that included separators which irritated users < tbsaunde> Jamie: ok, what is it in windows, I'm curious and don't know anything about how things work there < Jamie> so we ended up just taking it out and not including item counts at all unless the API provided accurate counts < Jamie> then, of course, people whinged, so we put in an option to "Guess object position information when unavailable" < Jamie> disabled by default So, I can see a couple reasonable solutions to this. - we can go back to the old guesing algorithm for menus, which isn't hard, but its often broken. - we can present the information that the posinset and setsize attributes give us, and you will have the position in a group, but not exactly the menu. - we can just stop trying to speak position in menus, or add more options to explicitly trun it on to either of the methods mentioned before. I'm not very clear on what benefits this would have over the solutions mentioned before, but its not really clear why you would want to know the position in a menu either. - we could do something else, that I haven't thought of if someone has a different idea. Trev
Attachment:
signature.asc
Description: Digital signature