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?