Archive index

A11y Slackers Gitter Channel Archive 2nd of October 2015

What fresh hell is THIS now? - Patrick Lauke
  1. garcialo
    01:38
    Is the double content from the aria-label AND the text?
  2. garcialo
    01:38
    Does it need the aria-label for it to be read at all?
  3. zakim-robot
    01:41
    [Dirk Ginader, a11y] it’s not reading it double. The content just has to be in the DOM twice for this to work. One for the visual with the partially bolded text inside of the Node and the second for the screen readers to be able to read it properly in the aria-label attribute.
  4. garcialo
    02:22
    Ah, I see.
  5. stevefaulkner
    09:02
    @garcialo aah, but do you?
  6. zakim-robot
    11:12
    [heydon, a11y] So, I’m testing with VoiceOver OSX and I find something really difficult as a test user: If I navigate to a heading using VO+CMD+H, I’d expect to be able to hit TAB and it would focus the next link under the heading, but focus stays above the heading I’ve navigated to. VO seems to treat TAB like a normal kbd control but uses a virtual/superimposed navigation for other commands. Am I missing something obvious? It doesn’t feel right that, once I’ve navigated to a heading (or any other part of the page), TAB becomes essentially useless.
  7. LjWatson
    11:48
    @Heydon what are you finding difficult?
  8. garcialo
    12:23
    @stevefaulkner Oh, but I do.
  9. MichielBijl
    12:36
    @garcialo Haha, “how many <main>'s should your website have?”
  10. MichielBijl
    12:38
    “One, it's called the <main>!” “Turns out it should have two” “Based on the latest evidence, it should have about 18.000!” “We lied to you, it should really have none; there is evidence that your main content could actually be a separate page!”
  11. MichielBijl
    12:38
    Oh the joys of specifications
  12. LjWatson
    12:40
    Two <main> elements walk into a bar. They sit down and the first says "Oh there's the bar - I immediately recognize it because it doesn't look like a table
  13. LjWatson
    12:40
    or a jukebox or a restroom. It seems so simple an observation but it's really important: Identifying the one important thing really matters." "Obviously,"
  14. LjWatson
    12:40
    says the second. "Great" says the first, "Just making sure we're on the
  15. LjWatson
    12:40
    same page".
  16. LjWatson
    12:40
    Heard yesterday courtesy of @bkardell
  17. rodneyrehm
    12:41
    evidently, that's evidence that the amount of evidence is evident
  18. MichielBijl
    12:51
    Haha, I have to save that one!
  19. zakim-robot
    13:01
    [heydon, a11y] @ljwatson: Simply that navigating by, for example, heading does not bring focus with it, so when I’ve gone to a heading (it shows a visible marquee), my focus is still elsewhere.
  20. zakim-robot
    13:13
    [dylanb, a11y] @heydon: the header is not focusable, so it cannot receive focus
  21. zakim-robot
    13:13
    [dylanb, a11y] the screen reader does not intercept the TAB key
  22. zakim-robot
    13:13
    [dylanb, a11y] it has other keys for navigating by DOM
  23. zakim-robot
    13:13
    [heydon, a11y] @dylanb
  24. zakim-robot
    13:14
    [heydon, a11y] Yeah,
  25. zakim-robot
    13:14
    [dylanb, a11y] it seems logical to me
  26. zakim-robot
    13:14
    [dylanb, a11y] but hey, that does not mean its intuitive
  27. zakim-robot
    13:15
    [heydon, a11y] I guess it’s just one of those things between virtual mode and non-virtual, but it is really annoying for me because I have to remember all the six-key-mash commands whenever I’m crawling the virtual tree. I wish there was a get-out.
  28. zakim-robot
    13:17
    [heydon, a11y] I find it weird that the TAB key is not intercepted. If I’m on a heading, that’s where I want to physically be in the document, right?
  29. zakim-robot
    13:18
    [dylanb, a11y] by definition, that is right
  30. zakim-robot
    13:19
    [dylanb, a11y] how can we tell you where you want to be is not right :simple_smile:
  31. stevefaulkner
    13:23
    @LjWatson as I have said before @bkardell is a JOKEr
  32. LjWatson
    13:57
    @Heydon have to agree with @dylanb on this one. Besides... for the most part we screen reader users don't need focus to move to non-focusable elements - we just want to read them.
  33. powrsurg
    14:03
    I think there is a disconnect from where a person's reading position in the document and the focus in that changing focus should keep up with your position in the document (not that I agree, but I can see where the expectation is that if you jumped to that position in a document you would like the next focusable item to occur from that position.
  34. powrsurg
    14:04
    That said, that seems like an expectation would likely would only have if you're a sited user using a screen reader (like for testing). At least that is what I would assume
  35. powrsurg
    14:06
    and this morning I finally got to trying the modality thing that @rodneyrehm pointed out yesterday and I am so happy with this. Thank you slackers. :)
  36. powrsurg
    14:06
    (is that what you'd actually like to be called in here?)
  37. zakim-robot
    14:07
    [dylanb, a11y] @powrsurg a11ys
  38. powrsurg
    14:07
    okay, thank you a11ys
  39. LjWatson
    14:09
    @powrsurg that's how it works. If you read a heading (with a screen reader) and hit tab, you'll go to the next focusable thing in the DOM after the heading.
  40. zakim-robot
    14:12
    [dylanb, a11y] @ljwatson: only if the focus is currently in a focusable element above the heading with no other focusable element in between - right?
  41. powrsurg
    14:13
    that's not how I interpreted what @Heydon was saying he was experiencing in VoiceOver (but was what he wanted)
  42. zakim-robot
    14:15

    [heydon, a11y] @ljwatson @dylanb I want / expect to be able to move to the first focusable thing after the selected heading. In VO, I can’t get it to do what you said (see quote below):

    “If you read a heading (with a screen reader) and hit tab, you'll go to the next focusable thing in the DOM after the heading."

  43. zakim-robot
    14:17
    [dylanb, a11y] @heydon: it should do that only if the focus is currently in a focusable element above the heading with no other focusable element in between
  44. zakim-robot
    14:19
    [heydon, a11y] @dylanb In other words, moving to the heading using virtual buffer has no effect on focus / location in document, unless intercepted actions are employed (like VO+CMD+L, which would go to the next link after the heading regardless of where focus is)
  45. zakim-robot
    14:19
    [heydon, a11y] That’s what annoys / confounds me :disappointed:
  46. zakim-robot
    14:19
    [dylanb, a11y] What @ljwatson is referring to is a side-effect of a common way of navigating a page...the user will use the down arrow (or CMD-OPTION-RIGHT in VO) to traverse the DOM in order, reading as they go. When the screen reader encounters a focusable element, it will set focus to that (assuming default settings) if the user carries on traversing and maybe skips ahead to a heading, then pressing the tab key will most likely end up in the next focusable element after the heading...but only because of the side effect of that usage pattern
  47. zakim-robot
    14:21
    [heydon, a11y] Huh, didn’t know encountering an elem not via TAB / JS focus told VO it was focused. For me, next element is CTRL+OPTION+RIGHT, not CMD?
  48. zakim-robot
    14:22
    [dylanb, a11y] yes, sorry - CTRL
  49. zakim-robot
    14:23
    [heydon, a11y] Well, thanks for the tip. I guess the focusing-dynamically-while-browsing-virtual-DOM is something to help with navigation, diminishing my frustration :wink:
  50. zakim-robot
    14:24
    [dylanb, a11y] giphy: http://giphy.com/gifs/beyonce-beyonc-gmlscrn-yFjtJZdIGb3Tq
  51. zakim-robot
    14:24
    [dylanb, a11y] that should help with your frustration (Guinness)
  52. zakim-robot
    14:25
    [dylanb, a11y] isn't it almost Guinness time in the UK anyway?
  53. zakim-robot
    14:25
    [heydon, a11y] I’m actually quite a big guinness drinker! Not draft though; the old recipe. I call it “old man Guinness”.
  54. zakim-robot
    14:25
    [callumacrae, a11y] it's guinness time in 35 minutes
  55. zakim-robot
    14:26
    [callumacrae, a11y] at least, it is in my office
  56. zakim-robot
    14:26
    [dylanb, a11y] well, now I know why you are into accessibility...
  57. zakim-robot
    14:26
    [dylanb, a11y] ...its about the POUR
  58. zakim-robot
    14:26
    [heydon, a11y] giphy: http://giphy.com/gifs/heart-happy-valentines-day-nichkhun-cuUVK6p5YrGbC
  59. zakim-robot
    14:26
    [callumacrae, a11y] blind drunk?
  60. zakim-robot
    14:26
    [heydon, a11y] giphy: http://giphy.com/gifs/logan-vmas-2014-nevermind-OlYEEbAADyn16
  61. zakim-robot
    14:27
    [callumacrae, a11y] can anyone who isn't on slack actually see the gifs?
  62. zakim-robot
    14:27
    [heydon, a11y] Wow, this random giphy feature is ludicrous.
  63. zakim-robot
    14:27
    [dylanb, a11y] thanks the Slack masters for the /collapse command
  64. zakim-robot
    14:27
    [callumacrae, a11y] we have hubot on our work slack network, it's a mess
  65. zakim-robot
    14:27
    [callumacrae, a11y] pugbomb!
  66. rodneyrehm
    14:29
    having only flown past the focus thing @dylanb and @LjWatson just talked about: there is a thing called “sequential focus navigation starting point” that acts as a marker within the document’s sequential navigation order in case no element has focus. This is why Firefox properly focuses the next focusable element after that heading- IE has a similar concept, no other browser knows this (yet). Making headings (any link target) focusable “solves” this problem everywhere.
  67. dylanb
    14:30
    @rodneyrehm I love Firefox's focus management - best of breed
  68. zakim-robot
    14:50
    [dylanb, a11y] @heydon: http://www.guinness.com/en-us/thebeer-es.html
  69. zakim-robot
    14:51
    [dylanb, a11y] is that the one?
  70. zakim-robot
    14:52
    [dylanb, a11y] What is this new fangled hogswash http://www.guinness.com/en-us/guinness-nitro-ipa.html
  71. zakim-robot
    14:53
    [heydon, a11y] @dylanb: Yeah, that’s the one. Much richer / hoppier and doesn’t go flat in seconds. Better all round, really.
  72. zakim-robot
    14:53
    [heydon, a11y] Not sure wtf the other hipsterbrew thing is all about
  73. zakim-robot
    15:24
    [Carolyn MacLeod, a11y] @rodneyrehm: Do you know if the “sequential focus navigation starting point” is used for Firefox's "caret browsing"? Or is it only used for AT?
  74. rodneyrehm
    15:25
    it even follows clicks
  75. rodneyrehm
    15:25
    click between two input elements (so that nothing gets focus, in which case the body will have focus), hit tab, see the second ipnut received focus.
  76. zakim-robot
    15:26
    [Carolyn MacLeod, a11y] Useful - thanks.
  77. zakim-robot
    15:27
    [Carolyn MacLeod, a11y] When I commented on FF bug 670928, I wondered if "navigating" between focusable elements and non-focusable elements would play well. It seems that it might...
  78. zakim-robot
    15:28
    [Carolyn MacLeod, a11y] ...so there's hope. :simple_smile:
  79. rodneyrehm
    15:34
    https://bugzilla.mozilla.org/show_bug.cgi?id=670928#c59 for reference
  80. zakim-robot
    15:42
    [Carolyn MacLeod, a11y] Yep, that's the one - thanks.
  81. zakim-robot
    15:53
    [Brian Kardell, a11y] @heydon: do you feel like above comments are related to this, which has always/continues to annoy me: If you navigate to a hash on the page from a TOC at the top, say in the HTML5 Single Page Edition and then hit tab, your focus moves back up 100 visual 'pages' back to the TOC, instead of to the next focusable thing after the heading?
  82. stevefaulkner
    20:32

    A11ySlackers log 1st October 2015 http://w3c.github.io/a11ySlackers/archives/2015/09/2015-10-01.html

  83. zakim-robot
    21:21
    [Jesse Beach, a11y] Does anyone have a good way to deal with asynchronous errors?
  84. zakim-robot
    21:21
    [Jesse Beach, a11y] Like I post a comment, move onto another element on the page, but then the post fails
  85. zakim-robot
    21:22
    [Jesse Beach, a11y] What's the best non-visual way to notify a user of the error?
  86. zakim-robot
    21:22
    [Jesse Beach, a11y] Put the error message in a div with role="alert"?
  87. zakim-robot
    21:27
    [Marcy Sutton, a11y] that’s what I’d do!
  88. zakim-robot
    22:31
    [dylanb, a11y] @jessebeach: the problem with async errors is you need to be able to associate the error with the field, so you need to do more than just announce, you need to also associate the error message with the field using one of the name association techniques AND you should clearly announce the label of the field when the error occurs so the association is unambiguous....
  89. zakim-robot
    22:32
    [dylanb, a11y] the problem is that when you have lots of fields and lots of them have errors, making announcements in async can be very difficult to understand when traversing a form
  90. zakim-robot
    22:32
    [Marcy Sutton, a11y] ooh great tips @dylanb
  91. zakim-robot
    22:32
    [dylanb, a11y] yeah this is more of a usability problem than accessibility per se
  92. zakim-robot
    22:33
    [dylanb, a11y] the technique to use is going to depend very much on the actual form
  93. zakim-robot
    22:34
    [dylanb, a11y] IMHO - it is better to avoid async (dynamic) validation if you can help it
  94. zakim-robot
    23:10
    [Jesse Beach, a11y] @dylanb, sure, I get trying to avoid, but most apps are not going to block the UI waiting on a request response.
  95. zakim-robot
    23:11
    [Jesse Beach, a11y] I wonder how we might extend ARIA to address tis
  96. zakim-robot
    23:11
    [Jesse Beach, a11y] this
  97. zakim-robot
    23:14
    [Jesse Beach, a11y] I don't know of key combos in screen readers that navigate by invalid form items
  98. zakim-robot
    23:18
    [dylanb, a11y] @jessebeach: I am not suggesting waiting necessarily...can you paint the scenario? This might help come up with a good solution.
  99. zakim-robot
    23:23
    [Jesse Beach, a11y] @dylanb: surely, the situation is, you toggle a switch to turn a feature off in a settings form. There is no "Save" button; the toggle is the chane. The UI updates immediately; we assume it will succeed and in most cases, it does.
  100. zakim-robot
    23:23
    [Jesse Beach, a11y] In the cases where we get a failure back from the server...or no response, we need to update the UI to reflect the reality of the model.
  101. zakim-robot
    23:24
    [Jesse Beach, a11y] These kinds of optimistic UI updates are very common
  102. zakim-robot
    23:24
    [Jesse Beach, a11y] and what I don't think we can do is pull focus around the page as requests from the server come back
  103. zakim-robot
    23:26
    [Jesse Beach, a11y] @dylanb: the more I think about it, the more I support the idea that this is a larger environment problem
  104. zakim-robot
    23:27
    [Jesse Beach, a11y] We might need to go back to specs and ATs
  105. zakim-robot
    23:28
    [Jesse Beach, a11y] What I told the dev who asked me about this, is, it's better to bring focus to the problem, rather than fail silently
  106. zakim-robot
    23:28
    [Jesse Beach, a11y] so we focus the element with the failure message
  107. zakim-robot
    23:29
    [Jesse Beach, a11y] If they change 3 things quickly and they all fail, well, drat, it's going to be messy
  108. zakim-robot
    23:29
    [Jesse Beach, a11y] but it'll always be failure than a visual-only failure message
  109. zakim-robot
    23:42
    [Michael Lockrey, a11y] So Facebook look like they're coming out with a video profile picture soon
  110. zakim-robot
    23:42
    [Michael Lockrey, a11y] Here's the first one I've seen
  111. zakim-robot
    23:42
    [Michael Lockrey, a11y] http://rackspace.us10.list-manage.com/track/click?u=20faa7ae8ad8bb97cd0048096&id=3242a3e68d&e=63b8c9f565
  112. zakim-robot
    23:43
    [Michael Lockrey, a11y] How does FB get away with not adding an accessibility layer here?
  113. zakim-robot
    23:43
    [Michael Lockrey, a11y] Bring Deaf I'm not going to be able to access any audio / dialogue
  114. zakim-robot
    23:44
    [Michael Lockrey, a11y] Wouldn't it be easy to require users to put in the text equivalent and automatically generate the accessibility?
  115. zakim-robot
    23:45
    [Cordelia McGee-Tubb, a11y] I hope that also comes with the ability to turn off animations.
  116. zakim-robot
    23:45
    [Michael Lockrey, a11y] Isn't this the same "core" issue we've had with alt text and images for years and years
  117. zakim-robot
    23:46
    [Michael Lockrey, a11y] That's the main profile pic
  118. zakim-robot
    23:46
    [Michael Lockrey, a11y] You look at that to learn more about the person
  119. zakim-robot
    23:48
    [Cordelia McGee-Tubb, a11y] I’m curious, are there any good social networking / social sharing platforms that prompt users for alternative text? I’ve seen it when uploading images to blogging platforms like WordPress, but haven’t seen a prompt on Facebook, Twitter, Instagram, etc. and don’t remember there being one on Flickr. I agree, seems like something every platform should have if they allow users to add non-text content.
  120. garcialo
    23:49
    There aren't any that do.
  121. zakim-robot
    23:49
    [Cordelia McGee-Tubb, a11y] I’m also very concerned about “seven-second videos … looping when another user views your profile.” Hope there’s a way to disable that.
  122. garcialo
    23:49
    yeah; that will be very distracting
  123. garcialo
    23:52
    As it is, the autoplay of videos drives me up the wall.
  124. garcialo
    23:53
    ...no pun intended
  125. zakim-robot
    23:54
    [Michael Lockrey, a11y] There's meme generators galore!
  126. zakim-robot
    23:54
    [dylanb, a11y] @jessebeach: I think your approach is the right one. Rather pull the user's attention back to the failed item (first failed item) and then let them find out about the other failures by moving back through the UI
  127. zakim-robot
    23:56
    [dylanb, a11y] an expansion of AT capabilities and ARIA to specifically address error conditions would be a great idea. It is currently not possible to semantically determine which part of a form field label is the error message at the moment
  128. zakim-robot
    23:56
    [dylanb, a11y] and that is a bug problem IMHO
  129. zakim-robot
    23:56
    [dylanb, a11y] *big