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

role="row" needs to support aria-setsize, aria-posinset #558

Closed
aleventhal opened this issue Apr 13, 2017 · 11 comments
Closed

role="row" needs to support aria-setsize, aria-posinset #558

aleventhal opened this issue Apr 13, 2017 · 11 comments
Assignees
Milestone

Comments

@aleventhal
Copy link
Contributor

This looks like an oversight that occurred because no one actually tried to create and validate a working treegrid when we came up with the original markup.

A treegrid is filled with role="row" descendants. Each row is expandable, and can support aria-label, aria-expanded. However, unlike a treeitem, there is no way to help the AT know where the user is within a given level. For that, we need aria-setsize and aria-posinset.

Filing this after @sideshowbarker pointed out that the validator is following the rules, disallowing this markup.
Related bug: https://bugzilla.validator.nu/show_bug.cgi?id=1033

This is blocking the creation of a valid treegrid for the ARIA authoring guide.

@aleventhal
Copy link
Contributor Author

Ah, @jnurthen says that I need to try aria-colcount, aria-colindex, aria-rowcount and aria-rowindex, which weren't there back in the day! I'll see if that works and close if possible.

@aleventhal
Copy link
Contributor Author

@jnurthen aria-rowcount is apparently for the total number of rows in the table, not on this level. So I think we still need setsize/posinset.

@jnurthen
Copy link
Member

Yep - I think you are correct that these are needed.

@mcking65
Copy link
Contributor

@aleventhal commented:

Each row is expandable, and can support aria-label, aria-expanded.

Well, there are end node rows that do not have children, so they are not expandable, right? And, those rows would not have aria-expanded.

@aleventhal continues:

However, unlike a treeitem, there is no way to help the AT know where the user is within a given level.
For that, we need aria-setsize and aria-posinset.

In trees, browsers can calculate this because of grouping and ownership. What if a parent row were to own a rowgroup that contains its children? That would enable the browser to calculate pos inset and setsize.

Even if that did work, I agree that posinset and setsize should be explicitly supported in the spec, otherwise there is nothing suggesting that that browsers should do the calculation.

If owned rowgroups were the accepted way of structuring a treegrid, then rowgroup should also support aria-level.

Alternatively, we could have an allowed context of group for rows and use group instead of rowgroup.

@mcking65 mcking65 self-assigned this Jun 15, 2017
@aleventhal
Copy link
Contributor Author

@mcking65 It's 99% likely that the treegrid will be done with a simple HTML table. It will probably already be coded up and the ARIA will be added after the fact. We should make it as simple as possible to add the ARIA. I suggest supporting @aria-setsize and @aria-posinset. We've implemented this in Fancytree.js and Chrome, and it works nicely with NVDA/JAWS. I believe Firefox supports as well.

So IMO we should do the easy thing here and allow a row to be like a treeitem when it's in a treegrid, and support these properties.

@SiTaggart
Copy link

SiTaggart commented Nov 2, 2017

I posted about this in the HTML spec too, so cross posting back to here.

w3c/html#1066

Agree, posinset and setsize is a requirement for building treegrids, or potentially grids if the grid is virtualised.

@mcking65
Copy link
Contributor

@jnurthen, this fell through the cracks ... it is not labeled and does not have a milestone. I think it should be labeled bug and be part of the 1.2 milestone. I'll put together a PR now. One question I have is whether there needs to be any prose about when aria-posinset and aria-setsize are allowed on row. We do not want them to be used like rowindex and rowcount ... so we need to make sure, somehow, there is no confusion there. Should it only be allowed in the context of treegrid? One comment above mentions virtualized grids, but I do not see why it is needed there.

@jnurthen jnurthen added this to the ARIA 1.2 milestone Jul 11, 2018
@jnurthen
Copy link
Member

@mcking65 I think there certainly needs to be prose on this - we don't want people adding aria-posinset and aria-setsize on grid rows as we have different attributes for these.

@SiTaggart can you give more details about the virtualized grid comment?

@SiTaggart
Copy link

Yeah, virtualised grids was an oversight by me. rowcount and rowindex will do it

mcking65 added a commit that referenced this issue Jul 11, 2018
Modified text and properties of the role row for issue #558:
- Removed paragraph about aria-expanded in treegrids.
- Add paragraph with two normative statements:
  * Authors should only use setsize, posinset, level, and expanded attributes in treegrids
  * User agents should only expose them in treegrids
- Modified allowed states and properties to allow aria-posinset and aria-setsize.
@mcking65
Copy link
Contributor

I borrowed similar prose from columnheader and rowheader roles. And, found another related mistake in a normative statement in rowheader while looking for similar and appropriate language. It says it must contained or owned by a grid. Separate PR for that coming.

mcking65 added a commit that referenced this issue Aug 16, 2018
For issue #558, Make changes in response to feedback from @jnurthen and @carmacleod:
* Change author SHOULD NOT to MUST NOT use setsize, posinset, level, and expanded attributes in treegrids
* change treegrids to tree grids in one place where not referring specifically to the treegrid role.
@carmacleod
Copy link
Contributor

Is there anything left to do here?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants