RFC: ARIA Attributes

[mrchief]

react-dropdown-tree-select is a composite component, i.e. it's a combo of many HTML elements working in tandem. There is no WAI-ARIA guideline that covers something like this, so this component tries to adhere to guidelines for the constituent elements.

Here is a breakdown of the constituent elements:

Element	ARIA Attributes	References	Not supported
Search Input	-role="combobox" -aria-autocomplete="list" -aria-haspopup="true" -aria-activedescendant	combobox-autocomplete-list	-aria-owns -aria-controls see w3c/aria/issues/716)
Dropdown Toggle Button	-aria-haspopup="true" -aria-expanded	menu-button-actions-active-descendant	-aria-owns -aria-controls see w3c/aria/issues/716)
Dropdown Tree Container (ul)	-role="tree" -aria-multiselectable	treeview
Tree Node	-role="treeitem" -aria-level -aria-expanded -aria-setsize -aria-posinset -aria-selected	treeview
Tree Node Expand/Collapse	-aria-expanded	menu-button-actions-active-descendant
Checkbox	-role="checkbox" -aria-checked	checkbox
Tag Delete Button	-role="button" -aria-labelledby	button

Partially fixes #216

[ellinge]

I’m in no way any expert on ARIA, and this has many parts to handle, so these are only my interpretations.

I think the tree expand/collapse and checkbox should become hidden for screen readers. Everything needed for a screen reader is available on the Tree node through attributes. Not sure if you need to use aria-hidden on them or if it’s enough to set tabIndex to -1.

The tree node and dropdown container also render differently depending on simpleSelect (role='option') or not. To handle partial state, it should output aria-checked instead which has ‘mixed’ as an option. But the simpleSelect should still render aria-selected. Some of the attributes are also not applicable since role="option" does not support some of the hierarchical attributes.

We also need to define how actions should be handled or just ignore them for now.

[mrchief]

I’m in no way any expert on ARIA, and this has many parts to handle, so these are only my interpretations.

That makes two of us!

I think the tree expand/collapse and checkbox should become hidden for screen readers.

I thought so too but their design pattern examples have it otherwise.

Not sure if you need to use aria-hidden on them or if it’s enough to set tabIndex to -1.

tabIndex=-1 will affect tabbing/focusing. aria-hidden will only affect screen readers. However, if one is using aria-hidden, then tabIndex should be -1. tabIndex=0 + aria-hidden=true is a no no.

I'm ok either way, with marking them aria-hidden as long as we set the tabIndex correctly.

The tree node and dropdown container also render differently depending on simpleSelect (role='option') or not.

Yes, absolutely.

To handle partial state, it should output aria-checked instead which has ‘mixed’ as an option. But the simpleSelect should still render aria-selected.

Agreed. This is why I didn't put any values in the table, just that aria-checked will be emitted. It is implied that we'll emit the correct value and those will be asserted by tests I guess.

Some of the attributes are also not applicable since role="option" does not support some of the hierarchical attributes.

Agreed. I wasn't sure how to cover all these variations in a simple manner with the above table. Feel free to edit the RFC if you feel we can depict all these cases with simplicity.

We also need to define how actions should be handled or just ignore them for now.

Actions are largely unknowns but we do know that they are all buttons, so I think we can just follow button's specs for them.

[ellinge]

https://www.w3.org/TR/wai-aria-1.1/#aria-hidden

Authors MAY, with caution, use aria-hidden to hide visibly rendered content from assistive technologies only if the act of hiding this content is intended to improve the experience for users of assistive technologies by removing redundant or extraneous content. Authors using aria-hidden to hide visible content from screen readers MUST ensure that identical or equivalent meaning and functionality is exposed to assistive technologies.

To me the screen reader navigates to the node by keyboard. They should have all required information as aria-attributes on the node itself. The checkbox and expand/collapse button only becomes redundant in my opinion. They are only there for navigation by mouse/visual aids?

[ellinge]

Actions are largely unknowns but we do know that they are all buttons, so I think we can just follow button's specs for them.

Still, how should one navigate to them? How do we expose them right and so on.

[mrchief]

Hear ya. I think, for starters, tab should go in this cycle:

node > tab > action1 > tab > action2... > tab > next node vertically

If no actions then:

node > tab > next node vertically

If one has actions but doesn't want to cycle through them, then they can use the arrow keys to go to the next node right away, so I think this should be a good enough experience.

[ellinge]

Do you have any example from w3 where they tab within selections? Haven't encountered any. I think that would be a mayor deviation from what's normally implemented which could be a risk.

[mrchief]

Do you have any example from w3 where they tab within selections

Do you mean actions? I don't see them as part of a selection (the node item). You're only selecting/deselecting node items - actions are something that appears inline but are not part of the node value.

[ellinge]

Do you have any example from w3 where they tab within selections

Do you mean actions?

Nope meant node navigation by tab. Have not encountered any example yet where tab does not leave current control.
Do you have any example where traversing between selections are done with tab?

[mrchief]

