Closed
Bug 441888
Opened 16 years ago
Closed 16 years ago
ARIA checked menu items are not included in the total list of menu items
Categories
(Core :: Disability Access APIs, defect)
Tracking
()
VERIFIED
FIXED
mozilla1.9.1a1
People
(Reporter: gibson.becky, Assigned: surkov)
References
()
Details
(Keywords: access)
Attachments
(1 file, 1 obsolete file)
6.05 KB,
patch
|
MarcoZ
:
review+
|
Details | Diff | Splinter Review |
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9) Gecko/2008052906 Firefox/3.0pre
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9) Gecko/2008052906 Firefox/3.0pre
The example url has a context menu with 11 items. The first 8 are standard menuitems, the last three are checkable menuitems. The Accessible description for the first 8 are "x of 8" where x is the position of the menuitem in the list of items. There is no description for the 3 checkable menuitems. Since they are included within the same menu, they should also be counted.
Note that you can also substitute "nightly" in the above url in place of "dojo-2008-06-25" to get the most up to date test file if you are brave.
Reproducible: Always
Steps to Reproduce:
1.Open inspect32 or other tool to view MSAA information - set it up to track keyboard focus
2.Open the above url
3. put focus in the first text box on the page
4. press shift-F10 to bring up the context menu.
5. arrow down to the menu item "cut", notice that the description in IA2 is listed as "4 of 8"
6. arrow down to the menu item labeled "checked", notice that there is no description. I think it should be "9 of 11"
Expected Results:
description for "checked" menu item should be "9 of 11"
Updated•16 years ago
|
Component: Disability Access → Disability Access APIs
Product: Firefox → Core
QA Contact: disability.access → accessibility-apis
Version: unspecified → 1.9.0 Branch
Comment 1•16 years ago
|
||
Confirmed.
Becky, is there a separator below the 8th menu item (where it stops counting) and above the checkable items?
I've done a test on the regular Firefox View menu, and noticed that I'm getting a higher count (13 items in my case) than are actually visible, and I am wondering whether we are counting separators in this case, but on the sample page, are thinking that at the separator, the menu ends.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Comment 2•16 years ago
|
||
For any changes we make to ARIA processing, please update this doc:
http://developer.mozilla.org/en/docs/ARIA_User_Agent_Implementors_Guide
Assignee | ||
Comment 3•16 years ago
|
||
Assignee: nobody → surkov.alexander
Status: NEW → ASSIGNED
Assignee | ||
Comment 4•16 years ago
|
||
Attachment #326879 -
Attachment is obsolete: true
Attachment #326885 -
Flags: review?(marco.zehe)
Assignee | ||
Updated•16 years ago
|
Flags: in-testsuite+
Comment 5•16 years ago
|
||
Is this patch meant to stop counting on a snormal separator, for example as seen in Firefox's "View" menu?
Because with this patch applied, it still has 13 items (10 items plus 3 separators), and the description still says "1 of 13, 2 of 13, 3 of 13, 5 of 13".
Status: ASSIGNED → RESOLVED
Closed: 16 years ago
Resolution: --- → FIXED
Reporter | ||
Comment 6•16 years ago
|
||
In answer to the question of the separators. The are three separators in the menu. There are two which are not counted (based on the code when I submitted the bug) within the first 8 items. In other words, there are eight actual menu items and 2 separators. Then there is a separator created in the same manner as the others, then the 3 checkable menu items. I don't think that separators should be counted since they are never navigated to.
Assignee | ||
Comment 7•16 years ago
|
||
Technically in the example those separators aren't separators in a11y terms (they haven't role separator and they are exposed as role nothing). I really haven't idea why they are counted (because we count only accessibles with the same role). So the question is for Becky: what the difference is between our example in mochitest (see the patch2) and your example?
Marco, why the bug is fixed?
Comment 8•16 years ago
|
||
(In reply to comment #7)
> Technically in the example those separators aren't separators in a11y terms
> (they haven't role separator and they are exposed as role nothing). I really
> haven't idea why they are counted (because we count only accessibles with the
> same role). So the question is for Becky: what the difference is between our
> example in mochitest (see the patch2) and your example?
Alex, the ARIA menu that Becky linked to now works correctly with your patch, it counts 11 items.
However, in our own View menu, we also count the separators. Look at the "View" menu in DOM inspector. The patch hasn't changed that, although I thought it would. Or did you not intend to also change regular menus that have separator accessibles?
> Marco, why the bug is fixed?
With your patch, the ARIA bug is indeed fixed. I am just wondering whether this patch also should address regular menus or not.
Assignee | ||
Comment 9•16 years ago
|
||
No, it shouldn't address the original xul:menu, please file another bug for this.
Marco, did you land the patch if you marked it as fixed? You didn't set r+ in any way and fixed looks strange :)
Comment 10•16 years ago
|
||
Oops, thanks for the pointer! I must have accidentally hit that radio button somehow.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Updated•16 years ago
|
Status: REOPENED → NEW
Comment 11•16 years ago
|
||
Comment on attachment 326885 [details] [diff] [review]
patch2
r=me
Attachment #326885 -
Flags: review?(marco.zehe) → review+
Comment 12•16 years ago
|
||
Pushed to mozilla-central in changeset:
http://hg.mozilla.org/mozilla-central/index.cgi/rev/e4d8bb043ef7
Status: NEW → RESOLVED
Closed: 16 years ago → 16 years ago
Resolution: --- → FIXED
Comment 13•16 years ago
|
||
Verified fixed in Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1a1pre) Gecko/2008062804 Minefield/3.1a1pre.
Status: RESOLVED → VERIFIED
Updated•16 years ago
|
Target Milestone: --- → mozilla1.9.1a1
You need to log in
before you can comment on or make changes to this bug.
Description
•