Archive index

A11y Slackers Gitter Channel Archive 24th of August 2015

What fresh hell is THIS now? - Patrick Lauke
  1. zakim-robot
    03:52
    [jitendra, a11y] I was not aware of it that text justification can affect the accessibility
  2. zakim-robot
    03:52
    [jitendra, a11y] thanks @stevef for the link
  3. zakim-robot
    10:09
    [Matt Hinchliffe, a11y] I've just looked at some code that had the sites logo marked up as a heading containing a link and using CSS text replacement to display the logo image. I've recommended that this is change to a link containing an image on the basis that the top level heading should be reserved for the main content piece and the document title is fine for orientating a user. Would there be anything else worth adding? Would adding the banner landmark role be useful?
  4. StommePoes
    10:12
    The cases where I've done this (using CSS) is when I have a sprite. Are these guys using a sprite?
  5. StommePoes
    10:13
    banner is prolly better for whole-header bits: is there more than just a logo? what's every page got in the header?
  6. StommePoes
    10:14
    (also I've had the home page use a heading-heading (h1) for the logo because CMS users never add h1's to home pages over here. all inner pages just have a p with links etc and the h1 is properly somewhere in teh <main> part of the page)
  7. LjWatson
    10:15
    @Matt if there is other info as well as the logo, it might be worth wrapping it all in the <header> element (which will give you the banner role for free).
  8. LjWatson
    10:15
    FWIW I agree wholeheartedly that wrapping the logo in a heading is not helpful (speaking as a screen reader user here as much as anything).
  9. StommePoes
    10:19
    One way to get alt text with an image when you're using a sprite is to use a transparent image (can have alt) and the sprite part as a background. The problem with that technique though is that if the sprite is 404 for whatever reason but transparent.png isn't, alt text won't show visible. Then again, in a lot of browsers it won't show anyway if it's a small image <frown>
  10. LjWatson
    10:20
  11. zakim-robot
    10:23
    [Matt Hinchliffe, a11y] Thanks all
  12. zakim-robot
    10:25
    [Matt Hinchliffe, a11y] @StommePoes I've also done the same with homepages in the past where there is no clear H1
  13. StommePoes
    10:28
    My god and my religion forbid pages introducing a webshop with scattered h2's and h3's but no h1 :)
  14. StommePoes
    10:28
    That was the only sane solution I could find.
  15. MichielBijl
    11:53
    I often add a hidden h1
  16. MichielBijl
    11:53
    Fill it with 'frontpage' or 'articles' or whatnot
  17. zakim-robot
    12:29
    [Matt Hinchliffe, a11y] That sounds reasonable too
  18. jonathantneal
    12:39
    Do ATs do something special with the "hidden" attribute, or do they only care about its current style?
  19. MichielBijl
    12:43
    hidden is equal to display: none; :)
  20. rodneyrehm
    12:43
    (not in IE10)
  21. MichielBijl
    12:45
  22. MichielBijl
    12:45
    According to that it is supported in IE11
  23. rodneyrehm
    12:46
    yes, beginning IE11
  24. rodneyrehm
    12:46
    but making it work in older browsers is dead simple:
    *[hidden] { display: none }
  25. jonathantneal
    12:46
    ^ asterisk not necessary
  26. rodneyrehm
    12:47
    the only thing you’re not getting this way, is the simple boolean property on Element
  27. rodneyrehm
    12:48
    yeah, the * is not necessary, it’s just there to explicitly say “applies to every element"
  28. rodneyrehm
    12:49
    since hidden is a boolean attribute, it cannot contain any content - so [hidden~="screen”] does not make much sense
  29. rodneyrehm
    12:49
    (unless the author knows something I don’t…)
  30. rodneyrehm
    12:51
    the second code example may benefit from the unset value in the .visuallyhidden:focus {} block - https://developer.mozilla.org/en-US/docs/Web/CSS/unset
  31. jonathantneal
    12:51
    I can file an issue with Sanitize, then. What is the (or is there an) attribute or attribute+value that would best markup what both of those projects are describing?
  32. rodneyrehm
    12:52
    I think I would replace “.visuallyhidden” by aria-hidden=“true”
  33. MichielBijl
    12:52
    visually hidden ≠ aria-hidden=true
  34. rodneyrehm
    12:53
    ah, no, never mind, that’s the exact opposite of you wanted to achieve… :D
  35. MichielBijl
    12:53
    :p
  36. rodneyrehm
    12:53
    maybe I shouldn’t be doing three things at once
  37. jonathantneal
    12:54
    Precisely. So, what is the appropriate markup? Or are there none, and hidden="screen" is just a bad hack?
  38. rodneyrehm
    12:54
    if you were adamant on using the HTML5 hidden attribute as specified (even with element.hidden = true), then have a look at http://www.smashingmagazine.com/2014/11/28/complete-polyfill-html5-details-element/ to find a neat trick to polyfill boolean attributes/properties
  39. rodneyrehm
    12:55
    "bad hack” is a nice term for “not specification compliant what so ever"
  40. jonathantneal
    12:55
    Really, the later seems so much kinder.
  41. rodneyrehm
    12:56
    I agree, until you want to hide from multiple sources
  42. rodneyrehm
    12:56
    -source +whateverWordIWasLookingFor
  43. rodneyrehm
    12:57
    I’d probably suggest a second attribute: invisible
  44. jonathantneal
    12:57
    [hidden] => hidden from screen and AT, [aria-hidden="true"] => hidden from AT, [?] => hidden from screen ...
  45. rodneyrehm
    12:57
    instead of trying to overload the hidden attribute
  46. jonathantneal
    12:57
    ^ @MichielBijl any thoughts?
  47. rodneyrehm
    12:58
    so “hidden” would continue to mean “in DOM but not in any other tree”, “invisible” would mean “in DOM and AT, but not render tree"
  48. jonathantneal
    13:02
    As in [aria-hidden="invisible"]? Does aria-hidden support such a value?
  49. rodneyrehm
    13:02
    no
  50. rodneyrehm
    13:08
    http://discourse.wicg.io/t/a-way-to-hide-text-visually-but-not-from-screen-readers/510/4 has some ideas about using media queries, @jonathantneal
  51. MichielBijl
    13:13
  52. MichielBijl
    13:17
    As far as I know, the best way to visually hide, is still through clip: ; / position: absolute;
  53. zakim-robot
    13:20
    [Karl Groves, a11y] +1
  54. jonathantneal
    13:23
    Would anyone (available and willing) visit this page with a screen reader and report back what was read, as well as the browser+version and reader+version they used? http://sandbox.thewikies.com/aria-tests/aria-hidden.html
  55. garcialo
    13:27
    output from NVDA used with Firefox
  56. garcialo
    13:27
    ARIA Hidden Attribute Tests
    heading level 1
    ARIA Hidden Attribute Tests
    ARIA hidden with no value.
    ARIA hidden with a value of false.
  57. jonathantneal
    13:28
    Thank you, @garcialo!
  58. garcialo
    13:28
    np
  59. jonathantneal
    13:28
    Which version of NVDA and Firefox did you use?
  60. garcialo
    13:29
    NVDA 2015.2 - FF 40.0.2
  61. garcialo
    13:29
    should be latest of both
  62. jonathantneal
    13:33
    In VoiceOver, the nonsense value was read aloud. That’s the first difference I’ve noticed.
  63. garcialo
    13:39
    My VoiceOver reads each line
  64. powrsurg
    13:49
    how many people here actually have/test in Jaws?
  65. StommePoes
    13:50
    I did until recently, with the 40 min demo and restarting the computer :P
  66. jonathantneal
    13:50
    @garcialo your voiceover read every line in FF?
  67. jonathantneal
    13:50
    I’m installing the trial of JAWS on Windows 10 to test with Edge.
  68. rodneyrehm
    13:50
    jaws time-limit-demo not testing anthing unless I have a specific question
  69. rodneyrehm
    13:51
    apparently Edge does not yet have any noteworthy accessibility integration, @jonathantneal
  70. StommePoes
    13:51
    rodney but edge improves constantly so likely changes will be seen within the next several months
  71. rodneyrehm
    13:52
    yes, that is expected
  72. rodneyrehm
    13:52
    … just saying that right now testing things in Edge may not yield any meaningful results
  73. StommePoes
    13:53
    yeah ok
  74. powrsurg
    13:53
    for giggles I tested Narrator in Edge. It functioned as you would expect
  75. garcialo
    13:57
    @jonathantneal Yes, FF 40.0 with Voiceover 7.0 I believe
  76. MichielBijl
    13:58
    @jonathantneal Safari 8 with VO skips the aria-hidden=true line
  77. MichielBijl
    13:59
    VO has no official support for FF or Chrome
  78. MichielBijl
    13:59
    Or the other way around; I forget
  79. garcialo
    13:59
    I would expect it goes both ways. =p
  80. garcialo
    14:00
    But yeah, I should have checked with Safari; I just instinctively use FF for screen reader testing since I hardly ever use VoiceOver
  81. jonathantneal
    14:00
    JAWS + IE11 returned nearly the same result as VoiceOver+Chrome. JAWS did not work with Edge.
  82. jonathantneal
    14:01
    @powrsurg could you write out what was said with Narrator + Edge?
  83. jonathantneal
    14:02
    I couldn’t get Narrator to read Edge. It would just put a blue box around all of the contents of the page.
  84. garcialo
    14:02
    yeah Edge and Narrator aren't there yet
  85. garcialo
    14:03
    Edge team is working on it
  86. garcialo
    14:03
    well, on the Edge part
  87. LjWatson
    14:07
    @rodneyrehm @jonathantneal unfortunately the Edge accessibility problem is likely to be challenging to solve - don't expect a solution anytime soon.
  88. rodneyrehm
    14:07
    @LjWatson I don’t even know what I’m supposed to respond to that…
  89. garcialo
    14:08
    @LjWatson What's the big issue with it?
  90. LjWatson
    14:09
    @rodneyrehm there isn't much you/anyone can say sadly :(
  91. LjWatson
    14:09
    The problem is that Edge doesn't support MSAA, which was the primary accessibility API used by Windows screen readers in IE. It still has UIAutomation support, but UIA is apparently much less robust/feature rich than MSAA.
  92. LjWatson
    14:10
    The whole thing is compounded by the fact Edge doesn't permit third party/external access to the DOM, so the workaround used in IE to overcome the problems with both MSAA and UIA has also been removed.
  93. garcialo
    14:10
    ouch
  94. rodneyrehm
    14:11
    ah, MSAA is the old API, and UIA the new one. but UIA has been around for a while. or something like that
  95. LjWatson
    14:11
    So one way or another, it's going to take some clever thinking to solve everything. Fortunately the Edge team at MS are a smart lot, so I'm hopeful a solution will be possible - just not anytime soon I suspect.
  96. jonathantneal
    14:11
    For those who have shared, here are the results thus far. http://sandbox.thewikies.com/aria-tests/aria-hidden.results.html
  97. jonathantneal
    14:13
    @MichielBijl, would you be able to share exactly what was read aloud in VO + Safari? I couldn’t get VoiceOver to work with Safari myself. It wanted me to use the arrow keys to go through each element, and all of them were read aloud in that case, even aria-hidden="true".
  98. MichielBijl
    14:20
    @jonathantneal did you use the modifier + arrow keys?
  99. MichielBijl
    14:22
    It just speaks the lines, except for the one with aria-hidden
  100. jonathantneal
    14:22
    “You are currently on HTML content. To enter the web area, press Control+Option+Shift+Down arrow.” If I do that, then I can have it read each line of text aloud. This includes the “aria hidden with a value of true” line.
  101. MichielBijl
    14:23
    I'm on OS X 10.10.4 (14E46)
  102. MichielBijl
    14:24
    VO is tied to OS X version, so maybe you're on 10.9 or lower?
  103. jonathantneal
    14:24
    I’m actually in Safari 9 + El Capitan.
  104. jonathantneal
    14:25
    Is there a way to toggle how it’s reading Safari content? I can’t get it to read the page without pressing the down and up arrow keys to move between the lines of text.
  105. MichielBijl
    14:26
    Hmm, if you only use arrow keys, it does read it
  106. MichielBijl
    14:26
    If you use modifier keys + arrow keys to navigate it does not
  107. MichielBijl
    14:26
    That might be a bug
  108. jonathantneal
    14:26
    I can’t get it to just read it to me. I refresh the page. It just says to use Control+Option+Shift+Down arrow to enter the content, as I said before.
  109. jonathantneal
    14:26
    What are the modifier keys I can use to navigate the page, @MichielBijl ?
  110. MichielBijl
    14:27
    control+option by default
  111. MichielBijl
    14:27
    so control+option+right arrow for example
  112. jonathantneal
    14:31
    Thanks @MichielBijl, that worked.
  113. jonathantneal
    14:33
    Chrome doesn’t support that style of navigation. Then, as you mentioned, Firefox reads them all aloud (including aria-hidden="true") but Safari ignores that line.
  114. powrsurg
    14:34
    @jonathantneal I'm not at a desktop that has Edge at the moment, unfortunately
  115. jonathantneal
    14:34
    @powrsurg there seems to be no way to use an AT with Edge at this time. No worries.
  116. MichielBijl
    14:40
    No problem @jonathantneal. That is my preferred way of navigating in Safari, not sure if everyone does it with the VO modifier keys.
  117. jonathantneal
    14:50
    It seems like the only way to navigate in Safari, so I’m glad I could test it.
  118. zakim-robot
    17:32
    [dylanb, a11y] aXe Firefox extension now approved https://addons.mozilla.org/en-US/firefox/addon/axe-devtools/
  119. zakim-robot
    17:33
    [dylanb, a11y] remove the old one because the name and URL changed
  120. powrsurg
    18:36
    does anyone know a service that can be used to create audio transcripts for audio that is obtained via getUserMedia?
  121. jonathantneal
    23:58
    Thanks again for your help today. I was able to test 10 different scenarios tonight. VoiceOver with Safari, Chrome, and Firefox, JAWS with Internet Explorer, Chrome, and Firefox, NVDA for Internet Explorer, Chrome, and Firefox, and ChromeVox with Chrome.