Archive index

A11y Slackers Gitter Channel Archive 31st of August 2016

What fresh hell is THIS now? - Patrick Lauke
  1. zakim-robot
    @zakim-robot
    Aug 31 02:17
    [caesar] Hi guys. Does anybody know of a resource or advice regarding the use of links within checkbox/radio button elements, e.g. "I accept the [Terms and Conditions]" where "Terms and Conditions" is a link?
  2. [caesar] I know there is an Android Talkback limitation where it will either toggle the checkbox or activate the link, but not both. Anything else?
  3. zakim-robot
    @zakim-robot
    Aug 31 03:30
    [garcialo] @caesar Do you have a public example so I don't have to mock one up myself?
  4. [caesar] Here's a pen I made just a little while ago: https://codepen.io/cyberseraphic/full/GjKQwY/
  5. [caesar] (Just made a quick edit)
  6. zakim-robot
    @zakim-robot
    Aug 31 03:58
    [garcialo] Didn't find anything that seems bad on NVDA+Firefox or VO+Safari on either Mac OS or iOS
  7. [caesar] Thanks. I think we noticed that if the <label> association is not explicit (i.e. missing "for" attribute) then it behaves strangely in some combos
  8. [caesar] Plus on Android there is definitely a problem. The elements cannot receive focus independently
  9. [caesar] Just wondering if this had been documented anywhere, or if there was any advice around this as a general practice (whether to avoid or not).
  10. luis garcia
    @garcialo
    Aug 31 04:05
    Yeah, don't know of anything specific that's been documented. Wait a day or so and @stevefaulkner will post a blog about it.
  11. zakim-robot
    @zakim-robot
    Aug 31 04:20
    [caesar] Haha...
  12. [caesar] He's already done the implicit vs explicit labelling part... https://www.paciellogroup.com/blog/2011/07/html5-accessibility-chops-form-control-labeling/
  13. stevefaulkner
    @stevefaulkner
    Aug 31 06:33

    @caesar there is some advice i put into the HTML5 spec about it. Read the note and related examples:

    The ability to click or press a label to trigger an event on a control provides usability and accessibility benefits by increasing the hit area of a control, making it easier for a user to operate. These benefits may be lost or reduced, if the label element contains an element with its own activation behavior, such as a link:

    https://w3c.github.io/html/sec-forms.html#the-label-element

  14. Ian Devlin
    @iandevlin
    Aug 31 06:34
    Good morning/afternoon/evening/night.
  15. zakim-robot
    @zakim-robot
    Aug 31 06:36
    [caesar] Thanks @stevefaulkner!
  16. Job van Achterberg
    @jkva
    Aug 31 07:09
    Morning folks
  17. zakim-robot
    @zakim-robot
    Aug 31 08:29
    [felixzapata] hi all, I always liked it the focus transition inside WebAIM.org webpage. Based on it, I've created a Polymer component called "flying-focus" to use this behavior. I would like to receive feedback. https://github.com/felixzapata/flying-focus
  18. zakim-robot
    @zakim-robot
    Aug 31 09:41
    [felixzapata] one more thing, It is possible I rename the component to something like flying-focus-xxxxx
  19. Fiona Holder
    @FionaHolder
    Aug 31 09:46
    morning
  20. that's a neat focus effect :)
  21. Ian Devlin
    @iandevlin
    Aug 31 10:13
    I have a question which I could Google to be fair, but this room is like a Google of Accessibility Experts so the results returned will have far greater value :D
  22. Léonie Watson
    @LJWatson
    Aug 31 10:13
    Heh. Flattery will get you everywhere :)
  23. Ian Devlin
    @iandevlin
    Aug 31 10:13
    Is it possible to automate keyboard accessibility testing? I would assume so, but has anyone used any testing frameworks that support this?
  24. Well Leonié, it is true!
  25. Oops, I put the accent on the wrong character
  26. Sorry.
  27. Léonie Watson
    @LJWatson
    Aug 31 10:14
    NP - at least you got the accent in the first place :)
  28. I believe Selenium has been used for this purpose.
  29. Ian Devlin
    @iandevlin
    Aug 31 10:14
    I always try and write people's names correctly!
  30. Ah ok, thanks, I will investigate further!
  31. Léonie Watson
    @LJWatson
    Aug 31 10:17
    Thisis more about a11y testing with selenium, but it might give you some pointers http://www.deque.com/blog/accessibility-testing-axe-webdriverjs/
  32. Ian Devlin
    @iandevlin
    Aug 31 10:24
    Ah excellent, thanks again!
  33. Léonie Watson
    @LJWatson
    Aug 31 10:24
    NP
  34. zakim-robot
    @zakim-robot
    Aug 31 13:41
    [karlgroves] @iandevlin: Yes. Essentially you’d want to automate the key events and test for their effects. Selenium is a key component of that. I often use Selenium and Karma with Chai for this. You might also want to check out CodeceptJS for this. It has a very low barrier to entry
  35. Ian Devlin
    @iandevlin
    Aug 31 13:48
    Thanks Karl.
  36. zakim-robot
    @zakim-robot
    Aug 31 14:08
    [karlgroves] @iandevlin when I’m in Germany I’ll show you some fun stuff. ;)
  37. Ian Devlin
    @iandevlin
    Aug 31 14:11
    Great!
  38. zakim-robot
    @zakim-robot
    Aug 31 15:32
    [hidanielle] Hi all, I have a weird bug I'm dealing with, where using NVDA in Firefox, navigating with the down arrow key, it goes through content in the wrong order, starting with: top nav -> footer -> main content. The order should be: top nav -> content -> footer. The tab order however works and goes through the page as expected.
  39. [hidanielle] Anyone have any resources specifically about reading a page with the arrow keys that might help? I've tried to google but found nothing :(
  40. Fiona Holder
    @FionaHolder
    Aug 31 15:35
    What's the order in the HTML?
  41. zakim-robot
    @zakim-robot
    Aug 31 15:35
    [hidanielle] the correct order
  42. Fiona Holder
    @FionaHolder
    Aug 31 15:36
    strange, not something I've seen before
  43. zakim-robot
    @zakim-robot
    Aug 31 15:38
    [hidanielle] very odd
  44. zakim-robot
    @zakim-robot
    Aug 31 16:06
    [marcysutton] Thanks for sharing my post Leonie! Iandevlin -- you can test keyboard stuff with PhantomJS so it can be a headless browser, there are some issues with testing visual :focus but mechanics-wise it works pretty well. Selenium is a lot more reliable but it's more slow.
  45. [marcysutton] You can use a karma-chrome or karma-firefox launcher if you want a real browser
  46. [marcysutton] This also seems obvious to me now but I learned in the past few weeks of React testing that the DOM has to be fully rendered and attached (but it can be headless)
  47. Mallory
    @StommePoes
    Aug 31 16:24
    I haven't managed to make Phantom do the right thing at all with keystrokes
  48. or simulated clicks
  49. but it could be the problem is in (one of the) expect.js rather than phantom?
  50. So we're just abandoning writing these test in JS entirely and moving them all to Selenium.
  51. I also have a possibly unsolveable problem of making a keyboard trap in a component (whom I've decided to treat like a modal otherwise there's little sane use of it) where the focusables inside... can be changed at whim by other scripts I can't listen for.
  52. If I could call a "shiftTab()" function in Javascript I'd be all set :/
  53. or whatever would mean "focus on the previous whatever the browser would focus on if you did anything similar to a shift-tab" since if you're using Opera 12 or some mobile shift-tab makes no sense.
  54. I should have some way of telling the browser "act like focusables in this container are the only ones existing on the page" because I can't write for all the various ways keyboard-focus can be moved by users.
  55. Listening for tab and shift on first and last items, or listening for "is the restricted area a container of the current activeElement" are hacky and don't allow users the full freedom they need (like tabbing instead of ctrl-L-ing to addressbar and tools)
  56. Mallory
    @StommePoes
    Aug 31 16:30
    When we need to trap keyboard, we are all writing crappy crap piles of poo (except not as cute)
  57. We need a poop-dogey dog
  58. SO STINK! MUCH CRAPPY! WOW!
  59. zakim-robot
    @zakim-robot
    Aug 31 18:00
    [marcysutton] Keyboard focus traps are challenging even before you get into tests. It's the same steaming pile we're trying to solve with inert
  60. James Nurthen
    @jnurthen
    Aug 31 18:01
    What is the status of inert?
  61. Mallory
    @StommePoes
    Aug 31 18:03
    whatever it is, it's not somewhere I can use it safely I believe
  62. zakim-robot
    @zakim-robot
    Aug 31 18:06
    [marcysutton] It's being discussed: whatwg/html#1474 there is a polyfill by @alice
  63. [marcysutton] That's a hard problem when you know where something is inserted into the DOM, like a modal. But in UI framework-land it's even more difficult when developers have control over where things get inserted. a lot of DOM walking and manipulation
  64. James Nurthen
    @jnurthen
    Aug 31 18:10
    Glad to hear inert hasn't gone away completely. It is badly needed and will simplify a lot of code once it is there.
  65. Mallory
    @StommePoes
    Aug 31 18:36
    Not just simplify
  66. this is f*cking Jenga
  67. just waiting to collapse in some places
  68. Javascript just isn't capable of doing some of the things we need to do.
  69. var delegate = new DomDelegate(document.body);
    delegate.on('click focus', '*', doAllTheThingsInEndlessLoopsForever);
  70. LIsten to all the things, for all the things, and do lots of stuff.
  71. all the time for all the things
  72. and then some more thingas
  73. s/thingas/things
  74. Job van Achterberg
    @jkva
    Aug 31 18:38
    Just wait until we get proper multithreading on the client
  75. That will be fun
  76. "We have to deal with locks?!"
  77. Mallory
    @StommePoes
    Aug 31 18:39
    manual locks? We'll make browsers do it for us
  78. but before it becomes spec
  79. there'll be a decade of terrible race-condition-or-locked codez
  80. Job van Achterberg
    @jkva
    Aug 31 18:40
    Indeed
  81. And actor-based concurrency will be reinvented on the client
  82. ErlangJS
  83. Mallory
    @StommePoes
    Aug 31 18:40
    The browser will also have its own separate event scheduler
  84. per tab
  85. yes
  86. Google better be listening. Chrome can advertise how awesome it is by having each tab contain it's own event scheduler
  87. Job van Achterberg
    @jkva
    Aug 31 18:42
    @stommepoes you want multithreaded event handling per tab?!
  88. God no
  89. That's giving everybody a whole bunch of ropes to hang themselves with /and/ the guns to shoot themselves in the foot
  90. But at least npm would install faster
  91. (And yes, I know it's node, which actually has a thread pool that we don't get to touch)
  92. Mallory
    @StommePoes
    Aug 31 18:50
    oh but they'll want it per tab
  93. I just want a focus-previous-thing command :(