WCAG support

[ellinge]

There's currently no support for keyboard navigation and no ARIA-attributes present.
Here are some guidelines one should consider complying with WCAG:
https://www.w3.org/TR/wai-aria-practices/examples/listbox/listbox-collapsible.html

Here are some of the highlights on attributes one should consider implementing:

• role
• aria-haspopup
• aria-expanded
• aria-selected

[mrchief]

Thanks for opening this. Having WCAG support would be great. I believe there are no clear guidelines for a mixed or combo control like this.

This component essentially is a mix of:

• an input
• a dropdown
• a TreeView
• label + checkboxes (each tree node)
• tags (selected tree nodes that have text plus a "x" button)
• node action item(s) - these are optional but essentially they are just buttons

To fully implement WCAG in a meaningful way, we'd need the following:

To add ARIA attributes

• Determine proper attributes to apply (RFC: ARIA Attributes #235)
• PR for adding the attributes (feat: Add ARIA roles and attributes #233)
• Automated tests to ensure compliance (preferably integrated with CI)

To add Keyboard navigation

• Figure out what Keyboard navigation should look like with all possible variations (e.g., with or without checkboxes, with or without action items, scrolling, adding/removing/navigating tags, etc.)
• Handle scroll virtualization
• PR for Adding keyboard navigation capabilities (feat: Add keyboard navigation #225)
• Automated tests to ensure compliance (preferably integrated with CI)

As you can see, the scope can be quite broad for getting it right a 100%, but I think we can probably add stuff incrementally in multiple PRs.

I'll start looking into it, and I'm open to ideas, suggestions, and PRs for this.

[ellinge]

Did some first tries to include a11y-testing through axe:
https://github.com/ellinge/react-dropdown-tree-select/tree/feat/%23216-tests

It only detects missing labeling for search input though. Not sure it will detect our scenario/needs. Since some dom-nodes are not rendered by React, it propably cannot detect that we expand and collapse child nodes. Not sure of it's capabilties. But it probably will be able to validate the attributes we apply I guess.

They also state

There is limited support for JSDOM. We will attempt to make all rules compatible with JSDOM but where this is not possible, we recommend turning those rules off. Currently the color-contrast rule is known not to work with JSDOM.

Here is the rule list:
https://github.com/dequelabs/axe-core/blob/develop/doc/rule-descriptions.md

[ellinge]

There’s automated tests in place in #225 that will give the same result as Chrome's audit.
Scroll virtualization? Do you mean replacing infinitescroll with a virtualized list/window instead?
#225 currently scrolls to current focused item

[mrchief]

Scroll virtualization

I meant scroll should work with arrow/pg up/dn keys...

[ellinge]

Scroll virtualization

I meant scroll should work with arrow/pg up/dn keys...

Alright, then that's in place in #225 also. A virtual window would be nice though and solve another open issue I think. Lots of potential nodes to render on page down 🐢 Most of them are based on fixed heights though so unsure how that would be solved good with custom css and long labels etc...

The audit for Chrome/axe doesn't solve more than validation of added aria-attributes for us, custom controls are open to interpretation. But Code climate seems to be aware of them already so perhaps they are redundant and should be removed.

[mrchief]

A virtual window would be nice though

Do you mean something like react-window or similar? I've considered many in the past and most of them require a fixed height which is kind of a downer for me. It's an additional burden for the caller which I would like to avoid. The current solution seems like a good one though, is there something bothering you?

Lots of potential nodes to render on page down

Page down should render the next page, similar to what happens when you reach the last item via mouse scroll (it renders the next set of 100 items, which is our page size).

The audit for Chrome/axe doesn't solve more than validation of added aria-attributes for us, custom controls are open to interpretation. But Code climate seems to be aware of them already so perhaps they are redundant and should be removed.

I was wondering the same. Between code climate and our RFC assertions, we should be ok so yeah, remove axe if you prefer so.

[ellinge]

Page down should render the next page, similar to what happens when you reach the last item via mouse scroll (it renders the next set of 100 items, which is our page size).

It currently goes to the actual last item. Guess End should only that that then (or arrow up on an unfocused control)

I was wondering the same. Between code climate and our RFC assertions, we should be ok so yeah, remove axe if you prefer so.

Realized since we set them dynamically, code climate won't detect them.
So, I'll leave axe since that's at least "rendered", even if only virtually.

[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 📦🚀

[mrchief]

🎉 This issue has been resolved in version 3.0.0 🎉

The release is available on:

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

Your semantic-release bot 📦🚀