Closed
Bug 864224
Opened 12 years ago
Closed 12 years ago
Support nested ARIA listitems structured by role='group'
Categories
(Core :: Disability Access APIs, defect)
Core
Disability Access APIs
Tracking
()
RESOLVED
FIXED
mozilla24
People
(Reporter: surkov, Assigned: surkov)
References
(Blocks 1 open bug)
Details
(Keywords: access)
Attachments
(1 file, 2 obsolete files)
(deleted),
patch
|
tbsaunde
:
review+
|
Details | Diff | Splinter Review |
example:
<div role="list">
<div role="listitem">Item 1
<div role="group">
<div role="listitem">Item 1A</div>
<div role="listitem">Item 1B</div>
</div>
</div>
<div role="listitem">Item 2
<div role="group">
<div role="listitem">Item 2A</div>
<div role="listitem">Item 2B</div>
</div>
</div>
</div>
Assignee | ||
Updated•12 years ago
|
Summary: group level isn't calculated for nested ARIA listitems → group level isn't calculated for nested ARIA listitems structured by role='group'
Assignee | ||
Comment 1•12 years ago
|
||
Assignee: nobody → surkov.alexander
Status: NEW → ASSIGNED
Attachment #740170 -
Flags: review?(trev.saunders)
Comment 2•12 years ago
|
||
Comment on attachment 740170 [details] [diff] [review]
patch
Shouldn't you fix AccGroupInfo::IsConceptualParent() too?
what is logic behind checking only last child to see if sibling has list child checking all the kids of all the siblings would be crazy but only the last one is funny.
Assignee | ||
Comment 3•12 years ago
|
||
(In reply to Trevor Saunders (:tbsaunde) from comment #2)
> Comment on attachment 740170 [details] [diff] [review]
> patch
>
> Shouldn't you fix AccGroupInfo::IsConceptualParent() too?
seems so
> what is logic behind checking only last child to see if sibling has list
> child checking all the kids of all the siblings would be crazy but only the
> last one is funny.
probably less work + handling existing widgets
Assignee | ||
Comment 4•12 years ago
|
||
changing summary to reflect 'node child/parent of' relation work
Summary: group level isn't calculated for nested ARIA listitems structured by role='group' → Support nested ARIA listitems structured by role='group'
Assignee | ||
Comment 5•12 years ago
|
||
Attachment #740170 -
Attachment is obsolete: true
Attachment #740170 -
Flags: review?(trev.saunders)
Attachment #743654 -
Flags: review?(trev.saunders)
Updated•12 years ago
|
Attachment #743654 -
Flags: review?(trev.saunders) → review+
Comment 6•12 years ago
|
||
Comment on attachment 743654 [details] [diff] [review]
patch2
might be good if davidb looks at this (if he thinks he understands it) my eyes glazed over some, this stuff is far too complicated :(
Attachment #743654 -
Flags: review?(dbolter)
Comment 7•12 years ago
|
||
Give me a bit.
Comment 8•12 years ago
|
||
Alexander can you remind me why there is special text about allowing groups in lists?
http://www.w3.org/WAI/PF/aria/complete#list
"Lists contain children whose role is listitem, or elements whose role is group which in turn contains children whose role is listitem."
What is the common use case?
Comment 9•12 years ago
|
||
Comment on attachment 743654 [details] [diff] [review]
patch2
So I was thinking about this more and I'd really like to understand why we need this complexity and when using a role=list wouldn't work.
Attachment #743654 -
Flags: review+ → review?(trev.saunders)
Comment 10•12 years ago
|
||
(I'm sure there must be a reason but I've forgotten it)
Assignee | ||
Comment 11•12 years ago
|
||
(In reply to David Bolter [:davidb] from comment #8)
> Alexander can you remind me why there is special text about allowing groups
> in lists?
There is failing ARIA test (FF track item: https://wiki.mozilla.org/Accessibility/ARIA1.0TestSuiteFailures#769). The spec is not clear about it what Joseph agreed with and if I understand it right it's ARIA.next issue. You should have mail thread in your inbox where we discussed that.
Assignee | ||
Comment 12•12 years ago
|
||
(In reply to Trevor Saunders (:tbsaunde) from comment #9)
> Comment on attachment 743654 [details] [diff] [review]
> patch2
>
> So I was thinking about this more and I'd really like to understand why we
> need this complexity and when using a role=list wouldn't work.
yeah, except the spec doesn't seem says about this way. I think we did it to follow HTML lists.
What I don't like is ARIA diversity is too wide. I would be more happy if nested ARIA lists had the same structure as nested trees. But in either case proposed nested ARIA lists structure seems natural so I don't really have objections to not support it.
Comment 13•12 years ago
|
||
(In reply to alexander :surkov from comment #11)
> (In reply to David Bolter [:davidb] from comment #8)
> > Alexander can you remind me why there is special text about allowing groups
> > in lists?
>
> There is failing ARIA test (FF track item:
> https://wiki.mozilla.org/Accessibility/ARIA1.0TestSuiteFailures#769). The
> spec is not clear about it what Joseph agreed with and if I understand it
> right it's ARIA.next issue. You should have mail thread in your inbox where
> we discussed that.
I'd argue either the test is wrong or the spec should be changed.
(In reply to alexander :surkov from comment #12)
> (In reply to Trevor Saunders (:tbsaunde) from comment #9)
> > Comment on attachment 743654 [details] [diff] [review]
> > patch2
> >
> > So I was thinking about this more and I'd really like to understand why we
> > need this complexity and when using a role=list wouldn't work.
>
> yeah, except the spec doesn't seem says about this way. I think we did it to
> follow HTML lists.
Well, I don't see a reason we need to support group as a child of html list item either...
> What I don't like is ARIA diversity is too wide. I would be more happy if
> nested ARIA lists had the same structure as nested trees. But in either case
I wish trees were like lists and used the dom tree.
> proposed nested ARIA lists structure seems natural so I don't really have
> objections to not support it.
natural maybe, but its hard or imposible to implement performantly. Ideally I think the way to do this would be
<div role=list>
<div role=list> # sub list
<div role=listitem>foobar</div>
</div>
<div role=listitem</div>
</div>
or maybe even kill nested lists all together and say you should use trees for that.
Assignee | ||
Comment 14•12 years ago
|
||
(In reply to Trevor Saunders (:tbsaunde) from comment #13)
> > There is failing ARIA test (FF track item:
> > https://wiki.mozilla.org/Accessibility/ARIA1.0TestSuiteFailures#769). The
> > spec is not clear about it what Joseph agreed with and if I understand it
> > right it's ARIA.next issue. You should have mail thread in your inbox where
> > we discussed that.
>
> I'd argue either the test is wrong or the spec should be changed.
true but current version of the spec cannot be changed, so that will be part of next version. You may say that next spec should have this test then. I don't really care. The spec doesn't deny this behavior so if they want to have it then it should be ok. In either way it shouldn't prevent us to implement it.
> > proposed nested ARIA lists structure seems natural so I don't really have
> > objections to not support it.
>
> natural maybe, but its hard or imposible to implement performantly.
lists shouldn't be really large and it doesn't look that any other structure is really much performant
> or maybe even kill nested lists all together and say you should use trees
> for that.
trees are operable, lists are not.
Comment 15•12 years ago
|
||
Sorry for the delay, I've emailed PFWG to get clarity on why this support is necessary.
Comment 16•12 years ago
|
||
(In reply to alexander :surkov from comment #14)
> (In reply to Trevor Saunders (:tbsaunde) from comment #13)
>
> > > There is failing ARIA test (FF track item:
> > > https://wiki.mozilla.org/Accessibility/ARIA1.0TestSuiteFailures#769). The
> > > spec is not clear about it what Joseph agreed with and if I understand it
> > > right it's ARIA.next issue. You should have mail thread in your inbox where
> > > we discussed that.
> >
> > I'd argue either the test is wrong or the spec should be changed.
>
> true but current version of the spec cannot be changed, so that will be part
> of next version. You may say that next spec should have this test then. I
> don't really care. The spec doesn't deny this behavior so if they want to
> have it then it should be ok. In either way it shouldn't prevent us to
> implement it.
the point is I'd prefer to not implement it
> > > proposed nested ARIA lists structure seems natural so I don't really have
> > > objections to not support it.
> >
> > natural maybe, but its hard or imposible to implement performantly.
>
> lists shouldn't be really large and it doesn't look that any other structure
> is really much performant
and what happens when someone decides to use aria list for web email client? Sure in current use it might not be terrible, but why should we keep adding things that have limits when there are better designs that handle large test cases better?
> > or maybe even kill nested lists all together and say you should use trees
> > for that.
>
> trees are operable, lists are not.
so maybe the idea would be allow interactible and not interactible trees, or maybe just keep nested lists. However interactible or not trees seems nice for perf since we can avoid all this silly stuff to see if we should expose level and always expose it for tree type since its expected to have multiple levels and never expose for lists since they never will.
Assignee | ||
Comment 17•12 years ago
|
||
I think that ARIA lists should have the same structure as ARIA trees, i.e.
<div role="list">
<div role="listitem">1</div>
<div role="group">
<div role="listitem">1.1</div>
<div role="listitem">1.2</div>
</div>
</div>
because ARIA spec defines list and listitems similar to tree and treeitems but trees introduces a hierarchy by described way
Assignee | ||
Updated•12 years ago
|
Attachment #743654 -
Attachment is obsolete: true
Attachment #743654 -
Flags: review?(trev.saunders)
Attachment #743654 -
Flags: review?(dbolter)
Comment 18•12 years ago
|
||
(In reply to alexander :surkov from comment #17)
> I think that ARIA lists should have the same structure as ARIA trees, i.e.
>
> <div role="list">
> <div role="listitem">1</div>
> <div role="group">
> <div role="listitem">1.1</div>
> <div role="listitem">1.2</div>
> </div>
> </div>
I guess that could work
> because ARIA spec defines list and listitems similar to tree and treeitems
> but trees introduces a hierarchy by described way
I'd prefer aria tree's worked with the dom tree but I guess the way they're isn't too terrible just kind of awkward, though I'd like to here if some people who work on the DOM more can think of issues with the way aria trees work.
Assignee | ||
Comment 19•12 years ago
|
||
You know ARIA trees examples in the web use a hierarchy same with proposed hierarchy in the bug, for example:
http://test.cita.illinois.edu/aria/tree/tree1.php#lsc
http://www.w3.org/WAI/GL/wiki/Using_ARIA_trees
I'm not sure whether implemented hierarchy is still valid. It was implemented in bug 414976.
Assignee | ||
Comment 20•12 years ago
|
||
1) support proposed hierarchy for ARIA list and ARIA tree
2) keep ARIA tree hierarchy we had
Attachment #749133 -
Flags: review?(trev.saunders)
Comment 21•12 years ago
|
||
Comment on attachment 749133 [details] [diff] [review]
patch
I guess this is fine, though the first / last special casing is pretty strange, but arguably that's good because it'll make people not want to use aria when they don't need it.
Attachment #749133 -
Flags: review?(trev.saunders) → review+
Assignee | ||
Comment 22•12 years ago
|
||
Flags: in-testsuite+
Comment 23•12 years ago
|
||
Status: ASSIGNED → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla24
You need to log in
before you can comment on or make changes to this bug.
Description
•