Closed
Bug 525909
Opened 15 years ago
Closed 12 years ago
Support ARIA role "rowgroup"
Categories
(Core :: Disability Access APIs, defect, P2)
Core
Disability Access APIs
Tracking
()
RESOLVED
FIXED
mozilla19
People
(Reporter: davidb, Assigned: surkov)
References
(Blocks 1 open bug)
Details
(Keywords: access)
Attachments
(2 files, 1 obsolete file)
Member only: http://www.w3.org/WAI/PF/Group/track/issues/372
"There might be problems introducing the rowgroup role, we need to test impacts on existing implementation prior to ARIA 2nd LC"
We should add mochitests (and possible implementation), to make sure that if rows are contained in an element with role="rowgroup" that nothing breaks horribly. If this new role is something that breaks us for 3.6 we should request pushing it to ARIA 2.0.
Reporter | ||
Comment 1•15 years ago
|
||
Would be good to know what happens in the case of role="group" as well.
Comment 2•15 years ago
|
||
Simple testcase showing what I think is meant.
Testing shows with AccProbe that whether the div has a role of rowgroup or not does not make any difference to Minefield or Namoroka. The table interface yields the same result in both cases.
Note that there is also no accessible being created for the rowgroup. The rows inside the rowgroup div appear to be at the same level as the others.
Reporter | ||
Comment 3•15 years ago
|
||
Just to be clear, the node with role=rowgroup is not in the accessible tree at all?
Comment 4•15 years ago
|
||
(In reply to comment #3)
> Just to be clear, the node with role=rowgroup is not in the accessible tree at
> all?
Correct!
Comment 5•15 years ago
|
||
When I just did the change from "rowgroup" to "group", I now see what happens:
1. With the div having a role of "rowgroup", a "section" node is being created on the same level as the table. So the document accessible has two children: An empty section and the table.
2. When changing this to "group", the doucment also gets two children: a grouping and the table. Inside the table, the hierarchy is the same in both cases: The table has 4 rows as children, with each having cell children of their own again.
So for some reason, we're creating accessibles outside the table hierarchy if the node appears inside the table but we don't expect it there.
Reporter | ||
Comment 6•15 years ago
|
||
We should check it against the DOM which I will do as soon as I catch my breath.
Reporter | ||
Comment 7•15 years ago
|
||
Yep that matches the DOM so I think we are doing the right thing. We should get this into suite so that we can tell if/when behaviour changes.
Assignee | ||
Comment 8•15 years ago
|
||
(In reply to comment #0)
> Member only: http://www.w3.org/WAI/PF/Group/track/issues/372
>
> "There might be problems introducing the rowgroup role, we need to test impacts
> on existing implementation prior to ARIA 2nd LC"
>
> We should add mochitests (and possible implementation), to make sure that if
> rows are contained in an element with role="rowgroup" that nothing breaks
> horribly. If this new role is something that breaks us for 3.6 we should
> request pushing it to ARIA 2.0.
Yes, it breaks. Now our implementation allows ARIA trees to use group to bring hierarchy. However we could support rowgroups in ARIA treegrid in timeframe of Firefox 3.7 I think. However could you clarify why does ARIA need new role and is role="group" not suitable for ARIA treegrid?
Reporter | ||
Comment 9•15 years ago
|
||
From the current spec:
rowgroup
A group containing one or more row elements in a grid.
The rowgroup role establishes a relationship between owned row elements. It is a structural equivalent to the thead, tfoot, and tbody elements in an HTML table element.
Note: This role does not differentiate between types of row groups (e.g. thead vs. tbody), but an issue has been raised for WAI-ARIA 2.0.
Assignee | ||
Comment 10•15 years ago
|
||
Ah, that's interesting. I thought it's analogue of ARIA group in ARIA trees but I was wrong.
Good news, we don't need to support ARIA rowgroup at all ;)
1) We don't expose thead and etc
2) "establishes a relationship" is too diluted to consider this as implementation manual.
Reporter | ||
Comment 11•15 years ago
|
||
OK :)
Let's keep this low priority until/unless someone asks for it.
Priority: -- → P5
Assignee | ||
Comment 12•14 years ago
|
||
Per discussion with Rich we should expose it as role="group" and use member_of relation. Bumping to P2 (P1 I believe should be reserved for FX4 blocking stuffs) since it's required by ARIA to pass candidate recommendation.
Priority: P5 → P2
Assignee | ||
Updated•12 years ago
|
Assignee: nobody → surkov.alexander
Summary: Test impact of additional ARIA role "rowgroup" → Support ARIA role "rowgroup"
Assignee | ||
Comment 13•12 years ago
|
||
just expose it as grouping role. No relations since I don't see any utility of them.
Attachment #680608 -
Flags: review?(trev.saunders)
Assignee | ||
Comment 14•12 years ago
|
||
(correct patch)
Attachment #680608 -
Attachment is obsolete: true
Attachment #680608 -
Flags: review?(trev.saunders)
Attachment #680609 -
Flags: review?(trev.saunders)
Assignee | ||
Comment 15•12 years ago
|
||
Comment on attachment 680609 [details] [diff] [review]
patch2
now we expose an accessible for role="rowgroup" with no role actually (MSAA role is "rowgroup", IA2 role is from native markup). In either case role from native markup as MSAA string role doesn't seem right here.
Btw, spec allows us to not expose an accessible for it at all:
"Not mapped" + included elements: "Elements that have a mappable role in the role attribute string (see Role Mapping below). "
But having no accessible might be not correct so. It seems reasonable to expose it as grouping role:
IA2: ROLE_SYSTEM_GROUPING
ATK: ATK_ROLE_PANEL
OSX: NSAccessibilityGroupRole
(we could request to change ARIA impl guide for IA2 and ATK I guess but I'm not sure about OS X). What do you think?
Attachment #680609 -
Flags: feedback?(dbolter)
Reporter | ||
Comment 16•12 years ago
|
||
Comment on attachment 680609 [details] [diff] [review]
patch2
Review of attachment 680609 [details] [diff] [review]:
-----------------------------------------------------------------
A group role here seems good to me as well.
Attachment #680609 -
Flags: feedback?(dbolter) → feedback+
Comment 17•12 years ago
|
||
(In reply to alexander :surkov from comment #15)
> Comment on attachment 680609 [details] [diff] [review]
> patch2
>
> now we expose an accessible for role="rowgroup" with no role actually (MSAA
> role is "rowgroup", IA2 role is from native markup). In either case role
> from native markup as MSAA string role doesn't seem right here.
>
> Btw, spec allows us to not expose an accessible for it at all:
>
> "Not mapped" + included elements: "Elements that have a mappable role in the
> role attribute string (see Role Mapping below). "
>
> But having no accessible might be not correct so. It seems reasonable to
> expose it as grouping role:
>
> IA2: ROLE_SYSTEM_GROUPING
> ATK: ATK_ROLE_PANEL
> OSX: NSAccessibilityGroupRole
>
> (we could request to change ARIA impl guide for IA2 and ATK I guess but I'm
> not sure about OS X). What do you think?
for atk having a pain under a table seems funny, same for OSX I think, but I'm not sure I have a better idea.
Really however I tend to think we should only add this role if its somehow different from group and it makes sense to expose it differently.
Assignee | ||
Comment 18•12 years ago
|
||
(In reply to Trevor Saunders (:tbsaunde) from comment #17)
> > IA2: ROLE_SYSTEM_GROUPING
> > ATK: ATK_ROLE_PANEL
> > OSX: NSAccessibilityGroupRole
> >
> > (we could request to change ARIA impl guide for IA2 and ATK I guess but I'm
> > not sure about OS X). What do you think?
>
> for atk having a pain under a table seems funny, same for OSX I think, but
> I'm not sure I have a better idea.
yep, that why I asked
> Really however I tend to think we should only add this role if its somehow
> different from group and it makes sense to expose it differently.
You talk abut ARIA roles "group" vs "rowgroup"? It seems sometimes ARIA adds extra roles for the author that doesn't have any special processing by AT.
Assignee | ||
Comment 19•12 years ago
|
||
Jamie, do you have opinion on this?
Assignee | ||
Comment 20•12 years ago
|
||
Trev pointed that rowgroup elements may be used to introduce groups (I know that sounds tautology and you already named us mr obvious slapping your head) but yep it should affect on group info we expose. If we have rowgroup accessible then it happens automatically, if we reject to have it an accessible for it (ARIA allows that to us) then we need to do some magic on this way. Btw, having rowgroup accessible we could expose group info for rowgroups as well (but we aren't allowed by ARIA spec).
So, I think I'd want to keep an accessible for rowgroup (it seems to be lesser problems approach). And rowgroup shouldn't be a weak role like it's implemented now. Role GROUPING having mapping described in comment #15 should be more appropriate than native markup role even if they aren't really suitable (btw it contradicts to ARIA impl guide, I'll file a bug). In either case "rowgroup" is inherited from "group" ARIA role which has GROUPING role mapping so we should be in a good shape from that point of view.
If we get another feedback then let's change roles to a better fit. Until that I suggest to take this patch. I need a decision taken here to proceed with bug 804461.
Updated•12 years ago
|
Attachment #680609 -
Flags: review?(trev.saunders) → review+
Comment 21•12 years ago
|
||
Status: NEW → RESOLVED
Closed: 12 years ago
Flags: in-testsuite+
Resolution: --- → FIXED
Target Milestone: --- → mozilla19
You need to log in
before you can comment on or make changes to this bug.
Description
•