Archive index

A11y Slackers Gitter Channel Archive 11th of March 2016

What fresh hell is THIS now? - Patrick Lauke
  1. zakim-robot
    Mar 11 08:11
    [kevinchao89] <ol><h2 aria-label></h2></ol>
  2. zakim-robot
    Mar 11 08:12
    [kevinchao89] Label isn't being read in this instance. Why?
  3. MichielBijl
    Mar 11 09:02
    Because it has no content?
  4. MichielBijl
    Mar 11 09:02
    Or because your HTML is invalid (ul can only have li as direct descendants)
  5. MichielBijl
    Mar 11 09:03
    @kevinchao89
  6. Good gracious. NaturalReader.
  7. MichielBijl
    Mar 11 11:29
    Great balls of fire?
  8. :+1:
  9. zakim-robot
    Mar 11 12:56
    [karlgroves] Anyone here have an HTML version of a VPAT?
  10. stevefaulkner
    Mar 11 13:18
    @karlgroves how about the google vpats https://www.google.com/mail/help/accessibility.html
  11. zakim-robot
    Mar 11 13:19
    [karlgroves] Thanks! That’s actually pretty clean HTML too
  12. zakim-robot
    Mar 11 13:21

    [karlgroves] Its a good start. Some stuff I’d do differently, but I really didn’t want to do the entire thing from hand if I didn’t have to.

    Thanks, Steve

  13. @MichielBijl @stevefaulkner should I be worried that nobody responded to w3c/aria#290 ? Not that I had super high expectations :(
  14. MichielBijl
    Mar 11 15:01
    No, I'll have a look at it next week/this weekend.
  15. MichielBijl
    Mar 11 15:02
    Most issues stay open for a while unfortunately :(
  16. MichielBijl
    Mar 11 15:02
    We're all busy to get the next heartbeat publication ready ;)
  17. stevefaulkner
    Mar 11 15:03
    @pkra it may take 'em months, I file stuff all the times and wait and wait...
  18. Thanks, @MichielBijl @stevefaulkner. No worries. I work with MathML; patience is my strong suit ;-)
  19. PS: blog post is almost ready...
  20. stevefaulkner
    Mar 11 15:05
    :+1: cool look forward to reading and socialising ;-)
  21. powrsurg
    Mar 11 15:49
    Okay. Got our streaming video player to be able to keyboard to every button in the player, supports common keyboard commands (though I still can't find any WCAG documentation on what you should have, but the players I've tested mostly support the same commands), supports closed captioning (not sure if we should enable them by default or not, but they can be toggled), and screen readers will read off any audio description tracks
  22. powrsurg
    Mar 11 15:49
    and it's responsive.
  23. powrsurg
    Mar 11 15:49
    only issue is that if there is any buffering in the video player the description tracks could get ahead of the video ...
  24. stevefaulkner
    Mar 11 15:49
    @powrsurg :clap:
  25. powrsurg
    Mar 11 15:49
    am I missing anything else that one should do?
  26. powrsurg
    Mar 11 15:51
    I mean, I guess aside from trying to figure out the buffering thing ...
  27. zakim-robot
    Mar 11 16:20
    [poorgeek] test it on different mobile browsers? I seem to remember an issue with WebVTT captions and a version of iOS
  28. zakim-robot
    Mar 11 16:24
    [poorgeek] nm. that was specifically an issue with JWPlayer 6 interacting with iOS7
  29. powrsurg
    Mar 11 16:44
    yeah, I saw that with everything. But I'm basing this on videoJS and not JWPlayer. JWPlayer missed one thing I wanted
  30. zakim-robot
    Mar 11 16:52
    [sufian] hey I've got a question about keyboard navigation: I've heard that it's a good idea to have skip-to-content links (or any internal links via fragment URLs) to also cause focus to move to the target section of the document; I've also heard that this is a bug in some browsers (assuming that the correct behavior is implemented in other browsers), but I can't seem to find any bug report pages on any of the browser issue trackers
  31. zakim-robot
    Mar 11 16:52
    [sufian] does anyone know of the state awareness for browsers with respect to this topic?
  32. zakim-robot
    Mar 11 16:53
    [sufian] oh hey, just found one for chrome https://bugs.chromium.org/p/chromium/issues/detail?id=115185
  33. powrsurg
    Mar 11 16:53
    chrome and IE have similar bugs. Give your target a tabindex="-1" fixes both
  34. powrsurg
    Mar 11 16:54
    if I understand what you're saying
  35. zakim-robot
    Mar 11 16:56
    [sufian] yeah, that's what I'm asking about
  36. zakim-robot
    Mar 11 16:57
    [sufian] is the correct behavior that focus should only be moved if the target has tabindex="-1" set? (or is able to be focused)
  37. powrsurg
    Mar 11 17:25
    tabindex="-1" is for programmatic focus (via JS) but seems to also work as part of a fragment URL. tabindex="0" lets someone tab to that element like it was a form input, a link, etc
  38. zakim-robot
    Mar 11 17:40
    [sufian] yeah
  39. zakim-robot
    Mar 11 17:41
    [sufian] I just tested on a range of browsers https://sigusrone.com/misc/fragment-navigation-keyboard.html -- looks like all the ones I checked implement the w3c's html5 spec
  40. zakim-robot
    Mar 11 17:41
    [sufian] and it looks like the html5 says that keyboard focus not be "moved" to the target unless the target is itself focusable
  41. jnurthen
    Mar 11 18:40
    @powrsurg did you find common keyboard controls in your media player investigation?
  42. jnurthen
    Mar 11 18:41
    We really need to add a media player section in the APG - but I have little expertise in the area
  43. powrsurg
    Mar 11 19:38
    In general, the free VideoJS player has the best accessibility support over two of the biggest commercial players
  44. powrsurg
    Mar 11 19:39
    well, VideoJS requires a plugin to add the support, but the plugin is also free and good so that helps
  45. jnurthen
    Mar 11 19:43
    videojs is totally free (for commercial use too?)
  46. jnurthen
    Mar 11 19:43
    correct?
  47. powrsurg
    Mar 11 19:43
    Flowplayer angered me because it was so close to working. But to get it actually working properly require basically copying the code from the live player and re-adding it properly. You can't call the intended buttons because it encapsulated everything
  48. powrsurg
    Mar 11 19:44
    apache license
  49. powrsurg
    Mar 11 19:45
    v2
  50. jnurthen
    Mar 11 19:46
    ok
  51. powrsurg
    Mar 11 19:46
    No player lets you enable/disable the closed captioning with a keyboard command, but VideoJS lets you tab to it at least. If you fix flowplayer you can do so I believe
  52. jnurthen
    Mar 11 19:47
    I think tabbing to less frequently used controls is absolutely fine
  53. jnurthen
    Mar 11 19:47
    no one ever remembers keyboard shortcuts anyway
  54. powrsurg
    Mar 11 19:47
    none of them do audio descriptions really well. I ended up pulling code from https://accessibility.oit.ncsu.edu/video/audiodescriptions/headingsmap-captions-audiodescription.html to get it working
  55. powrsurg
    Mar 11 19:48
    by well I mean at all really
  56. powrsurg
    Mar 11 19:49
    I added a <div> that is invisible to the user that gets the description read off to them by a screen reader
  57. powrsurg
    Mar 11 19:49
    oh with that URL above there are mix-content issues you'd have to allow to even get it working
  58. jnurthen
    Mar 11 19:49
    I've never done voiced audio descriptions. I've always done them using an alternate soundtrack (which includes the original sound and the audio description)
  59. powrsurg
    Mar 11 19:50
    I'm using <track> elements for it
  60. jnurthen
    Mar 11 19:51
    interesting.
  61. powrsurg
    Mar 11 19:52
    I'm making a player our clients can use for their employees for online training to take courses. They are uploading one video which we are doing on-demand streaming. I know most won't have any type of captioning done (but I wanted to allow them to do so). I know it'd be incredibly unlikely for them to have two versions of the same video
  62. powrsurg
    Mar 11 19:52
    Also the <track> method makes aXe not complain and it's something one should be doing. :p
  63. jnurthen
    Mar 11 20:02
    i was talking about the audio descriptions not captions
  64. StommePoes
    Mar 11 20:03
    @sufian -> "and it looks like the html5 says that keyboard focus not be "moved" to the target unless the target is itself focusable" It may say that because the vendors don't seem to call whatever it is that moves the exact same thing as "keyboard focus", however in the broken browsers (all Blink, Webkit and KHTML due to one bug (recently fixed but not all out in the wild!) and IE5-11) the next tab is broken
  65. StommePoes
    Mar 11 20:03
    So in the Chromium bug, where they've fixed it, they use the more technical term
  66. StommePoes
    Mar 11 20:04
    the "sequential focus navigation starting point" https://bugs.chromium.org/p/chromium/issues/detail?id=454172
  67. powrsurg
    Mar 11 20:35
    yeah, I was adding info
  68. zakim-robot
    Mar 11 20:44
    [sufian] StommePoes: oh good to know, thanks!
  69. StommePoes
    Mar 11 20:53
    I still use the negative tab index, because webkit, IE aren't fixed and my Chromes and chromiums haven't gotten any updates yet with the fix
  70. powrsurg
    Mar 11 21:02
    given how many custom mobile browsers there are out there that will never get an updated webview it's still good to do (of course that assumes that skip-tos are useful for those mobile users)
  71. zakim-robot
    Mar 11 23:39
    [fstorr] Question on expanding abbreviations: it seems like best practice is to expand them in plain text as well as using the title attribute (https://www.paciellogroup.com/blog/2013/01/using-the-html-title-attribute-updated/). Should that expansion happen within the <abbr> element (eg <abbr title=“North American Space Agency”>NASA (North American Space Agency)</abbr>) or outside <abbr title=“North American Space Agency”>NASA</abbr> (North American Space Agency) The title attribute expands it within the context of the element so I can see some logic in also having the expanded plain text in it as well; on the other hand, the expanded plain text isn’t the abbreviation itself so can see not keeping it in there might also make sense.