Nope meant node navigation by tab. Have not encountered any example yet where tab does not leave current control.

Hmm, yeah that does sound weird. One idea would be to use the toolbar pattern if you think of actions as an inline toolbar. Or else we could do Ctrl+Tab to cycle through actions. 3rd option would be to do nothing and tackle it in the future if there is enough of an ask.

[ellinge]

This Pill List is the closest I've seen to our tag list as well on w3, not sure if it's applicable:
https://www.w3.org/TR/2017/NOTE-wai-aria-practices-1.1-20171214/examples/grid/LayoutGrids.html

[mrchief]

That's a great example. I'd say it's totally applicable for our tags.

And the Data Grid Example seems to follow the toolbar pattern which seems like a good fit for actions.

[ellinge]

And the Data Grid Example seems to follow the toolbar pattern which seems like a good fit for actions.

How do you suggest it should be combined with treeview, which I think is the right fit?
Enter and space currently toggles selection and arrows currently controls collapse/expand.

If any actions, should enter/space instead trigger the toolbar so you can use arrows for navigation between the node and actions? If focusing the node enter now triggers toggle instead?

Space could still always toggle selection?

[ellinge]

Closed by mistake. This is perhaps something to have in mind:
https://www.w3.org/TR/wai-aria-practices/examples/treegrid/treegrid-1.html

[mrchief]

How do you suggest it should be combined with treeview, which I think is the right fit?

Yes, treeview is the right fit.

If any actions, should enter/space instead trigger the toolbar so you can use arrows for navigation

What do you mean by "trigger the toolbar"? I imagined navigating node with up/down arrows and once the node has focus, the following should happen:

• Enter/space toggles selection
• left/right arrows cycle between actions (if present); no op if no actions

[ellinge]

Enter/space toggles selection

Do you mean checkbox selection or some form of "activation" here of node for action navigation?

left/right arrows cycle between actions (if present); no op if no actions

That's assigned to expanding/collapsing unfortunately. We would not support actions on nodes with children in that case. It would be odd to have different behavior depending on children or not. That's what I meant with Enter activating another behaviour for the node, e.g. navigating between actions instead. I think the treegrid sample is something which is closer to what you're thinking about.

Then arrows becomes navigation only after expanding a node instead of going to first child (which is the suggested behaviour for a treeview) Row does not support aria-checked for partial though but that could be solved on the column level instead I guess.

[mrchief]

Do you mean checkbox selection or some form of "activation" here of node for action navigation?

Yeah, checkbox/radio selection.

That's assigned to expanding/collapsing unfortunately.

Damn, can't win 😆

It would be odd to have different behavior depending on children or not.

Agreed.

That's what I meant with Enter activating another behaviour for the node, e.g. navigating between actions instead. I think the treegrid sample is something which is closer to what you're thinking about.

I understand it now. Enter feels weird though. What about shift+arrows or alt+arrows for action nav?

[ellinge]

Then we introduce our own bindings instead of relying on the recommended one for the roles we say we implement? The treegrid comes quite naturally I think if you give it a go. First column being the label/selection/toggle and the following actions. No idea how that works with most rows only having one column and a few others different number of columns/actions though.

I think we should be inspired by that even if we don't change to the roles. Meaning arrow right (and left reversed) does the following:

• expand node (if children)
• traverse actions if any OR go to first child (if children)
  ELSE nothing

Since most actions propably are on leafs the expanding propably never will need to be triggered though. How would one know that the arrows has some additional meaning here? Is it possible to use a different role in the middle of a treeview or append aria-owns, aria-haspopup or similar to hint to the user that there's some additional horizontal options/actions?

If it weren't for those actions... One option would be to ignore them for now and implement them in another issue? I think

[ellinge]

We should also think about the need for aria-owns populated with, if any, id array of _children since the tree is in fact rendered flat and the relationship is therefore not clear between the two.

[ellinge]

https://www.w3.org/TR/wai-aria-1.1/#aria-keyshortcuts looks interesting. Could set it dynamically only for focused item

Unsure it will work in other browsers than chrome though. Found one issue on github saying apple refused to implement it and one open ticket for mozilla/firefox. So perhaps not a good path but would solve our problems I think. Perhaps it's intended for more fixed focus targets.

[mrchief]

I think we should be inspired by that even if we don't change to the roles. Meaning arrow right (and left reversed) does the following:

• expand node (if children)
• traverse actions if any OR go to first child (if children)
  ELSE nothing

This is similar to what I said earlier - isn't it? I guess no-op if no actions threw you off? If so, then I apologize for not being clear enough.

I agree with the above approach.

How would one know that the arrows has some additional meaning here?

It's kinda defacto behavior in software. Shift/Alt/Ctrl are modifier keys and are used in various software for modifying the behavior of arrow keys. It comes intuitively to try using those modifier keys.

Then we introduce our own bindings instead of relying on the recommended one for the roles we say we implement?

We're doing that one way or the other - as we try to use our best judgments in piecing together all different patterns/practices. 😄

