E-mail List Archives
Thread: Conveying relationship in grid
Number of posts in this thread: 2 (In chronological order)
From: Vemaarapu Venkatesh
Date: Thu, Apr 12 2018 10:28PM
Subject: Conveying relationship in grid
No previous message | Next message →
Hello all, Greetings!
I am having a grid with list of tasks as data in it. Every parent task have
their child's in the grid simply there's a parent child relationship
constructed in the grid. How to convey this hierarchy to a screen reader
user?
As far as my understanding, using aria-level might do the things. Like
assigning level 1 to parent task and level 2 to child tasks so on anbd it's
obvious to use aria-owns to build that relation for screen reader users
regardless of DOM order.
Also I feel it is good if users are able to collapse and expand parent task
so that they can easily reach their desired one's instead of navigating
every child task of parent.
Here the complete row of child task is filled with some data and when it
comes to parent task row, only task name alone in the first cell exists. Is
it better way to disable all other cells in the parent row as no data
exists and not letting keyboard focus go there?
Any thoughts. Are there any other ARIA attributes which we can use to
provide better experience for screen reader users?
Regards,
Venkatesh
From: glen walker
Date: Fri, Apr 13 2018 9:44AM
Subject: Re: Conveying relationship in grid
← Previous message | No next message
The old 1.0 authoring practice used to have a "tree grid
<https://www.w3.org/TR/2013/WD-wai-aria-practices-20130307/#treegrid>"
design pattern. The new authoring practice
<https://www.w3.org/TR/wai-aria-practices-1.1/#x5-1-fundamental-keyboard-navigation-conventions>
has a place holder for the tree grid but no specs yet. I think that's the
pattern you're describing. It's a complicated interaction which is
probably why the new authoring practice doesn't have it yet. Support for
trees, in general, does not seem to be fully supported yet by all screen
readers and browsers, which makes a tree grid even harder to support.
The treegrid role is documented at
https://www.w3.org/TR/wai-aria-1.1/#treegrid. The treeitem role is also
documented and you do indeed use the aria-level property, as you suggested.
On Thu, Apr 12, 2018 at 10:28 PM, Vemaarapu Venkatesh <
= EMAIL ADDRESS REMOVED = > wrote:
> Hello all, Greetings!
>
> I am having a grid with list of tasks as data in it. Every parent task have
> their child's in the grid simply there's a parent child relationship
> constructed in the grid. How to convey this hierarchy to a screen reader
> user?
> As far as my understanding, using aria-level might do the things. Like
> assigning level 1 to parent task and level 2 to child tasks so on anbd it's
> obvious to use aria-owns to build that relation for screen reader users
> regardless of DOM order.
> Also I feel it is good if users are able to collapse and expand parent task
> so that they can easily reach their desired one's instead of navigating
> every child task of parent.
> Here the complete row of child task is filled with some data and when it
> comes to parent task row, only task name alone in the first cell exists. Is
> it better way to disable all other cells in the parent row as no data
> exists and not letting keyboard focus go there?
>
> Any thoughts. Are there any other ARIA attributes which we can use to
> provide better experience for screen reader users?
>
> Regards,
> Venkatesh
> > > > >