Closed Bug 439205 Opened 16 years ago Closed 6 years ago

IAccessible2 role exposed as IA2_ROLE_UNKNOWN for child elements in lists styled as tables

Categories

(Core :: Disability Access APIs, defect)

1.9.0 Branch
x86
Windows XP
defect
Not set
normal

Tracking

()

RESOLVED WORKSFORME

People

(Reporter: Jamie, Unassigned)

References

(Blocks 2 open bugs)

Details

(Keywords: access, Whiteboard: [bk1])

Attachments

(1 file)

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9pre) Gecko/2008061105 Minefield/3.0pre
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9pre) Gecko/2008061105 Minefield/3.0pre

IAccessible2 role exposed as IA2_ROLE_UNKNOWN for child elements in lists styled as tables
Some pages create lists styled as tables; i.e. an "ul" tag with a style of "display: table" and child elements with a style of "display: table-row". An example of this is the list of useful links in Bugzilla at the bottom of the page (id "useful-links"; starting with the "Actions:" list). Where this occurs, calling IAccessible2::role() on the list object returns ROLE_SYSTEM_LIST, but IAccessible2::role() on the child accessible objects returns a role of IA2_ROLE_UNKNOWN (0). The list object returns its real role (ROLE_SYSTEM_LIST), so the real roles of the child objects should therefore also be returned (ROLE_SYSTEM_LISTITEM, etc.).

Reproducible: Always

Steps to Reproduce:
1. Open the provided test case.
2. Examine the role returned by IAccessible2::role() for the list object. Observe that it is ROLE_SYSTEM_LIST.
3. Examine the role returned by IAccessible2::role() for each of the children of the list.
Actual Results:  
The role for the "list item" and "div" objects is IA2_ROLE_UNKNOWN. The "list item with forced aria role" object has a role of ROLE_SYSTEM_LISTITEM.

Expected Results:  
The role should not be IA2_ROLE_UNKNOWN for any of the objects. "list item" should probably have a role of ROLE_SYSTEM_LISTITEM and "div" should probably have a role of IA2_ROLE_SECTION.

Note that the ARIA role override on the "list item with forced aria role" object works correctly.
Keywords: access
Version: unspecified → 1.9.0 Branch
Attached file Test case.
This sample demonstrates a list styled as a table containing several children styled as table rows.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Blocks: 191a11y
Often (for HTML) we take decision what accessible to create based on frame type
(rendered object type). So if you use display style then I would assume we
should create table accessibles in this case (note we don't do it for html:ul).
What do you think?
(In reply to comment #2)
> Often (for HTML) we take decision what accessible to create based on frame type
> (rendered object type). So if you use display style then I would assume we
> should create table accessibles in this case (note we don't do it for html:ul).
My primary concern is that this is consistent and that we never see IA2_ROLE_UNKNOWN. If it is decided that the list should be exposed as a table, its children should be exposed as if they were children of a table. The same goes for exposing the list as a list.

As to the choice itself, it is probably best to consider the use cases and the reason for their use of this styling. It would be good to query the Bugzilla developers as to why they chose to do this and then make a decision on that basis.
Marco, any news from bugzilla guys?
Depends on: 513662
Blocks: 513662
No longer depends on: 513662
No longer blocks: 191a11y
Sill occur with the test case.
Whiteboard: [bk1]
Jamie, related question: what hierarchy is expected for 

<table role="button">
 <tr><td>cell</td></tr>
</table>

does it make sense to expose table interface on the table?
(In reply to alexander :surkov from comment #7)
> <table role="button">
>  <tr><td>cell</td></tr>
> </table>
> does it make sense to expose table interface on the table?
This is a corner case and is thus somewhat controversial. My gut feeling is that the table interface shouldn't be exposed - button and table semantics don't really fit together. However, I'm sure someone could make a pretty convincing counter-argument.
Ok, I agree, we had a precedent, bug 494807.
(In reply to James Teh [:Jamie] from comment #8)
> (In reply to alexander :surkov from comment #7)
> > <table role="button">
> >  <tr><td>cell</td></tr>
> > </table>
> > does it make sense to expose table interface on the table?
> This is a corner case and is thus somewhat controversial. My gut feeling is
> that the table interface shouldn't be exposed - button and table semantics
> don't really fit together. However, I'm sure someone could make a pretty
> convincing counter-argument.

I lean towards that we should expose table interface (aka presentational table) but no table related roles on table element and its descendants. Visually that button's content is aligned as a table and I don't see a good reason to hide that from AT.
This test case now behaves consistently (exposes list and list items). Perhaps fixed by bug 804461.
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: