Archive index

A11y Slackers Gitter Channel Archive 23rd of October 2016

What fresh hell is THIS now? - Patrick Lauke
  1. Martin Wendt
    @mar10
    Oct 23 09:39
    Hello everybody,
  2. Martin Wendt
    @mar10
    Oct 23 10:57

    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:

    • Are keyboard shortcuts ( as reccomended here ) part of ARIA compliance? I would think, that a page author can decide to use ENTER to activate a node instead of expanding, even if even if the https://www.w3.org/TR/wai-aria-practices-1.1/#TreeView proposes another implementation.
    • Same for mouse handling: is it mandatory for compliance to implement a dblclick as 'expand node'?

    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:

    • what is the authorative approval for a distinct implementation?
    • Which screen readers are considered 'reference'

    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

  3. stevefaulkner
    @stevefaulkner
    Oct 23 11:27

    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.

  4. Martin Wendt
    @mar10
    Oct 23 12:43
    100% agreed, and this is a rule for good usability in general (btw. <kbd>ENTER</kbd> is interpreed as 'rename node' in Mac Finder).
    What I would like to know is: what are the requirements for claiming WAI-ARIA compliance of a tree/tree grid? Who can give authorative advice? Are there test suites, or best practices?
    I tried a bit and there seems to be different behavior on different screen readers, but I may be wrong.
  5. zakim-robot
    @zakim-robot
    Oct 23 12:58

    [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

  6. Martin Wendt
    @mar10
    Oct 23 13:37
    This message was deleted
  7. Martin Wendt
    @mar10
    Oct 23 14:20

    @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?

  8. zakim-robot
    @zakim-robot
    Oct 23 14:26

    [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

  9. Martin Wendt
    @mar10
    Oct 23 14:33
    I do this already.
  10. zakim-robot
    @zakim-robot
    Oct 23 14:33

    [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/

  11. [karlgroves] With regard to expecting double click support: I don’t see that in the official APG doc I mentioned above
  12. zakim-robot
    @zakim-robot
    Oct 23 14:39
    [karlgroves] (Then again, they don’t mention click behavior anywhere)
  13. Martin Wendt
    @mar10
    Oct 23 14:44

    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!

  14. @zakim-robot I think that @powrsurg referred to (just guessing)

    NOTE: Double-clicking on a parent node will toggle its expanded or collapsed state.

    here https://www.w3.org/WAI/GL/wiki/Using_ARIA_trees

  15. zakim-robot
    @zakim-robot
    Oct 23 14:50

    [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)

  16. zakim-robot
    @zakim-robot
    Oct 23 16:52
    [wendykelly] Good morning :) Yesterday I watched @karlgroves presentation at Fronteers ( https://vimeo.com/163074780) then watched @marcysutton and Estelle Wyle’s presentations as well…
    So then, of course, I watched the set on perceived time and visual performance….
    I am curious if anyone would like to help me understand the relationship between the two ideas.
    More to the point: do a11y and visual performance best practices play well together?
  17. zakim-robot
    @zakim-robot
    Oct 23 17:28
    [marcysutton] @wendykelly: they do to a point. By optimizing assets to get pages to load fast, you will undoubtedly make them ready to use sooner. In my talk, however, I argued that perceived performance is only visual (like the DIV outlines added to facebook on load) and that we should also test for functional performance. i.e. how quickly can I start typing?
  18. zakim-robot
    @zakim-robot
    Oct 23 17:43
    [marcysutton] I did another version of that talk that was twice as long, might be useful? https://www.youtube.com/watch?v=RkbyP-OJRgw
  19. zakim-robot
    @zakim-robot
    Oct 23 18:34
    [marcysutton] Ooh I thought of this too–Tim Kadlec and Katie Kovalcin have a podcast all about performance and they kindly invited me to chat with them about accessibility https://pathtoperf.com/2016/09/29/12-with-marcy-sutton.html
  20. [wendykelly] Thank you!!
  21. zakim-robot
    @zakim-robot
    Oct 23 20:28
    [miwayha] dumb voiceover question: whenever i have voiceover on and i’m trying to work this autocomplete widget in safari, the up and down arrow keys don’t work, but in chrome they do. any thoughts? http://jqueryui.com/resources/demos/autocomplete/default.html
  22. [miwayha] it’s not just that autocomplete widget: it’s any accessible autocomplete widget i’ve been able to find: arrows work fine with VO + Chrome, not with VO + Safari