Gitter Channel Archive 23rd of October 2016
Gitter Channel Archive 23rd of October 2016
What fresh hell is THIS now? - Patrick Lauke
I am the the author of a jQuery tree/treegrid widget (Fancytree) and I would like to add ARIA support.
There is already an option to enable it, and some aria-... attributes are added. However there are still some open questions to me:
To my understanding, the most important thing is to assign aria- attibutes to the generated elements in a way such that screen readers handle it nicely.
But then:
Maybe someone can give some input, or even help improving the spec: https://github.com/mar10/fancytree/wiki/SpecAria
Current implementation here: http://wwwendt.de/tech/fancytree/demo/sample-aria.html
Hi @mar10
Are keyboard shortcuts ( as reccomended here ) part of ARIA compliance?
The design patterns describe common standard interaction patterns for the most part. Where ever widgets have a desktop application counterpart, the keyboard advice is similar/same to what platform conventions are. In this way interoperability is improved. Users have expectations about how they can interact with UI widgets, suggest it best to code to support those expectations.
[karlgroves] I think that Steve’s answer was the comprehensive one. One of the most important parts of WAI-ARIA is to allow developers to indicate Name, State, Role, and Value to users. When you create a widget that uses ARIA, the assistive technologies can indicate to the user what type of control they’re on and what it is doing. AT will also provide hints to the user on how to interact with that type of control.
As Steve said:
Where ever widgets have a desktop application counterpart, the keyboard advice is similar/same to what platform conventions are.
In other words, not supplying all the expected keyboard behaviors is basically supplying the user with a broken experience because your widget will not behave in ways they expect
@zakim-robot, @stevefaulkner Maybe my question was not clear enough.
I am not argumenting against keyboard shortcuts. Fancytree already is completely controllable using the keyboard (see the online example).
@powrsurg mar10/fancytree#652 for incomplete ARIA compliance.
The missing home, end, * shortcuts are easy to implement and make sense, so no problem here.
The issue also asked for implementing dblclick as 'expand node', referring to this spec](https://www.w3.org/WAI/GL/wiki/Using_ARIA_trees).
My understanding was, that dblclick may have other useful implementations - such as editing a node - and if an author chooses to implement it that way, this should not make it "not-ARIA-compliant".
Maybe this topic is obsolete anyway, since the referred-to spec is obsoleted by this spec which does not mention mouse events for trees?
I think the keyboard handling is trivial to implement, and it is good to have the ARIA guides here.
What is not trivial (in my experience) is to add the right aria attributes in a way, such that all screen readers provide good experience to disabled users.
The current demo (see link above) already adds ariaattributes and roles, but is this enough or optimal?
How can I know or improve this?
[karlgroves] > What is not trivial (in my experience) is to add the right aria attributes
I can’t understand this line of argument. Of course you can. For instance, if a node is collapsed and then an event is fired to expand it, of course you can modify aria-expanded value accordingly when you change the display property on the children
[karlgroves] > How can I know or improve this?
By following the design pattern completely. It seems like you’re overthinking it here.
I don’t want to bore you with the complete history of how this document came to be, but suffice it to say that a shitload of research and work went into the ARIA authoring practices doc and that list of editors and contributors on the doc are some of the brightest in a11y
Just. Follow. The. Pattern.
https://www.w3.org/TR/wai-aria-practices-1.1/
Main reason for me to enter this chatroom was that last time I tried the markup with different readers (a few years ago), it did not seem very usable and behaved very different on different clients.
Ok then, I will look if there are some changes since I last looked into the specs, and try to follow as close as possible, and see what happens - thanks for your time!
@zakim-robot I think that @powrsurg referred to (just guessing)
NOTE: Double-clicking on a parent node will toggle its expanded or collapsed state.
[karlgroves] Generally speaking, you should anticipate weirdness across AT on certain widget types - including a difference in how it behaves with the screen reader on vs. off. I’ve been bitten by this a handful of times with VO, specifically. You may need to wrap the tree in a DIV with role=application to get it to work reliably.
Just a note regarding that doc you cite: take a look at the disclaimer at the top of the page.
That being said, I’m interested in seeing the folks from APG weigh in (cc @jamesn @stevef)