Archive index

A11y Slackers Gitter Channel Archive 17th of August 2016

What fresh hell is THIS now? - Patrick Lauke
  1. zakim-robot
    @zakim-robot
    Aug 17 06:33
    [caesar] Just noticed something odd. The Understanding WCAG 2.0 SC 2.4.7 page contains the following sentence: "If there is only one keyboard actionable control on the screen, the success criterion would be met because the visual design presents only one keyboard actionable item."
  2. luis garcia
    @garcialo
    Aug 17 06:34
    how is that odd?
  3. zakim-robot
    @zakim-robot
    Aug 17 06:34
    [caesar] Are they saying that if a web page contains one, and only one, button, then it wouldn't need to show visible focus? What about differentiating the web page element from the application interface?
  4. luis garcia
    @garcialo
    Aug 17 06:35
    I don't believe developers can modify focus styles for the application
  5. zakim-robot
    @zakim-robot
    Aug 17 06:36
    [caesar] Sure. So the SC would be met purely because you can tell when the focus is on the button because it is NOT on any of the browser application UI elements?
  6. luis garcia
    @garcialo
    Aug 17 06:37
    yeah, I guess technically
  7. because once your focus is in the viewport, there is only possible thing that can have focus
  8. there is nothing else to differentiate it from
  9. zakim-robot
    @zakim-robot
    Aug 17 06:37
    [caesar] Wow, OK. I would not have guessed that.
  10. luis garcia
    @garcialo
    Aug 17 06:38
    I agree it's a bit odd, but there's lots of little technicalities
  11. like if something is just horrible for everyone, it's not technically an accessibility issue
  12. it's only an accessibility issue when a barrier is created because of a disability
  13. zakim-robot
    @zakim-robot
    Aug 17 06:42
    [caesar] Yeah. I know the WCAG WG takes a very hardline stance between usability and accessibility. Another surprise I encountered previously was that link focus states didn't have to meet contrast, so long as their base state did...
  14. luis garcia
    @garcialo
    Aug 17 06:43
    mmm...I don't remember that exception
  15. I'd have to look it up, but I thought those also needed to meet the minimums
  16. zakim-robot
    @zakim-robot
    Aug 17 06:58
    [caesar] Contrast of Hover and Link Text States
  17. Mallory
    @StommePoes
    Aug 17 08:00
    it's why some have made a WUHCAG
  18. Fiona Holder
    @FionaHolder
    Aug 17 08:17
    I'm developing a testing tool and honestly trying to decipher 1.1 Non text content was really tricky and I'm sure there are nuances I'm getting wrong
  19. I think that's the most complex criterion of the lot though
  20. zakim-robot
    @zakim-robot
    Aug 17 11:01
    [michiel] It's kind of hard for machines to decide whether something is decoration or content.
  21. [michiel] Or if alt="Steve's toilet" is indeed a correct description of the image.
  22. Fiona Holder
    @FionaHolder
    Aug 17 12:30
    It is, and I'm 100% fine with the WCAG being aimed at human testers because machine testing just isn't possible for a lot, but some kind of logical structure or flow chart to the decisions you have to make would go a long way!
  23. 1.1 is very much "you should do this", oh wait but not if X, Y, Z, and actually if it's Z, X is invalid anyway and you should also consider all this, oh and captchas
  24. Ironically, the other criteria are much better scoped and defined but developers start at 1.1 and start muttering about accessibility being impossible
  25. Fiona Holder
    @FionaHolder
    Aug 17 12:36
    (That came across quite ranty, but the general sentiment is "ugh, non text content is hard to explain", not trying to criticise those writing the WCAG!)
  26. zakim-robot
    @zakim-robot
    Aug 17 12:41
    [michiel] FionaHolder: look no further than the official WAI alt Decision Tree of Money and Wonder!
  27. [michiel] http://www.w3.org/WAI/tutorials/images/decision-tree/
  28. [michiel] Well, maybe not money and wonder…
  29. Fiona Holder
    @FionaHolder
    Aug 17 12:44
    How have I never come across this tutorials section before?! Thanks :)
  30. This part of the decision tree is the bit I was struggling with I guess, haha
    "This decision tree does not cover all cases. For detailed information on the provision of text alternatives refer to the Image Concepts Page"
  31. zakim-robot
    @zakim-robot
    Aug 17 13:15
    [alice] Good morning! I have a design patterns question
  32. LJWatson @LJWatson waves at Alice
  33. zakim-robot
    @zakim-robot
    Aug 17 13:19
    [alice] @ljwatson: you are the perfect person, hello! <3
  34. [alice] It's about <dialog> vs role=dialog
  35. Léonie Watson
    @LJWatson
    Aug 17 13:20
    Ha! That's not something I hear too often :) I'll help if I can though...
  36. zakim-robot
    @zakim-robot
    Aug 17 13:20
    [alice] <dialog> allows focus to escape into the browser chrome; the design pattern advice for role=dialog suggests wrapping focus immediately back to the top of the dialog
  37. [alice] why are these different, and is one pattern preferable?
  38. Léonie Watson
    @LJWatson
    Aug 17 13:32
    Hmm. Good question. I suspect the two things were written at different times by different people.
  39. Worth mentioning that <dialog> is at risk in HTML5.1 anyway.
  40. zakim-robot
    @zakim-robot
    Aug 17 13:34
    [alice] :(
  41. [alice] What are the odds that we can get inert in in time to help?
  42. Léonie Watson
    @LJWatson
    Aug 17 13:41
    I don't have Chrome installed on this machine yet, so cant run the tests. You can though http://w3c-test.org/html/semantics/interactive-elements/the-dialog-element/
  43. Worth checking because Chrome may have implemented it - we just need at least two implementations to take it off the at risk list.
  44. Ah. Word from someone at W3C is that Chrome is the only implementation - so we'd need another.
  45. We'd need Firefox/Gecko, Safari/Webkit or Edge/EdgeHTML to implement it - or at least be on public record as being committed to implementing it.
  46. With that done, it would be easy enough to pull it back into 5.2 (we've just done something similar for details/summary).
  47. Then it would be possible to look at cleaning up the definition with regard to your point ^^
  48. This is the closest info we have on another implementation I think https://bugzilla.mozilla.org/show_bug.cgi?id=840640
  49. Peter Krautzberger
    @pkra
    Aug 17 13:47

    Hi slackers. A quick question. Imagine from an article you generate several lists of labeled things (basically: lists of types of article fragments such quotations etc). From my initial research it seems to me that definition lists fit -- does it?

    (IIUC, AT support for DLs is not ideal and perhaps li+section is better here anyway. Any other thoughts would be very helpful.)

  50. I realize I might not be providing sufficient information. Happy to write more.
  51. zakim-robot
    @zakim-robot
    Aug 17 13:49
    [michiel] You mean an article index?
  52. Fiona Holder
    @FionaHolder
    Aug 17 13:50
    In my mind a DL is for the literal definition of a term, not a sort of "item with a label" type thing, if that's what you mean?
  53. Léonie Watson
    @LJWatson
    Aug 17 13:50
    Yes, a dl would be ok for this.
  54. zakim-robot
    @zakim-robot
    Aug 17 13:50
    [michiel] FionaHolder: DL is now a description list rather than definition list.
  55. [michiel] http://w3c.github.io/html/grouping-content.html#the-dl-element
  56. Fiona Holder
    @FionaHolder
    Aug 17 13:52
    Ah, thanks for the update, I can't say I've used one in years!
  57. Léonie Watson
    @LJWatson
    Aug 17 13:52
    From the HTML5.1 spec...
  58. "Term-description groups may be names and definitions, questions and answers, categories and topics, or any other groups of term-description pairs."
  59. https://www.w3.org/TR/html51/grouping-content.html#the-dl-element
  60. zakim-robot
    @zakim-robot
    Aug 17 14:14
    [karlgroves] @alice: are you still around?
  61. [alice] @karlgroves: yo
  62. [karlgroves] Question for you. I noticed something with a11y properties in Chrome devtools. It gives you a node’s text even if the node in display:none. I was wondering if you guys would be willing to consider a feature request to not do that - or to add some indication that the content is hidden?
  63. zakim-robot
    @zakim-robot
    Aug 17 14:19
    [alice] The extension or the experiment?
  64. [alice] Can you post a screenshot
  65. [alice] ?
  66. [karlgroves] yup. BRB
  67. [alice] I'll be a little unresponsive as I'm at a thing
  68. [karlgroves] Styles panel shows display none. A11y Props panel shows the innerText
  69. [karlgroves] Screen Shot 2016-08-17 at 10.21.36 AM.png
  70. zakim-robot
    @zakim-robot
    Aug 17 14:24
    [alice] That's the extension
  71. [karlgroves] Yeah
  72. Peter Krautzberger
    @pkra
    Aug 17 14:32
    Yikes. I get a call and your kind folks write tons of helpful comments -- thank you!
  73. (you kind folks)
  74. thanks, michiel, Leonie, Fiona!
  75. Léonie Watson
    @LJWatson
    Aug 17 14:34
    @pkra NP :)
  76. Peter Krautzberger
    @pkra
    Aug 17 14:34
    @LJWatson :sparkles:
  77. zakim-robot
    @zakim-robot
    Aug 17 14:39
    [michiel] thumbsup emoji
  78. Peter Krautzberger
    @pkra
    Aug 17 14:49
    ah, sorry michiel -- :-) just for you!
  79. Oh. Gitter's web client converts : - ) into :grinning:
  80. michiel: consider yourself smiled at, gratefully so even.
  81. zakim-robot
    @zakim-robot
    Aug 17 14:50
    [michiel] I'm on IRC :P
  82. [michiel] But thanks :D
  83. Peter Krautzberger
    @pkra
    Aug 17 15:03
    michiel: I know! : - )
  84. Job van Achterberg
    @jkva
    Aug 17 15:05
    : - P
  85. zakim-robot
    @zakim-robot
    Aug 17 15:06
    [alice] @karlgroves sorry for disappearing :)
  86. [karlgroves] np
  87. [alice] So the experiment does do what you want
  88. [alice] and I should probably retire the text computation features of the experiment
  89. powrsurg
    @powrsurg
    Aug 17 15:56
    We just had a discussion here at work about getting more consistent with the way we refer to people in our system. One of the concerns was that calling someone a "disabled user" (meaning an account for them exists, but their status has been turned off) implies that they are a user that has a handicap. Does this seem like something that comes up often? We don't have any means of identifying such
  90. Job van Achterberg
    @jkva
    Aug 17 15:58
    "disabled account" would fix that
  91. zakim-robot
    @zakim-robot
    Aug 17 15:59
    [marcysutton] here's some info on enabling Alice's awesome experiment (which I hope to see enabled for all) http://bit.ly/chrome-a11y
  92. powrsurg
    @powrsurg
    Aug 17 15:59
    well, we simply say "Disabled" in those places
  93. Fiona Holder
    @FionaHolder
    Aug 17 16:06
    Was thinking "Inactive", but that's not exactly the same.... hmm
  94. zakim-robot
    @zakim-robot
    Aug 17 16:31
    [oliviernourry] Hi all, I have a question regarding HTML code and vocalization by screenreaders
  95. [michiel] Shoot
  96. [oliviernourry] I would like to write stuff like "level AA" and have it pronouced as "level double-A"
  97. [oliviernourry] I've tried simply using aria-label="double-A" on a span containing "AA"; but it appears that NVDA, notably, ignores the aria-label when there's content. Which somehow makes sense
  98. [oliviernourry] So, digging into FF and NVDA forums I came up with this: <span aria-label="double-A"><span aria-hidden="true">AA</span></span>
  99. [oliviernourry] Which works fine with NVDA, Jaws... but not with VoiceOver, which ignores the whole (says nothing)
  100. [oliviernourry] More regular things like <abbr title="double-A"> don't work everywhere either
  101. [karlgroves] @oliviernourry: @ljwatson says that (I’m simplifying) “Stop wanting that”. Her argument - unless I’m misinterpreting - is that forcing the content to read well for screen readers isn’t a fruitful pursuit, mostly because of what you’ve just described.
  102. [michiel] aria-label is only allowed on something with an explicit role; so VoiceOver is actually correct.
  103. [michiel] I'm with Karl and Léonie. No need to dictate it anyway.
  104. [karlgroves] Hammering out special cases like that always becomes a PITA for little return because IMO, the AT user can sort it out on their own, if needed.
  105. zakim-robot
    @zakim-robot
    Aug 17 16:36
    [oliviernourry] @karlgroves: sure thing, but a friend of mine (who's also a friend of Leonie's, BTW!) said she was very pleased with the improvement, comapred to just hearing variations of "aaaah"
  106. [oliviernourry] ;)

  107. [karlgroves] I always like using the example of a field label with a description:

    “Must be xx/xx/xxxx format” - always a good time with VoiceOver

  108. [oliviernourry] lol
  109. Fiona Holder
    @FionaHolder
    Aug 17 16:38
    I would have assumed that the <abbr title="double-A"> option would be the "correct" way to achieve it? Whether screen readers support is another matter though.
  110. zakim-robot
    @zakim-robot
    Aug 17 16:40
    [karlgroves] That’s probably the best, semantically.
  111. [oliviernourry] Well I was hoping there was something clean to deal with such things. I usually don't bother too much about that, for the same reasons you mention. But here we're talking about a legal documentation (RGAA, the French WCAG transposition) that comprises hundreds of occurrences, and that's pretty uncomfortable when you need to know which level it is actually (although I understand there are ways to spell this out with any SR)
  112. [oliviernourry] Thought about using aural properties of CSS3, but last time I checked, this wasn't working well either
  113. [karlgroves] Nope. :(
  114. [oliviernourry] abbr aren't vocalized by NVDA, I was told. But didn't dig more into this. I agree this is the closest to what should be done, if need be

  115. [alexlande] > aria-label is only allowed on something with an explicit role

    Whoa, really? I think I’ve probably been using it incorrectly, in that case :( The spec says “Used in Roles: All elements of the base markup”, which I interpreted as “any element, regardless of role”. Does it actually mean “any explicitly defined role”?

  116. [karlgroves] It should be applied to elements that can be labelled
  117. [karlgroves] In other words, <span aria-label=“foo”></span> won’t work but <span aria-label=“foo” role=“checkbox"></span> would
  118. zakim-robot
    @zakim-robot
    Aug 17 16:45
    [oliviernourry] yeah, I think that what NVDA and JAWS do is to consider this as a fallback measure when there's nothing else to read about
  119. [alexlande] I see. thanks, that makes sense
  120. [oliviernourry] that's why it works when you annihilate the content of the inner span with aria-hidden, although this is not what it is expected to do
  121. [oliviernourry] but htat's pure guessing
  122. [oliviernourry] ah well, too bad, but none is expected to do the impossible ;) thanks for your insights, people
  123. zakim-robot
    @zakim-robot
    Aug 17 17:08
    [michiel] I think, WebKit just landed localisable list types :O
  124. [michiel] Also, improved media player controls.
  125. [michiel] https://trac.webkit.org/changeset/203801
  126. zakim-robot
    @zakim-robot
    Aug 17 17:19
    [brianarn] I have a semantics question that is kinda eating at me, and then realized I could put it out here, so I’d love an opinion or two, knowing that (at least for now) I can’t change the overall UX in the way I’d really like, which would wind up removing all of the ambiguity. :)
  127. [brianarn] We have a Careers page, which had some <a href=“#” links that were being hijacked by JS to do some sort of fancy slide-in of content, so no actual navigation, and in auditing things, we decided that a button is clearly a better choice
  128. [brianarn] there was also a “Go back” link that was href=“#” that got taken over, and we made it a button too, since in both of these cases, it was executing some JS to change up page content
  129. [brianarn] but we also realized that at the in-between state, when content was showing, the route was being altered in a way that did make for a valid URL for that page.
  130. [brianarn] and both the “Show job” and “Back to careers” interactions were causing route changes and navigations, but doing so via JS, and not any actual linking
  131. [brianarn] so like, they really also do feel link links and not buttons
  132. [brianarn] Something about typing it out makes me think that perhaps we revert back to links, but use actual proper hash references instead of # for everything (though in this one rare case, # is arguably the correct “Back to Careers” type link).
  133. [brianarn] I’d rather see it such that each career was properly its own page of content and whatnot, and I think we might push that in the next iteration of the site, but for now, we’re having some struggle picking out the best semantics, curious to what y’all think.
  134. zakim-robot
    @zakim-robot
    Aug 17 17:27
    [michiel] Say careers is at rawr.eu/careers.html and Show job pulls in content but also changes the URL to rawr.eu/careers.html#become-a-dinosaur. Couldn't both links not simply references those URI's?
  135. [brianarn] that’s basically what it is, but neither is using the natural navigation elements of the link
  136. [brianarn] in both cases, due to decisions that can’t easily be undone for now, both links are being taken over by JS and manually managed
  137. [michiel] But couldn't you make it that way?
  138. [michiel] You can still hijack it, but there should be some sort of fallback right?
  139. [scottohara] so without JS navigation doesn’t work?
  140. [brianarn] There should and that is a higher level of conversation that is happening right now
  141. [brianarn] Yeah, right now without JS, nav doesn’t work (and we’re trying to undo that)
  142. [brianarn] well, I should rephrase - nav doesn’t even exist without JS right now
  143. [michiel] In that case I'd argue that <a href=\#> is fine. And focus on undoing the not having nav without JS :)
  144. [michiel] To clarify, I think it's not a high priority if you will change it anyway.
  145. [brianarn] I think long-term we’re changing it out
  146. [brianarn] like, gut the everything
  147. zakim-robot
    @zakim-robot
    Aug 17 17:32
    [brianarn] We just did a giant overhaul of most aspects, and cleaned out a lot of other href=“#” that was very much links-as-buttons in a terrible way, and things are a lot better in general now, but this one area is still rough because it wasn’t the focus of the recent redesign work
  148. [michiel] Well, marcysutton is the expert on all things Angular and webappy, so she might be able to tell you in more detail how to tackle this one :)
  149. [marcysutton] progressive enhancement is also really hard to do in Angular 1x :\
  150. zakim-robot
    @zakim-robot
    Aug 17 17:38
    [marcysutton] Ideally the links would have actual routing URLs in them and pages would load with and without JS
  151. [marcysutton] Where the JS version uses a router, but the URLs are also supported server-side
  152. zakim-robot
    @zakim-robot
    Aug 17 17:50
    [brianarn] Agreed
  153. [brianarn] Right now, our job list comes from a third-party API integration thing, but the site is static, hence the choice to render links via JS
  154. [brianarn] they’re “routable” URLs if you have JS on, and, um, do nothing without it, which is not ideal.
  155. [brianarn] thankfully we have a lot of support to improve a11y - like, a LOT now, something really turned a corner a few months ago and our designers are actively asking about differing UX based on input devices and it’s just all pretty awesome, but no-JS is the next thing we’re looking at, and finding a few sore spots.
  156. zakim-robot
    @zakim-robot
    Aug 17 20:55
    [karlgroves] Current status: Feeling Mallory’s frustration from a few days ago with tooltips
  157. [michiel] I read “Feeding” (joy/allthethings emoji)
  158. [karlgroves] I don’t think her frustration needed any feeding.
  159. [michiel] Knowing Mall, no, don't think so :P
  160. zakim-robot
    @zakim-robot
    Aug 17 21:18
    [michiel] Does anyone have an ARIA enabled accordion?
  161. [michiel] This one looks nice: https://frend.co/components/accordion/
  162. [michiel] Have to test it though.
  163. James Nurthen
    @jnurthen
    Aug 17 21:28
    @michiel I hate the role=tab accordions. Keyboard navigation is so unintuitive
  164. zakim-robot
    @zakim-robot
    Aug 17 21:32
    [dpogue] On the subject of abbr and VoiceOver that came up earlier... it looks like that was fixed in Webkit today: https://bugs.webkit.org/show_bug.cgi?id=160907
  165. [karlgroves] backs away from the role=tab debate
  166. James Nurthen
    @jnurthen
    Aug 17 21:35
    oh come on. You know you want to get involved.
  167. zakim-robot
    @zakim-robot
    Aug 17 21:36
    [karlgroves] I just want to make sure everyone’s moved on from longdesc first ;)
  168. James Nurthen
    @jnurthen
    Aug 17 21:37
    yeah we did that. We are talking about buttons vs links now.
  169. zakim-robot
    @zakim-robot
    Aug 17 21:37
    [karlgroves] as long as the accordions work in Lynx I’m OK
  170. James Nurthen
    @jnurthen
    Aug 17 21:38
    with JS and Styles sheets off?
  171. zakim-robot
    @zakim-robot
    Aug 17 21:39
    [karlgroves] (trollface emoji) No. with them on.
  172. [michiel] jnurthen: yeah, well, we need to tell clients something :P
  173. [michiel] What does Project Oracle use?
  174. James Nurthen
    @jnurthen
    Aug 17 21:40
    essentially multiple expand/collapse regions
  175. each one is a tab stop
  176. zakim-robot
    @zakim-robot
    Aug 17 21:41
    [karlgroves] Identified as links?
  177. [michiel] Yeah I think that is better.
  178. [michiel] Can you share James?
  179. James Nurthen
    @jnurthen
    Aug 17 21:41
    (although I just noticed a bug in it if you start to use the arrow keys the tab navigation breaks)
  180. http://www.oracle.com/webfolder/technetwork/jet/uiComponents-accordion-basicAccordion.html
  181. zakim-robot
    @zakim-robot
    Aug 17 21:42
    [michiel] Thanks
  182. James Nurthen
    @jnurthen
    Aug 17 21:42
    I think they are buttons actually....
  183. zakim-robot
    @zakim-robot
    Aug 17 21:42
    [michiel] Frend's one uses one tab stop