Archive index

A11y Slackers Gitter Channel Archive 9th of December 2015

What fresh hell is THIS now? - Patrick Lauke
  1. stevefaulkner
    13:48
    slackers :clap:
  2. garcialo
    13:48
    You're easily impressed.
  3. MichielBijl
    13:59
    Question (about a11y for once): In VoiceOver, a numeric stepper (<input type="number">) is exposed as four individual elements in the form controls list; once with the calculated name, as simply “stepper” and twice as “button” without any name. Is this expected? How do other AT handle this?
  4. garcialo
    13:59
    if you have a public page, I can give you a copy/paste from NVDA output so you can compare it to what you're getting
  5. MichielBijl
    14:01
    Hold on
  6. MichielBijl
    14:04
    And I know those should have a label.
  7. garcialo
    14:04
    understood, you just need to see what's announced
  8. MichielBijl
    14:04
    Label is calculated from placeholder.
  9. MichielBijl
    14:04
    In VO anyway.
  10. MichielBijl
    14:04
    Tried adding a proper label with aria-label, but then VO announces it twice :/
  11. garcialo
    14:04
    you mean accname is calculated from placeholder =p
  12. MichielBijl
    14:04
    Yes
  13. MichielBijl
    14:05
    That is what I meant =p
  14. MichielBijl
    14:05
    Any other tips for forms are welcome.
  15. MichielBijl @MichielBijl is slowly improving the a11y of this project.
  16. zakim-robot
    14:22
    [callumacrae] Screen reader isn't picking up label for text input :confused: it's just reading out "required, edit text", which doesn't make much sense
  17. zakim-robot
    14:23
    [callumacrae] markup is:
    <label for="name">Name</label> <input type="text" name="name" id="name" autocomplete="off" aria-required="true">
    
  18. zakim-robot
    14:23
    [callumacrae] any ideas?
  19. zakim-robot
    14:30
    [karlgroves] What screen reader?
    Have you tested that code by itself (absent anything else on the page)
  20. zakim-robot
    14:31
    [karlgroves] Have you verified that no other inputs have the exact same ID? Have you hidden the label with CSS?
  21. zakim-robot
    14:32
    [karlgroves] That markup WFM http://output.jsbin.com/gopiya
  22. zakim-robot
    14:33
    [callumacrae] works by itself on that page, but there are no other elements with that ID
  23. zakim-robot
    14:33
    [karlgroves] There shouldn’t be > 1 element with the same ID.
  24. zakim-robot
    14:36
    [johnbhartley] would it be appropriate to use the below in this case? I've seen aria-labelledby as one way to fix the label not being read
    <label for="name" id="name-label">Name</label> <input type="text" name="name" id="name" autocomplete="off" aria-required="true" aria-labelledby="name-label">
    
  25. zakim-robot
    14:38
    [karlgroves] That would be an unnecessarily redundant use of ARIA. The pattern that @callumacrae is using is universally supported across all browsers and ATs that youd reasonably expect to be visiting
  26. zakim-robot
    14:39
    [callumacrae] That input is the only element with that ID
  27. zakim-robot
    14:39
    [callumacrae] I'm using VoiceOver
  28. zakim-robot
    14:39
    [johnbhartley] so just using the for="idName"
  29. zakim-robot
    14:39
    [callumacrae] Working when that's the only HTML on the page (with the CSS+JS still there), but not in context
  30. zakim-robot
    14:41
    [karlgroves] @callumacrae: you’ll need to eliminate other possible contributing factors, as there’s no logical reason why that wouldn’t work on VO. What browser?
  31. zakim-robot
    14:42
    [callumacrae] safari
  32. zakim-robot
    14:42
    [karlgroves] @johnbhartley: yeah, just using <label for=“foo”> where foo matches an id of a form field.
  33. zakim-robot
    14:42
    [karlgroves] @callumacrae: something else is contributing then
  34. zakim-robot
    14:42
    [callumacrae] also, it's here: https://www.lostmy.name
  35. zakim-robot
    14:42
    [callumacrae] It's the "Name" input
  36. zakim-robot
    14:43

    [karlgroves] @callumacrae:

    Dude.

    <label class="label--bubble label--bubble label--error error-name" data-js-tracking="error--name-field--homepage--form" aria-live="polite" for="name" style="visibility: hidden; display: none;"></label>

  37. zakim-robot
    14:44
    [callumacrae] oooh two labels
  38. zakim-robot
    14:44
    [callumacrae] d'oh
  39. zakim-robot
    14:44
    [karlgroves] No
  40. zakim-robot
    14:44
    [karlgroves] :wink:
  41. zakim-robot
    14:50
    [johnbhartley] removing that first label does fix it in VO, but maybe I'm not seeing the other reason for it not working
  42. zakim-robot
    14:51
    [callumacrae] I just turned it into a span, seems to have done the trick :simple_smile:
  43. zakim-robot
    15:01

    [karlgroves] New post by @stevef

    "ARIA allows developers to re-invent and extend native HTML features in meaningful ways. But like all bolt-on technologies its features are brittle compared to its built-in counterparts."
    http://html5doctor.com/html-developers-please-consider/

  44. MichielBijl
    15:23
    We should send a printed version of the first rule of ARIA to all developers in the world.
  45. zakim-robot
    15:58
    [karlgroves] Poster sized!
  46. deborahgu
    16:17
    I know HTML is hard to modify, but is there a reason the successful bits of aria aren't at least in the process of getting merged into HTML core? or is it that some of them are, and the process is just slow?
  47. deborahgu
    16:17
    and then they would cease to be bolt-on
  48. zakim-robot
    16:22

    [karlgroves] Not sure I understand the question. HTML5 references ARIA roles, states, and properties as valid.

    ARIA’s purpose is to bridge gaps between the current UI/ Widget paradigms in use on the web and the existing platform features. The example I use a lot are tree menus. There are no elements in HTML that can create a tree menu widget. However, people have been doing them for years, using divs and spans or (hopefully) properly structured HTML lists along with JS. Using ARIA, you can apply roles, states, and properties to these things and allow AT to communicate to the user about what the widget is and what it is doing.

  49. pkra
    16:23
    Does anybody know if JAWS 17 has issues with live regions on IE10 +Win7? This demo http://s.codepen.io/pkra/debug/BoVBpX works in most other JAWS+browser+windows combinations I tried but I get nothing on IE10+Win7.
  50. zakim-robot
    16:43
  51. MichielBijl
    16:46
    @pkra I heard someone here say that live regions and JAWS+IE are a pain in the ass
  52. pkra
    16:49
    @MichielBijl thanks! I saw that the other day -- and I won't argue ;-) Still, our approach seems to work for JAWS in FF, Chrome, IE from WinXP through Win10 (not Edge of course.), so I'm thinking I'm missing something particular about IE10 in Win7.
  53. pkra
    16:50
    Oh, let me correct that. I haven't tested IE8 and IE9 yet since they don't support xpath well enough.
  54. MichielBijl @MichielBijl waves at @stanislauzubovich
  55. deborahgu
    16:58
    @karlgroves, it's a multipart question. One is, there are frequent complaints (both in and out of the W3C) that ARIA is "bolt-on". We shouldn't put such and such in the ARIA spec because it's bolt-on and makes accessibility a second class citizen (ignoring that if it's not in ARIA it will be nowhere). Or webdevs should understand enough to avoid WAI-ARIA if HTML5 can do a thing, because ARIA is bolt-on. So if bolt-on is a problem, shouldn't elements of ARIA eventually migrate into core HTML?
  56. zakim-robot
    17:00
    [karlgroves] That’s probably based on a misunderstanding of ARIA, which isn’t surprising, really. Most devs don’t truly understand HTML, much less ARIA, because they aren’t expected to. :disappointed:
  57. MichielBijl
    17:00
    Why is ARIA bolt-on? I see it as something that gives more freedom in which elements you use and how you style them. Sure, I don't agree with creating button's with div's, point is you can.
  58. deborahgu
    17:00
    and secondly why is there no tree widget in HTML, or getting there? Why no dropdown menus? These are ubiquitous elements which are clearly widely used at this point, and HTML seems to have happily deferred to the Permanent Polyfills model. ARIA + JS solves the dropdown menu problem, right? Of course it results in 9 million separate implementations, which work differently, mostly inaccessible, and that many extra JS libraries on every web page. why not bring these into HTML eventually?
  59. deborahgu
    17:01
    I don't know why people call it bolt-on, but I've seen that argument used by people on the group formerly known as PF, so I assume it's not a misunderstanding of ARIA.
  60. MichielBijl
    17:01
    Hmm, not saying my way is the correct way of looking at it, that is just my opinion.
  61. MichielBijl
    17:02
    You can however use it as bolt-on.
  62. TzviyaSiegman
    17:02
    I have seen many arguments for better documentation about ARIA implementation. It is very hard for n00b to understand
  63. MichielBijl
    17:03
    @TzviyaSiegman can't argue with that.
  64. zakim-robot
    17:03
    [karlgroves] Many of the widget patterns that were described within ARIA are actually in HTML5 now, like a large number of the new input types.
  65. deborahgu
    17:04
    true! and those are awesome
  66. deborahgu
    17:04
    one of my favorite things is going through peoples HTML and pointing out that they can take out all of their fancy JavaScript libraries to give them inaccessible sliders because HTML 5 made everything happier.
  67. zakim-robot
    17:12
    [stanislauzubovich] Hi! Found an problem with tooltips (ok, it's divs with display none/block with tiny click/focus/blur js) on Mac+VoiceOver+Safari env. Problems with reading or re-reading on focus after first. Maybe someone had the same issue?
  68. MichielBijl
    17:53
    Do you have a code example?
  69. zakim-robot
    17:54
    [stanislauzubovich] can't share it due to code of conduct =(
  70. MichielBijl
    17:56
    Not even a stripped down version?
  71. zakim-robot
    17:57
    [stanislauzubovich] it still would be a huge amount of code :smiley:
  72. MichielBijl
    17:58
    Just put it in a CodePen thing or something.
  73. MichielBijl
    17:58
    How can a tooltip be a huge amount of code?
  74. zakim-robot
    17:58
    [stanislauzubovich] I know - but rules are still rules.
  75. MichielBijl
    17:59
    Accessible tooltips that work on touch/focus.
  76. MichielBijl
    17:59
    ±23 lines of CSS.
  77. MichielBijl
    17:59
    For the basics that is.
  78. MichielBijl
    18:00
    150 lines for the whole thing.
  79. MichielBijl
    18:01
    But not sure what you're looking for of course.
  80. powrsurg
    18:02
    shouldn't that have role="tooltip"?
  81. MichielBijl
    18:02
    sssht :P
  82. zakim-robot
    18:02
    [stanislauzubovich] Thanks a lot! To clear the situation - we have a big project with 15+ customers (sic) and we still have table layout :smiley: lots of legacy code and lots of rules is a huge pain :smiley:
  83. MichielBijl
    18:02
    In the description is a link to @Heydon's example.
  84. powrsurg
    18:02
    and what is read to the user?
  85. MichielBijl
    18:02
    link text plus tooltip.
  86. MichielBijl
    18:03
    Only tested with VO though :(
  87. powrsurg
    20:23
    We have white text on a black background with a 50% alpha opacity (e.g. rgba(0, 0, 0, .5)) that is positioned overtop a user supplied image. How can we ensure that's enough contrast.
  88. zakim-robot
    20:35

    [karlgroves] @powrsurg can you do me a favor? Try TPG’s color contrast analyzer on that. https://www.paciellogroup.com/resources/

    I’d be interested in knowing how that works in your use case

  89. powrsurg
    21:01
    I'm forwarding that along to the dev working on it
  90. powrsurg
    21:04
    A quick test shows that it is getting the right colors
  91. zakim-robot
    21:07
    [karlgroves] :+1:
  92. powrsurg
    21:12
    But now we need a JavaScript based version that can pick the true color that is being shown at that point (where there is no text) so we can change the text color dynamically
  93. zakim-robot
    21:14
    [karlgroves] Good luck with that. Getting the color contrast using BG and FG rgba is straightforward, as is the ability to lighten or darken the color. But add a user-supplied background image and you’re talking the Holy Grail of contrast-finding
  94. powrsurg
    21:18
    Yeah, hence why I asked here first because I thought this room was the most likely place to get it right
  95. powrsurg
    21:18
    think about it, it's really hard since the background image could change anywhere so it could have sufficient contrast in one spot and insufficient contrast 20px down
  96. zakim-robot
    21:19
    [karlgroves] Yeah. :disappointed:
  97. zakim-robot
    21:20
    [karlgroves] I mean, you could do some heroics with getImageData using <canvas> but that’s gonna be crazy expensive to dynamically calculate & modify
  98. zakim-robot
    21:25
    [jdan] medium solves this by placing a dark gradient on all images with text on them
  99. zakim-robot
    21:25
    [jdan] I don’t know if it “solves” it meaning WCAG 2.0 AA compliant or anything like that
  100. zakim-robot
    21:26
    [jdan] but the white text they put on top of cover images is very readable because of the gradients over user-provided images
  101. zakim-robot
    21:29

    [blavalla] @karlgroves, the first thing that came to mind was this:

    1.) Add the image into a canvas and get the image data, store this in some variable.
    2.) Draw the text via canvas onto that same image, and get the image data again.
    3.) Compare the two and throw out any image data that is unchanged.
    4.) Average the color of the remaining pixels, and compare.

    It definitely won't be perfect, but it'll give you a decent ballpark estimate.

  102. zakim-robot
    21:29
    [blavalla] The simpler option is just a gradient or outline around the text that is always there regardless of the background.
  103. zakim-robot
    21:33
    [karlgroves] I’m guessing at a certain opacity level with white foreground text almost everything will pass. I don’t know whether it’d meet aesthetic goals...
  104. powrsurg
    21:34
    We basically wanted to copy what Google does with the "change profile image" when you're logged in to Google and click on your image in the top right in that little popout window
  105. alice
    21:45
    @powrsurg I had a chat with Cordelia Dillon about this a while ago in the context of the devtools contrast ratio line, and she had this really great insight: just check the worst possible case for the background image, i.e. the text color
  106. powrsurg
    21:49
    okay, that might work give us somewhere to go off of ...
  107. zakim-robot
    23:26
    [dylanb] @blavalla: FireEyes does something similar to what you mention. It can only do this reliably because it runs in privileged context. iframes for example, cannot be rendered onto a canvas element except when priveleged. But then again, aXe and FireEyes are the only tools that work with X-domain iframes
  108. jnurthen
    23:54
    @dylanb not the only tools - the only publicly available tools ;)