Archive index

A11y Slackers Gitter Channel Archive 17th of May 2017

What fresh hell is THIS now? - Patrick Lauke
  1. zakim-robot
    @zakim-robot
    May 17 00:47
    [quidkid] @garcialo i’m going off of what I had to do to remediate a similar hamburger menu on mobile. although that trap was with the arrow keys. actually i’m looking back at it now and it does tab past and closes. i have no clue about themes given i’m still a newbie at accessibility
  2. zakim-robot
    @zakim-robot
    May 17 14:28
    [skymaiden] Hello! I've been trying to find an answer to a possibly dumb question, but I'm turning in circles – does anyone know if AT generally treats an absent aria-checked attribute the same as aria-checked="false"? I'm working on a react app, and it's not even putting the attribute in my generated HTML if the JS condition is false...(unless I manually write myCondition ? 'true' : 'false')
  3. [skymaiden] same for aria-pressed
  4. Fiona Holder
    @FionaHolder
    May 17 14:29
    What element is the attribute on?
  5. zakim-robot
    @zakim-robot
    May 17 14:31
    [skymaiden] the aria-checked is on a menuitem (<li>), and the aria-pressed on a menu button
  6. Fiona Holder
    @FionaHolder
    May 17 14:33
    I feel like even if you'd given them a role of checkbox, the AT would probably not state it was unchecked if aria-checked was missing. Though I don't have a laptop on me to give it a quick test right now
  7. Docs seem to state that if attribute is not present, the element doesn't support being checked: https://www.w3.org/TR/wai-aria/states_and_properties#aria-checked
  8. Not a default to false behaviour
  9. zakim-robot
    @zakim-robot
    May 17 14:38
    [skymaiden] ah! I didn't see that
  10. [skymaiden] same for aria-pressed
  11. [skymaiden] and I guess anything else with an on/off state
  12. [scottohara] yeah. no auto default there. there’d be no context for it to know it was even a checkbox, or a pressable item without the attribute to tell it so
  13. [skymaiden] ok, I'm going to manually write true/false strings to force the values to be written to the dom
  14. [skymaiden] thanks @fionaholder and @scottohara
  15. [skymaiden] I have another question: how are people handling dynamic DOM for AT? In this app, when elements are visually hidden they are also removed from the DOM, so I'm guessing that makes things tricky for screen reader users...
  16. zakim-robot
    @zakim-robot
    May 17 14:43
    [skymaiden] the interface comes back on hover for sighted mouse users – and I was thinking of adding a "dummy focus" item for keyboard users, to bring back the interface on tab then shift focus to the first real interface element...
  17. [skymaiden] but I'm not too sure how to make this work for screen readers...
  18. zakim-robot
    @zakim-robot
    May 17 15:10
    [quidkid] leaving this here: http://news.wabe.org/post/georgia-aims-make-its-websites-accessible-all
  19. zakim-robot
    @zakim-robot
    May 17 15:29
    [skymaiden] just discovered there are dedicated channels, I'll take my question to a more relevant room – sorry!
  20. James Nurthen
    @jnurthen
    May 17 15:34
    @skymaiden you need to be careful to only use aria-checked and aria-pressed on roles that support the checked/pressed state
  21. pressed on a button turns it into a toggle button so if that is what you want you need aria-pressed="false" to be an unpressed toggle button
  22. zakim-robot
    @zakim-robot
    May 17 15:38
    [skymaiden] yes exactly – i have aria-pressed on toggle buttons only, but I need it to be aria-pressed="false" for it to be recognised correctly
  23. James Nurthen
    @jnurthen
    May 17 15:38
    yes - cause that it the trigger it is a toggle button not a normal button.
  24. zakim-robot
    @zakim-robot
    May 17 15:38
    [skymaiden] but the JS was omitting the attribute completely if the value wasn't a string
  25. James Nurthen
    @jnurthen
    May 17 15:39
    for the gory details see https://www.w3.org/TR/core-aam-1.1/#role-map-button
  26. for the dynamic dom question it really depends if a screen reader should have access to the functionality all the time or if you want to handle it like for keyboard users
  27. I can't give a hard rule on that though.... very variable
  28. zakim-robot
    @zakim-robot
    May 17 15:44
    [skymaiden] oh wow that link... not as readable as the one posted earlier by fiona
  29. James Nurthen
    @jnurthen
    May 17 15:44
    ... I said it was the gory details.....
  30. that is what is going on under the covers.... its the doc that we use to test if aria is doing what it should be doing in the different Accessiibility APIs
  31. zakim-robot
    @zakim-robot
    May 17 15:45
    [skymaiden] but I think you might be right in that it depends on whether we want to replicate the keyboard experience – which itself tries to replicate the mouse experience
  32. James Nurthen
    @jnurthen
    May 17 15:45
    very much a usability question
  33. zakim-robot
    @zakim-robot
    May 17 15:46
    [skymaiden] you guys are amazing
  34. [tink] For anyone here who uses a screen reader and Github, they've just added headings for individual comments on issue/PR discussions.
  35. James Nurthen
    @jnurthen
    May 17 15:46
    woo hoo
  36. not just screen readers. the Low Vision task force was crying out for those
  37. zakim-robot
    @zakim-robot
    May 17 17:24
    [simong] Does anyone have any experience with accessible emails? Is there any reason NOT to use h1..h6 or role=“presentation” for non datatable-tables ?
  38. [simong] One of our marketing vendors is claiming they use <div> for everything as it renders better.
  39. [simong] Having done some email work in the past I can attest that having properly functioning emails is hard, but I never came across anything like headings or role=“presentation” messing things up ..
  40. zakim-robot
    @zakim-robot
    May 17 17:38

    [m_j_robbins] I’d say 100% you should use H and P, and use role="presentation on non-data tables

    People used to say avoid <h> and <p> tags in email because they are harder to style consistently. But that’s just lazy.

  41. [m_j_robbins] Outlook.com and AOL will strip out role and aria but not much we can do about that
  42. [m_j_robbins] I’d also say avoid HTML5 Semantic tags as these are striped out too but not replaced with anything, so any class, id, or style added will be removed too
  43. zakim-robot
    @zakim-robot
    May 17 17:46
    [simong] Thanks for confirming @m_j_robbins! I suspect they’re just being lazy but don’t have enough resources to back it up
  44. zakim-robot
    @zakim-robot
    May 17 18:07
    [michiel] simong: you might be interested in this article Mark wrote: http://blog.rebelmail.com/accessibility-in-email-part-ii/
  45. [michiel] And the preceding one: http://blog.rebelmail.com/accessibility-in-email/
  46. [simong] That’s actually the article we sent to our vendor ^^
  47. [michiel] Nice goin’ thumbsup emoji:skin-tone-3:
  48. [michiel] _is still baffled by m_j_robbins’ talk at CSS Day_
  49. [michiel] I won’t spoil it, but that was truly amazing
  50. [michiel] ’twas like a great plot twist in a great drama film.
  51. zakim-robot
    @zakim-robot
    May 17 18:17
    [m_j_robbins] haha cheers mate
  52. zakim-robot
    @zakim-robot
    May 17 18:30
    [m_j_robbins] A few more articles on accessible email listed here if you need them @simong + anyone else who’s interested https://github.com/wilbertheinen/accessible-email-documentation