By the way, how did the RFC for ARIA attributes turn into a discussion about keyboard nav? I planned on creating another RFC for that! 😄

w3.org/TR/wai-aria-1.1/#aria-keyshortcuts looks interesting. Could set it dynamically only for focused item

It definitely is!

Unsure it will work in other browsers than chrome though. Found one issue on github saying apple refused to implement it and one open ticket for mozilla/firefox. So perhaps not a good path but would solve our problems I think. Perhaps it's intended for more fixed focus targets.

I'd say that's still a good start. With Edge switching to Chromium, I'd say that should cover 3/4 major browsers (Chrome, Safari, Edge).

The more I read about ARIA, the more I find how flaky the current state of affairs is. There are no universally implemented standards amongst readers or browsers. Every reader/browser has their interpretations and quirks. And one thing that scares me is that "bad ARIA is worse than no ARIA." I'd say let's do the best we can and note the oddities as we go along. And if you have a real use-case, then we can use feedback from that to hone in our implementation iteratively.

[ellinge]

This is similar to what I said earlier - isn't it? I guess no-op if no actions threw you off? If so, then I apologize for not being clear enough.

You skipped the part with expand/collapse, which is the default behaviour with left/right arrow on the role treeitem 😄

It's kinda defacto behavior in software. Shift/Alt/Ctrl are modifier keys and are used in various software for modifying the behavior of arrow keys. It comes intuitively to try using those modifier keys.

We're doing that one way or the other - as we try to use our best judgments in piecing together all different patterns/practices. 😄

Well so may be. But we implement the “defacto” for the role not what usually works in software. Picture yourself blind, the only guidance you have is the how the screen reader interprets the aria attributes and content available. You need a hint to tell you that there's more content available "to the right". The role treegrid solves that by introducing columns which tells you there is more content to the right.

I guess we can solve it by either changing the role completely or perhaps using group as a middleman between the treeitem and the tree. Maybe aria-keyshortcuts can help. I'm not sure, but what I'm sure of is that we need something more to tell the user more options are available and how they access them.

By the way, how did the RFC for ARIA attributes turn into a discussion about keyboard nav? I planned on creating another RFC for that! 😄

They are tightly coupled; the roles expect some keyboard actions to be implemented ⌨️

I'd say that's still a good start. With Edge switching to Chromium, I'd say that should cover 3/4 major browsers (Chrome, Safari, Edge).

Yes, I think it would be easiest for us as well. I think we currently are close to what's best for our needs. I'm not aware how much actions are used but I guess the use is pretty slim since they don't seem to work as expected currently and no issues seems to have been issued yet. It would be awful if they required us to change everything because of them.

The more I read about ARIA, the more I find how flaky the current state of affairs is. There are no universally implemented standards amongst readers or browsers. Every reader/browser has their interpretations and quirks. And one thing that scares me is that "bad ARIA is worse than no ARIA." I'd say let's do the best we can and note the oddities as we go along. And if you have a real use-case, then we can use feedback from that to hone in our implementation iteratively.

That's applicable to other things regarding web so nothing new 😆 As I said earlier, I think we are close to something which is well implemented. Even if we have some special cases, we are close to how the examples from W3 are implemented. And most of the aria-attributes should be well supported, nothing fancy. It's just the part with actions that probably will require some more potentially "quirky" solutions.

In Europe/EU public sector sites are now by law required to ensure their sites are accessible. Not sure this is the best link covering that but if you're interested it's a summary at least: https://developer.paciellogroup.com/blog/2018/04/eu-directive-on-the-accessibility-of-public-sector-websites-and-mobile-applications/

The site we plan on using this component on is such a site. So, it will probably will be audited by third party to ensure compliance.

[mrchief]

Agree with everything you say. And it's good to have a real-world use case. As far as actions go, we use them internally and the global handler works for the team using it.

I guess we can solve it by either changing the role completely or perhaps using group as a middleman between the treeitem and the tree. Maybe aria-keyshortcuts can help. I'm not sure, but what I'm sure of is that we need something more to tell the user more options are available and how they access them.

I'm open to trying out things. I currently don't have much time to research this so I'll leave to your capable hands to best tackle this.

Do you mind opening a similar RFC for keyboard nav? Or do you think we should add the keys and effects in the readme?

[ellinge]

Not sure how much time I want to spend with this though. We don't use actions ourselves so this would be as a courtesy to get the PR:s through. We've already talked internally to build our own component instead since none (on npm) seems to cover WCAG & hierarchy-support.

[mrchief]

Not sure how much time I want to spend with this though. We don't use actions ourselves so this would be as a courtesy to get the PR:s through.

I understand and I don't want to spend more time than necessary either. I think we have clarity on most parts, the RFC suggestion was merely to solidify specs.

Let me know if you want to go through with the PRs though.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[mrchief]

🎉 This issue has been resolved in version 1.20.0 🎉

The release is available on:

• npm package (@latest dist-tag)
• GitHub release

Your semantic-release bot 📦🚀