Archive index

A11y Slackers Gitter Channel Archive 5th of October 2015

What fresh hell is THIS now? - Patrick Lauke
  1. MichielBijl
    08:54
    `#a11ywin: boss wants me to do an introduction to accessibility for the project managers :D
  2. zakim-robot
    09:18
    [Charlotte Spencer, a11y] Nice
  3. zakim-robot
    09:19
    [Charlotte Spencer, a11y] People also want me to do one for teams at my work, but I am very much an amateur :grimacing:
  4. MichielBijl
    09:20
    I'm no expert; just someone who specialises in it.
  5. zakim-robot
    09:36
    [rodneyrehm, a11y] I had @redux flown in to give an a11y/aria intro to my team
  6. zakim-robot
    09:36
    [rodneyrehm, a11y] (maybe something similar is an option for you, too)
  7. MichielBijl
    09:38
    I'll have to learn how to do talks at some point; so this is a good time to start learning
  8. zakim-robot
    09:39
    [rodneyrehm, a11y] yes, and yes
  9. zakim-robot
    11:31
    [rodneyrehm, a11y] @michiel: maybe http://de.slideshare.net/cheilmann/the-road-to-being-a-kickass-publis-speaker helps with that learning phase
  10. MichielBijl
    11:50
    Oh I could definitely take some speaker cues from George Carlin :D
  11. MichielBijl
    11:51
    Thank you, added to reading list.
  12. zakim-robot
    16:38
    [heidi valles, a11y] hi! aria-label vs. css-hidden text for icon text-alternatives. is one better than the other?
  13. zakim-robot
    16:48
    [Carolyn MacLeod, a11y] I'm interested in the answer, too. My best guess is aria-label, but I think you need to say how you are implementing your icons. We had <img> at first (best text alternative for img is alt text), then the devs decided that too many img's take too long to load, so we switched to "sprites" (this was a while back), but maintaining those is a pain and they don't scale, so we switched to "icon fonts" with aria-labels. But maybe we should be considering svg?
  14. zakim-robot
    16:50
    [heidi valles, a11y] right, I should’ve specified! The site I’m advising on right now is using icon fonts.
  15. zakim-robot
    16:51
    [rodneyrehm, a11y] depending on what you need the icons for, switching away from IconFonts (to e.g. SVG) is gaining traction because of iOS9’s content blockers and the general ability (and desire) to block web fonts
  16. zakim-robot
    16:54
    [rodneyrehm, a11y] regarding icons from generated content: http://www.brucelawson.co.uk/2014/notes-on-draft-css-alt-property/
  17. zakim-robot
    16:57
    [rodneyrehm, a11y] it was explained to me that aria-label=“” would behave as a replacement for the element’s content. So I assume <span class=“icon-font” aria-label=“explanation">symbol</span> is exactly what you want. Using the visually hidden text would cause the symbol itself to be read as gibberish.
  18. zakim-robot
    16:57
    [rodneyrehm, a11y] (as far as I know and I’m not exactly an authority…)
  19. zakim-robot
    16:59
    [heidi valles, a11y] ah, that’s interesting.
  20. zakim-robot
    17:05
    [heidi valles, a11y] yes icon fonts will be read as gibberish, and so it’s typical to add aria-hidden=“true” to these. but i wonder if the aria-label solves both...
  21. zakim-robot
    17:08
    [rodneyrehm, a11y] I think it does - based on what Heydon told me about aria-label the other day https://twitter.com/heydonworks/status/644542432273657857
  22. zakim-robot
    17:43

    [heydon, a11y] @heidi @rodneyrehm Whether SVG or icon font, you have two strategies, depending on your situation: 1. provide a good label for the icon or 2. bollocks to the icon because it means nothing much anyway, least of all non-visually.

    I’d use SVG and use aria-label on the <svg> element itself. SVG can also have an accessible name via its <title> child element, but this is unreliable without aria-labelledby and FUCK knows how it works when <use> is involved :smile:

  23. zakim-robot
    17:44
    [rodneyrehm, a11y] is anyone testing (physical) keyboard accessibility on Chrome for Android? I’m not getting any keypress to register in the web content view… nothing. zilch.
  24. zakim-robot
    17:45
    [heidi valles, a11y] thanks @heydon :simple_smile:
  25. zakim-robot
    17:47
    [heidi valles, a11y] @heydon aria-label would prob work best for both strategies? is there a case where css-hidden text would be preferable?
  26. zakim-robot
    17:49
    [heydon, a11y] CSS hidden text is better supported going backwards, but aria-label is one of the best supported ARIA properties, so you won’t encounter too many problems. To give you a better insight on aria-label and its different uses, I wrote https://dev.opera.com/articles/ux-accessibility-aria-label/ which may help.
  27. zakim-robot
    17:53
    [heidi valles, a11y] cheers
  28. zakim-robot
    18:08
    [heidi valles, a11y] @heydon and with aria-label, title would be ignored, or also read?
  29. zakim-robot
    18:30
    [dylanb, a11y] @heidi: aria-label takes precedence over title but it could be read on elements that support a hint (e.g. button, input...)
  30. stevefaulkner
    18:35
    when an element has an accessible name and a title, the title attribute provides the accessible description
  31. zakim-robot
    18:40
    [dylanb, a11y] why does @stevef always say things I was trying to say much more eloquently
  32. zakim-robot
    18:43
    [Faruk Ateş, a11y] @dylanb: what're you referring to?
  33. zakim-robot
    18:44
    [dylanb, a11y] @kurafire: he just said what I said, but he said it more eloquently :simple_smile:
  34. zakim-robot
    18:44
    [Faruk Ateş, a11y] ah ok
  35. zakim-robot
    18:47
    [heidi valles, a11y] @dylanb thanks - so i think that means removing title on such elements when there’s an aria-label would be wise, to prevent redundancy.
  36. zakim-robot
    18:48
    [heidi valles, a11y] @stevef what’s an “accessible description” beyond an accessible name…? sorry if i’m being dense!
  37. zakim-robot
    18:54
    [Faruk Ateş, a11y] No I was wondering the same thing, I'm assuming it's a term for a mechanism that Assistive Technologies can display or read out as a supportive accessibility thing?
  38. zakim-robot
    18:56
    [Faruk Ateş, a11y] yeah, that's what I thought, cool
  39. stevefaulkner
    18:56
    and no there is nothing 'dense' about the question :-)
  40. zakim-robot
    18:57
    [rodneyrehm, a11y] are there any good examples for accessible modal dialogs with forms in them? (like a prompt…)
  41. zakim-robot
    18:58
    [heidi valles, a11y] cheers steve
  42. zakim-robot
    18:59
    [Cordelia McGee-Tubb, a11y] @rodneyrehm: i like the “Incredible Accessible Modal" examples: http://accessibility.oit.ncsu.edu/training/aria/modal-window/version-3/
  43. stevefaulkner
    18:59
    :+1:
  44. zakim-robot
    19:05
    [rodneyrehm, a11y] thx!
  45. zakim-robot
    19:09
    [rodneyrehm, a11y] if you open the [modal](http://accessibility.oit.ncsu.edu/training/aria/modal-window/version-3/) and type something into the email address field so that you get your browser’s autosuggest, hit the downward key to select an item, and hit escape to abort the autocomplete selection, the entire dialog is closed. This does not happen for the enter key, because it’s not listening for the enter key - but the form submission instead
  46. zakim-robot
    19:11
    [rodneyrehm, a11y] the modal example is doing everything http://www.w3.org/WAI/PF/aria-practices/#dialog_modal says it should, but in a way that is interfering with browser added UI.
  47. zakim-robot
    19:11
    [rodneyrehm, a11y] hm, it doesn’t do that in Chrome, only in Firefox
  48. zakim-robot
    19:19
    [rodneyrehm, a11y] ah, there we go… https://bugzilla.mozilla.org/show_bug.cgi?id=286933 the bug is only 10 years old…
  49. zakim-robot
    20:13
    [Carolyn MacLeod, a11y] @stevef: Steve, have you had a chance to look at https://bugzilla.mozilla.org/show_bug.cgi?id=670928#c59 yet? I was a bit nervous offering a counter-proposal to yours, so I'd love your feedback on it. :simple_smile:
  50. zakim-robot
    20:14
    [Carolyn MacLeod, a11y] I understand that there's a bit of controversy over the HTML5 outline algorithm with respect to screen readers...
  51. zakim-robot
    20:14
    [Carolyn MacLeod, a11y] such wacky things as what to do if a section's aria-labelledby points to an h1-h6 that happens to implicitly define a section somewhere else...
  52. zakim-robot
    20:14
    [Carolyn MacLeod, a11y] and the whole business of mixing sectioning content with h1-h6's...
  53. zakim-robot
    20:15
    [Carolyn MacLeod, a11y] and the large fact that the algorithm doesn't even mention aria.
  54. zakim-robot
    20:15
    [Carolyn MacLeod, a11y] (I'm glad I didn't know about the controversy before I posted my proposal for the outline feature - it might have affected my thinking <g>).
  55. zakim-robot
    20:15
    [Carolyn MacLeod, a11y] But if the algorithm is broken, can't we fix it?
  56. zakim-robot
    20:17
    [Carolyn MacLeod, a11y] Or am I being incredibly naive?
  57. stevefaulkner
    21:18
    @car I looked at it briefly, have no problem with alternative proposals would just like to see some form of navigation implemented :-)
  58. stevefaulkner
    21:22
    @car re document outline - this may be helpful https://www.w3.org/wiki/HTML/Usage/Headings/h1only
  59. zakim-robot
    21:26
    [Carolyn MacLeod, a11y] @stevef: Me too. If you could find the time to comment on the bug, I think that would be helpful - I have a feeling that DavidB thinks you were working on a simplified proposal.
  60. stevefaulkner
    21:28
    @car, yes I will do
  61. zakim-robot
    21:29
    [Carolyn MacLeod, a11y] @stevef: Thanks. And thanks for the outline spec bug/discussion links. Going through them now.
  62. stevefaulkner
    21:37
    :+1:
  63. zakim-robot
    21:38
    [heydon, a11y] @stevef @dylanb I was talking about the title element :stuck_out_tongue:
  64. zakim-robot
    21:40
    [Steve Faulkner, a11y] @heydon ah a different kettle
  65. zakim-robot
    23:34
    [Faruk Ateş, a11y] What're people's thoughts on Polymer as a ui framework w.r.t. accessibility support?
  66. zakim-robot
    23:34
    [Matt May, a11y] makes cross with fingers
  67. zakim-robot
    23:36
    [Matt May, a11y] AFAICT, there's nothing structurally preventing Polymer components from being accessible. But critically, there's also nothing to _encourage or _verify that they've done so.
  68. zakim-robot
    23:37
    [Faruk Ateş, a11y] Heh, that's kinda how I suspected it to be, which… well, there you go I guess
  69. zakim-robot
    23:37
    [Faruk Ateş, a11y] Thanks @mattmay :smiley:
  70. zakim-robot
    23:38
    [Matt May, a11y] Polymer is actually why my pinned tweet says: "Accessibility. i18n. Security. Device independence. If you don't understand these VERY well, hold off on inventing your own web components."