Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Is the attribute aria-level on role=grid and role=tablist necessary? #915

Closed
spectranaut opened this issue Mar 18, 2019 · 11 comments · Fixed by #1079
Closed

Is the attribute aria-level on role=grid and role=tablist necessary? #915

spectranaut opened this issue Mar 18, 2019 · 11 comments · Fixed by #1079
Assignees
Labels
has PR PR exists that will close this issue
Milestone

Comments

@spectranaut
Copy link
Contributor

spectranaut commented Mar 18, 2019

What are the use cases for aria-level on role=grid and role=tablist? If there is no use cases, is it a bug that ARIA allows this?

aria-level on role=grid

Nested grids are possible to imagine on a website, but it seems hard to imagine that nest grids would not also be nested in the DOM. And if it is nested in a DOM, shouldn't the user agent calculate this information?

aria-level on role=tablist

See the description of aria-level for use on the role=treeitem:

"This attribute is applied to elements that act as leaf nodes within the orientation of the set, for example, on elements with role treeitem rather than elements with role group. This means that multiple elements in a set may have the same value for this attribute. Although it would be less repetitive to provide a single value on the container, restricting this to leaf nodes ensures that there is a single way for assistive technologies to use the attribute."

And the description of aria-level on role=row:

"In the case of a treegrid, aria-level is supported on elements with the role row, not elements with role gridcell. At first glance, this may seem inconsistent with the application of aria-level on treeitem elements, but it is consistent in that the row acts as the leaf node within the vertical orientation of the grid, whereas the gridcell is a leaf node within the horizontal orientation of each row. Level is not supported on sets of cells within rows, so the aria-level attribute is applied to the element with the role row."

It seems like aria-level should be on role=tab according to this logic.

cc @zcorpan @mcking65

@zcorpan
Copy link
Member

zcorpan commented Jun 24, 2019

It looks like this issue was mentioned in https://www.w3.org/2019/03/21-aria-minutes.html

mck: I want to put a discussion of this on the agenda relatively soon
jamesn: I'll put 1.2 on it

@mcking65 @jnurthen has this issue been discussed after that?

@jnurthen
Copy link
Member

jnurthen commented Jun 24, 2019

IMO tablist sounds correct - I've come across nested tablists in applications a number of times. If AT were to support this it would be helpful IMO. @curtbellew and @stes-acc probably have a bunch of use cases.

I can't see a use case for grid right now - anyone have one?

@mcking65
Copy link
Contributor

@jnurthen, while I am not opposed to leaving aria-level on tablist, it is difficult to imagine how this would be utilized by screen readers. Perhaps the screen reader might look up the tree to find out that a tab is a level 2 tab. If it did, I don't really know how the screen reader could help the user with that information. In some situations, depending on where the nested tabs fall within the parent tabpanel, the information may be entirely useless to the user.

In other words, to me, the utility of aria-level on tablist or tab seems more theoretical than utilitarian.

I believe there is zero utility on grids and that we could consider removing it.

@zcorpan
Copy link
Member

zcorpan commented Jun 26, 2019

@jnurthen Can you show an example of an application with nested tablists? I suppose the nested tablist would be inside the tabpanel?

@a11ydoer
Copy link
Contributor

@mcking65 is seeking the input regarding what the best strategy for addressing the use cases which are not happening often, so called "edge cases"

@jnurthen
Copy link
Member

@curtbellew I know there are products which used to have this - can you comment if you need this support to remain. Honestly I'd be in favour of removing the support but I know there are UIs which do this.

@a11ydoer
Copy link
Contributor

a11ydoer commented Aug 2, 2019

@jnurthen are you talking about aria role either "grid" or "tablist" above?

@jnurthen
Copy link
Member

jnurthen commented Aug 2, 2019

@a11ydoer tablist - I can't think of a reason to have a level on grid.

@smhigley
Copy link
Contributor

smhigley commented Aug 5, 2019

Going back through old emails, I found one example of role="group" within a tablist. It was a vertically-oriented set of tabs that controlled the content of a panel (which was also the principal content for the app). The tabs were hierarchical -- a bit like a tree but without expand/collapse capability.

I think it could be argued that it should have been a tree, and that perhaps it should have supported expand/collapse to benefit high zoom and smaller screens.

Even with that example, I believe I agree with @jnurthen in favor of removing it, at least until enough different people come forward with valid use cases for it that aren't better served by a different pattern.

@curtbellew
Copy link

@jnurthen Unfortunately I can't point to a specific use case in the wild here. I only have fuzzy memories of tablists using aria-level. I've got a couple emails out internally asking for access to environments I can look at but at this point I don't have anything from the real world.

@scottaohara
Copy link
Member

#1029 removed aria-level from grid so that part of this issue has been resolved.

I made #1079 to either be accepted to remove the attribute from tablist, or to be rejected. In either case, the outcome of the PR will close this issue.

@scottaohara scottaohara added the has PR PR exists that will close this issue label Oct 3, 2019
zcorpan added a commit to w3c/aria-practices that referenced this issue Oct 28, 2019
zcorpan added a commit to w3c/aria-practices that referenced this issue Oct 31, 2019
mcking65 pushed a commit to w3c/aria-practices that referenced this issue Dec 2, 2019
mcking65 pushed a commit to w3c/aria-practices that referenced this issue Dec 15, 2020
mcking65 pushed a commit to w3c/aria-practices that referenced this issue Dec 15, 2020
zcorpan added a commit to w3c/aria-practices that referenced this issue Nov 2, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
has PR PR exists that will close this issue
Projects
None yet
Development

Successfully merging a pull request may close this issue.

9 participants