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

Missing ARIA trees event support #652

Closed
powrsurg opened this issue Oct 21, 2016 · 10 comments
Closed

Missing ARIA trees event support #652

powrsurg opened this issue Oct 21, 2016 · 10 comments

Comments

@powrsurg
Copy link

Fancytree includes some of the keyboard events defined by the W3C for ARIA trees ( https://www.w3.org/WAI/GL/wiki/Using_ARIA_trees ). The missing keyboard events would be:

  • Enter: Toggle the expanded or collapsed state of the selected parent node.
  • Home: Select the root parent node of the tree.
  • End: Select the last visible node of the tree.
  • Tab: Navigate away from tree. (Fancytree does not code for this, but it seems to happen for me).
  • '*' (asterisk on the numpad): Expand all group nodes.

The W3C also indicates that double-clicking should effectively perform the same action as the Enter key. There have been previous posts questioning fancytrees events (see #578). While I understand the desire to keep things as-is, I believe that when the aria attribute is set the library should recognize that those using the library may need to follow the W3C spec for legal/compliance reasons and thus should implement the work arounds referenced.

@mar10
Copy link
Owner

mar10 commented Oct 21, 2016

Tab is already implemented. Home, End, and * could easily be added.
The behavior of Enter may also be changed, not sure yet if in general or only when options.ariais active.
I am not convinced that dblclick is a W3C requirement though, since it is targeted for

to users with disabilities, especially screen reader users and users who cannot use a mouse or other pointing device.

If you really need that, you can handle the dblclick event however.

@mar10
Copy link
Owner

mar10 commented Oct 22, 2016

Thinking a bit more about it, I don't even think that those keyboard shortcuts are a requirement, but just reccomendations:

The following keyboard shortcuts are implemented for this example (based on recommended shortcuts specified by the DHTML Style Guide Working Group.)

So the current behavior of Enter does not break aria compliance (please let me know if you have references that could clarify that)

I think that real compliance is rather about using the right ARIA markup in a way that screen readers handle it nicely. Here we could probably improve, but some help is welcome. See https://github.com/mar10/fancytree/wiki/SpecAria

@powrsurg
Copy link
Author

Those keyboard shortcuts are the basis behind what ARIA was aiming for with 1.0. The ARIA 1.1 best practices actually define more:

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

If you have questions on this, feel free to join https://gitter.im/w3c/a11ySlackers where people that actually work on the spec hang out to discuss issues.

@powrsurg
Copy link
Author

Also, the page you just linked isn't the markup we receive when setting things. What we've seen was closer to the B example from the Accessible Culture resource. When we added an aria-labelledby on the tree, and added aria-activedescendant (and potentially something else, I do not recall my work yesterday nor can access it until I get in on Monday) we were able to fully work with this library with NVDA, but VoiceOver doesn't seem to work. This seems odd since VO worked with the example pages for the library. We were still investigating this at the end of the day on Friday.

@mar10
Copy link
Owner

mar10 commented Oct 23, 2016

Yes, thats seems to be the problem, we have different client behavior. I experimented a bit a while ago, but did not find a final answer. Let me know what you find out. (I also asked this question at the a11y gitter channel)

@mar10
Copy link
Owner

mar10 commented Oct 23, 2016

From the gitter discussion I would think that the behavior of enter and dblclick is ok as is.
I will add the remaining keys.
We should also review the markup, and check with different ATs.

Thanks for your support!

I started a new branch for it:
https://github.com/mar10/fancytree/tree/aria
so we can explore and finalize without affecting working code.
Also created this issue #656 (also #655, but that is more involved)
Closing this in favor of #656

@mar10 mar10 closed this as completed Oct 23, 2016
@mar10
Copy link
Owner

mar10 commented Oct 29, 2016

@powrsurg did you have the time to look at the current markup or have any suggestions how to improve the behavior on different screen readers?

@powrsurg
Copy link
Author

I hadn't gotten to spend time looking at this during the week as we had spent time deploying code this week. I had just tested the sample-aria.html page from the branch linked above. It still does not work well with the latest NVDA and Firefox. It does not read off the current selection when the arrow keys are used to move around the tree. The work around for this that we had found was to set aria-activedescendant on the element with role="tree". The value of this attribute must be the id of the element receiving focus from moving with the arrow keys.

@mar10
Copy link
Owner

mar10 commented Oct 30, 2016

I modified the branch to update aria-activedescendant on the container.

Also looked at two online examples (Parciello, Open Ajax Aliance) which use different approaches.
For example one attaches the attributes to <li> the other to the embedded <span>:
https://github.com/mar10/fancytree/wiki/SpecAria

Both don't seem to work perfectly on VoiceOver, which I primarily have access to, but maybe you can recommend the best tradeoff, when using different ATs.

@powrsurg
Copy link
Author

NVDA needed the role="treeitem" on the span that receives the aria-activedescendant on the top example (the <ul>, not the <table>, else it read "text frame". For some reason the bottom worked fine as-is.

If I recall correctly from our testing, VoiceOver was terrible for us in El Capitan, but worked fine in Sierra.

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

No branches or pull requests

2 participants