Archive index

A11y Slackers Gitter Channel Archive 11th of July 2016

What fresh hell is THIS now? - Patrick Lauke
  1. Job van Achterberg
    @jkva
    Jul 11 07:23
    Morning folks =)
  2. Peter Krautzberger
    @pkra
    Jul 11 07:41
    Morning.
  3. Way to start a day: identify a stupid bug in Blink&WebKit and realizing it has been open for nearly 2 years on Chromium. I'm for a moratorium.
  4. https://bugs.chromium.org/p/chromium/issues/detail?id=408777
  5. zakim-robot
    @zakim-robot
    Jul 11 08:07
    [jv] morning
  6. zakim-robot
    @zakim-robot
    Jul 11 18:01
    [marcysutton] Good morning slackers. I wrote an article on Friday about links vs. buttons after being asked to write documentation about them and feeling like we're often painted into a corner by technical debt and design: https://marcysutton.com/links-vs-buttons-in-modern-web-applications/
  7. [marcysutton] There are probably more use cases I forgot so feel free to comment/chime in :)
  8. zakim-robot
    @zakim-robot
    Jul 11 18:08
    [dpogue] Might be worth mentioning that links cannot be disabled
  9. [marcysutton] I sort-of did in the bullet points, by saying buttons can be disabled
  10. zakim-robot
    @zakim-robot
    Jul 11 18:15
    [marcysutton] I’ve added a note about tabindex=“-1” and aria-hidden on links.
  11. [marcysutton] Thanks!
  12. Mark Sadecki
    @cptvitamin
    Jul 11 18:53
    Question RE Tab Panel Widgets: When you build a tab panel widget according to aria-practices, you can actually create a very awkward experience for screen reader users. The spec says that up and down arrow should behave exactly the same as left and right arrow, but up and down are the reading keys for Windows screen readers, so once you activate a tab and you want to read the contents of the associated tab panel, pressing the down arrow key will take you to the next tab and not the contents of the tab panel. The spec goes on to say that reaching the end of the tab list should cycle you to the beginning (and vice versa), so you are in effect removing the ability of the screen reader user to use their reading mode (http://w3c.github.io/aria/practices/aria-practices.html#tabpanel) Thoughts? is this a bug with the spec?
  13. We have thought of using aria-orientation, specifying horizontal, and then only listening for left and right arrow keys, hoping the screen reader users will infer that since its a horizontal tab list, only left and right arrow is supported.
  14. zakim-robot
    @zakim-robot
    Jul 11 19:04
    [michiel] cptvitamin: screen readers have a different mode for tabs widgets
  15. Mark Sadecki
    @cptvitamin
    Jul 11 19:05
    @michiel, what do you mean?
  16. zakim-robot
    @zakim-robot
    Jul 11 19:06
    [michiel] It's like tables mode; keys get assigned to different things.
  17. Mark Sadecki
    @cptvitamin
    Jul 11 19:06
    not latest versions of NVDA and JAWS
  18. zakim-robot
    @zakim-robot
    Jul 11 19:06
    [michiel] So a screen reader user will know they're on tabs instead of reading text.
  19. [michiel] Should be.
  20. Mark Sadecki
    @cptvitamin
    Jul 11 19:06
    yes, they are informed they are in a tab widget
  21. zakim-robot
    @zakim-robot
    Jul 11 19:06
    [michiel] Maybe ljwatson can elaborate.
  22. Mark Sadecki
    @cptvitamin
    Jul 11 19:06
    but they should still expect the down arrow to read them the next line of text
  23. zakim-robot
    @zakim-robot
    Jul 11 19:07
    [michiel] No, the interaction is closer to that of radio buttons.
  24. Mark Sadecki
    @cptvitamin
    Jul 11 19:09
    @michiel, so yeah, the problem arises when there are no focusable elements in the tab panel, so lets say there is a lot of text. Perhaps the next focusabel elemtn is in the footer of the page. If the user activates a tab, then hits the tab key, they move focus all they way to the footer, missing all the content in the tab panel. then they would have to arrow backwards through all the content.
  25. I could move focus to an inert element at the beginning of the tabpanel but that gets weird for sighted keyboard users
  26. zakim-robot
    @zakim-robot
    Jul 11 19:11
    [michiel] Hmm, SR's have a key combo to move into the tabs widget :)
  27. [michiel] StommePoes has brought up the akwardness of the tabs key interaction
  28. [michiel] There is an open issue for it: w3c/aria-practices#14
  29. Mark Sadecki
    @cptvitamin
    Jul 11 19:15
    @MichielBijl thanks!
  30. zakim-robot
    @zakim-robot
    Jul 11 19:23
    [michiel] No problem :)
  31. zakim-robot
    @zakim-robot
    Jul 11 19:31
    [michiel] Also seems this was fixed by jnurthen :)
  32. [michiel] w3c/aria-practices@d9fd7d7
  33. stevefaulkner
    @stevefaulkner
    Jul 11 19:34
    evening slackers
  34. zakim-robot
    @zakim-robot
    Jul 11 19:34
    [michiel] waves at Steve
  35. Mark Sadecki
    @cptvitamin
    Jul 11 19:41
    @MichielBijl I’m not out of the woods with the tab panel yet. JAWS and Edge (which nobody with accessibilty needs uses) reports that you can “Switch Pages” with CTRL + Tab when you are in a tab panel widget, but it doesn’t work (I think that is the screen reader keyboard shortcut you are referring to. It’s not announced in IE 11). In IE 11 and Firefox with JAWS 17 and latest NVDA not listening for UP and DOWN breaks reading mode all together because the screen reader focus is disconnected from the browser focus. Arrowing down in both browsers with both screen readers results in silence from NVDA and BLANK from JAWS.
  36. I think my best bet here is to move focus to an inert element at the top of the tab panel upon tab activation.
  37. I hate to do that because its wierd for sighted keyboard users
  38. zakim-robot
    @zakim-robot
    Jul 11 20:54
    [michiel] What I tend to do is put focus on the tab panel :)
  39. Mark Sadecki
    @cptvitamin
    Jul 11 21:09
    @MichielBijl yes, that is what our plan is. Unfortunately, we have to put an outline:none on that container to avoid the focus ring, so it could get a little weird for sighted keyboard users.
  40. thanks again. I spoke to Leonie and she gave some clear guidance
  41. StommePoes @StommePoes rages at using tab panels in the wild as a keyboarder... grrrrrr....
  42. zakim-robot
    @zakim-robot
    Jul 11 21:23
    [michiel] cptvitamin: I would note hide the focus ring
  43. [michiel] That would fail WCAG
  44. [alice] @michiel really? Even for a non-interactive element?
  45. [michiel] checks
  46. zakim-robot
    @zakim-robot
    Jul 11 21:28
    [michiel] 2.4.7 Focus Visible (Level AA)
  47. [michiel] All user interface elements that receive focus must have a visible focus indicator.
  48. [michiel] Tab panel is interface element, and it receives focus; so should have a visible focus indicator :)
  49. [alice] That seems ... lacking in nuance
  50. [alice] like, a lot of nuance
  51. [alice] e.g. in this case it only receives focus as an implementation detail
  52. [alice] not because it's going to take keyboard events
  53. [michiel] Well it makes sense; the point of a focus indicator is knowing where focus is.
  54. [michiel] If the tab panel doesn't receive focus you're still losing your place, no?
  55. [alice] If you could programmatically set the focus navigation start point and have AT focus follow that, I assert that that's what you'd do in this case
  56. [alice] because semantically (IMO) the tab panel doesn't "really" have focus in this case
  57. zakim-robot
    @zakim-robot
    Jul 11 21:33
    [alice] you're not going to type in it or activate it or change its value with the keyboard
  58. [michiel] That's true, but you would still want to know where focus is. At least, I would.
  59. [alice] To what end?
  60. [michiel] Well.
  61. [michiel] If a page loads I don't expect focus to be visible.
  62. [michiel] But if I—the user—press on tab I would like to see where it is.
  63. [michiel] The tabs widget is a bit crappy because there are a few different implementations around.
  64. [michiel] It's not like an input where the interaction is usually the same.
  65. [alice] If you "tab", focus will move to something in the tab order
  66. [alice] things in the tab order should absolutely have a focus style, I agree wholeheartedly with that bit :)
  67. [michiel] Yeah, so if you activate a tab in the tablist, and you tab to the tab panel, you should see the focus right?
  68. [michiel] Or are you making the case for automatically setting focus to the tab panel when you activate it?
  69. [michiel] Because then I can see your point.
  70. [alice] I'd expect hitting tab after activating a tab (argh multiple meanings of 'tab' here) would move to the first element in the tab order within the tab panel
  71. [alice] But perhaps that's mistaken.
  72. [alice] And yeah, I was assuming we were talking about moving focus programmatically :) thanks for clarifying
  73. zakim-robot
    @zakim-robot
    Jul 11 21:38
    [michiel] Yeah discussions about tabs in tab widgets while pressing tab are fun…
  74. [michiel] Right, what cptvitamin and I were discussing was setting focus to the tab panel instead of the first focusable.
  75. [michiel] But yeah, hitting the tab key after activation should focus first focusable either in the tab panel, or after the tabs widget
  76. [michiel] The problem I have with setting focus to the tab panel automatically is that you can have tabs widgets that automatically activate the tab panel after you've set focus to the tab in the tab list: https://www.youtube.com/watch?v=iRmX-GvFeXI
  77. [michiel] is getting sick of the word tab.
  78. [alice] setting focus to the tab panel makes sense to me
  79. [alice] and/or setting focus to the first element within the tab panel
  80. [michiel] Even if said tab is automatically activated?
  81. zakim-robot
    @zakim-robot
    Jul 11 21:43
    [alice] Right, depends how you get there
  82. [michiel] That's the only thing I hold against it.
  83. [michiel] So if the user activates the tab itself and focus is set to the tab panel programmatically I'm with you :)
  84. [alice] Right :)
  85. [michiel] And on that bombshell, I'm off to bed. Bye :)
  86. [alice] sleep well!