User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:5.0) Gecko/20100101 Firefox/5.0
Build Identifier: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:5.0) Gecko/20100101 Firefox/5.0
Sometimes IAccessible2::role() can give back a role of 0 on tables and table cells. I did not see this occure in Firefox 4, but do see it in Firefox 5 and 6. Not sure about 7.
An impact of this is that NVDA no longer renders this content in its virtualBuffer at all, and object navigation becomes problematic.
The only place I have seen this bug occure so far is when trying to edit the page at:
You will need to create a free wikispaces account first before you can edit the page.
All the edit controls are inside a table that exibits this bug.
Steps to Reproduce:
1. In Firefox go to http://nvda.wikispaces.org/ and sign in if necessary (a free wikispaces account is needed).
2. Click the "edit" link near the top of the page to start editing the NVDA - Home wiki page.
3. Tab to one of the editing controls such as the cancel button.
4. With an a11y inspection tool, or NVDA object navigation, note that the IAccessible2 role of the control's parent IAccessible is 0 (unknown). Also note if using NVDA that none of the editing controls appear in the virtualBuffer.
IAccessible2::role() gives back 0 and NVDA cannot render this content.
IAccessible2::role() should give back ROLE_SYSTEM_CELL or ROLE_SYSTEM_TABLE (depending on the actual object). NVDA should also render all the controls in its virtualBuffer.
Correction, the bug is in firefox 4, sorry about that.
Also, I have tracked it down to:
If a table is focusable (say with tabindex="0" for example) [the table on nvda.wikispaces.org is focusable, not sure how though] and the table has role="presentation", the table and its cells are still represented in the accessibility tree, but they all have an IAccessible2 role of 0.
I would like to understand why an aria role of presentation forces role to 0. If it is that role="presentation" nodes do not get filtered out of the accessibility tree if they are focusable, then they also need to maintain their original role. Otherwise ATs such as NVDA will refuse to render them properly, or in this case not at all.
Mick, what is a bug
1) presentation role should be ignored on presentation element or
2) the table at wiki is focusable while it shouldn't be?
Although I do not really understand the logic behind forcing the role to 0 on nodes with aria role presentation, I have worked around this in NVDA.
This bug can be closed as invalid if others do not feel that this is problematic.
However, I will point out the following:
* Why mutate the role to 0 yet keep things like accessibleTable (row and column counts etc) available?
* Why does setting aria role of presentation on a "table" node also cause the cells of the table ("TD" nodes) to also get a role of 0? This is one reason why NVDA now has to descend in to all unknowns (role of 0) rather than perhaps just unknowns with an object attribute of role:presentation -- because the table cells in this example do not have role:presentation but do have a role of unknown (0).
* If Gecko chooses not to filter out nodes with an aria role of presentation because they are focusable, I would assume this is because the node then obviously must have some importance. However, the node is not very useful because its role is now lost.
Mick, as I said on irc I think it's reasonable to keep role from markup when role presentation is used on focusable element, in other words, ignore role presentation on focusable nodes. Actually I agree that'll be a fix for the bug.
But I still wonder if focuable table in your example is expected and correct thing or that's a bug too.
(In reply to comment #3)
> * Why does setting aria role of presentation on a "table" node also cause
> the cells of the table ("TD" nodes) to also get a role of 0?
because cells make sense in context of the table, otherwise they are just text container and this is considered as wrong markup.
Created attachment 541607 [details]
test html file with a focusable table with an aria role of presentation
I have attached a testcase (html file containing a focusable table with an aria role of presentation). It has been made focusable with tabIndex="-1". Notice the table, header and cells are all role_unknown.
Re whether this is really an authoring bug: I'd probably think it was. I shal report this to wikispaces and see if they can take the tabIndex off the table.
Created attachment 541611 [details] [diff] [review]
(In reply to comment #7)
> Re whether this is really an authoring bug: I'd probably think it was. I
> shal report this to wikispaces and see if they can take the tabIndex off the
Ok, thank you.
changing summary to better reflect this bug is about.
Comment on attachment 541611 [details] [diff] [review]
I wasn't asked for review, but does it make a difference to also test an usually non-focusable item made focusable by tabindex="0" additionally to one that *is* focusable by its very nature (like the button)? I would just like to see this covered.
(In reply to comment #11)
> Comment on attachment 541611 [details] [diff] [review] [review]
> I wasn't asked for review,
Marco, even if you weren't asked you always can do review or do comments as module peer and assignee must address your concerns.
The patch is trivial so probably two reviewers is too much. But thank you for looking into!
> but does it make a difference to also test an
> usually non-focusable item made focusable by tabindex="0" additionally to
> one that *is* focusable by its very nature (like the button)? I would just
> like to see this covered.
if you like. Should it be a test of focusable table tree hierarchy?
Comment on attachment 541611 [details] [diff] [review]
r=me since this is an edge case. I don't think there is a perfect solution for all use cases.
> if you like. Should it be a test of focusable table tree hierarchy?
Yes, you can base it on Mick's testcase or use something simpler that gives us good test coverage here. I'd just like to be safe on this.
Created attachment 542722 [details] [diff] [review]
(In reply to comment #13)
> r=me since this is an edge case. I don't think there is a perfect solution
> for all use cases.
I didn't understand about edge case.
Comment on attachment 542722 [details] [diff] [review]
Thanks, that's what I had in mind! r=me
pushed to try with 666504 606085 666337 429642 667396 as http://tbpl.mozilla.org/?tree=Try&rev=dbf9bbf7adc9