Archive index

A11y Slackers Gitter Channel Archive 28th of June 2017

What fresh hell is THIS now? - Patrick Lauke
  1. zakim-robot
    @zakim-robot
    Jun 28 00:07
    [nschonni] thanks @marcysutton, i'll do some reading. I hadn't seen the reduced-motion media query before
  2. [nschonni] https://css-tricks.com/introduction-reduced-motion-media-query/
  3. zakim-robot
    @zakim-robot
    Jun 28 02:39
    [muan] Thanks. I replied to the thread.
  4. [nschonni] I appreciate it @muan
  5. zakim-robot
    @zakim-robot
    Jun 28 05:09
    [caesar] Does anybody have an opinion of how one would differentiate ms vs miss in a screen reader?
  6. [caesar] Should we put "miz" for the former so that it can be audibly distinguished from the latter?
  7. zakim-robot
    @zakim-robot
    Jun 28 08:11
    [dani-c] or use abbr tag?
  8. zakim-robot
    @zakim-robot
    Jun 28 12:55
    [karlgroves] Sharing this, HT Adrian Roselli: http://ncamftp.wgbh.org/cadet/
  9. zakim-robot
    @zakim-robot
    Jun 28 15:16
    [cehfisher] i’m signed up for the Tenon.io newsletter (as I’m guessing many here are) and today there was some interesting points about Extreme Accessibility approach and the failure rates for automated testing. just wondering if this info is in blog form so I could easily share with others on my team? or if there are additional resources about either subject people here know about? (cc @karlgroves)

  10. [karlgroves] @cehfisher I’ll be adding those things to the Tenon blog soon

    Here are some other links:
    http://www.karlgroves.com/2016/01/10/the-business-case-for-issue-prevention-extreme-accessibility/
    http://www.karlgroves.com/2016/08/15/extreme-accessibility-revisited/
    https://www.youtube.com/watch?v=YuCT8d1Afk4
    http://www.karlgroves.com/category/agile-accessibility/
    http://www.karlgroves.com/presentations/

  11. [karlgroves] http://blog.tenon.io/getting-instant-return-from-your-accessibility-testing/
  12. zakim-robot
    @zakim-robot
    Jun 28 15:22
    [nodesman] is this the right channel to ask about ARIA HTML markup related questions?
  13. [cehfisher] thanks much @karlgroves! please let us know when you have the new post up too…no pressure, but really interesting content
  14. [garcialo] @nodesman Yup.
  15. [tink] @nodesman it is, and welcome :)
  16. [garcialo] I…likely wouldn’t be the one to help you with that particular question, but this is the place.
  17. [nodesman] Thank you!
  18. zakim-robot
    @zakim-robot
    Jun 28 15:27
    [nodesman] Our website has a overlay that shows the user that their search results are being updated to reflect their changed filtering/sorting order. I am attempting to make that overlay be screen readable. Marking that overlay's containing div as aria-live reads the elements' text content. This text content for non-visually impaired people is different from what should be read out by screen readers. Setting aria-label does not result in VoiceOver reading the label - it still reads the text content. How do you overcome this?
  19. [nodesman] tldr; this jsfiddle doesn't work as expected: https://jsfiddle.net/sh3n2vtt/1/
  20. [garcialo] @nodesman Are you planning to have that be like a modal dialog?
  21. zakim-robot
    @zakim-robot
    Jun 28 15:33
    [garcialo] Or just some random flyout?
  22. [nodesman] its not a modal dialog exactly. it is a small box that overlays over main search results that tells the user that the search results are updating.
  23. [nodesman] yes its a flyout - assuming it is something the user will not have an option of interacting actively
  24. [garcialo] Can you copy/paste the text with a mouse?
  25. [garcialo] Or rather…will it be expected that the user can copy the text with a mouse.
  26. [nodesman] Which text? Do not follow
  27. [garcialo] The text in the overlay
  28. [nodesman] Untitled
  29. [nodesman] But the screen reader should not read this - it should instead read "Updating search results, please wait"
  30. [garcialo] It seems to read “Some content goes here” for me in the jsfiddle with VO+Safari on Mac OS
  31. zakim-robot
    @zakim-robot
    Jun 28 15:38
    [nodesman] yes. which corresponds to the snipped I've posted above.
  32. [garcialo] So…you don’t want it to read what’s being displayed visually? Maybe I’m confused.
  33. [nodesman] yes. dont read whats being displayed visually
  34. [nodesman] yes
  35. [garcialo] Why would you not want the screen reader to say what the browser is displaying visually?
  36. zakim-robot
    @zakim-robot
    Jun 28 15:43
    [nodesman] Because the overlay appearing is visual feedback for people who can see that there is work being done in the background. Therefore the text within it can be points USP about the company - "x Verified reviews, x Properties listed, etc...". That text being read out to the visually impaired as a result of the them attempting to filter the search results is out of place and does not tell them what is happening - we want to be explicit that a search lookup is occuring and that they need to wait.
  37. [garcialo] Okay…so then while that overlay is there, the user can’t interact at all with what’s behind it?
  38. [nodesman] Nope.
  39. zakim-robot
    @zakim-robot
    Jun 28 15:48
    [nodesman] But there are elements around it - the filters that they can apply more of.
  40. [garcialo] okay, so then it’s just for the “results” area that its’ disabling
  41. [nodesman] yes
  42. zakim-robot
    @zakim-robot
    Jun 28 15:57
    [garcialo] My first thought is that it’s still like an alert dialog…but only for that area of the page. In general, we don’t want to have any sighted-only-content. I don’t personally think that a message showing up and making the results non-interactive clearly communicates “results being updated” - it could also mean “we had a brief outage.” So, you’ll want to communicate that information in text…maybe as like a title or the first <p> in that alert. Additionally, it’s not a good practice to have sighted-user-only content. Why would your company only want sighted users to have the “points about the company?” Also, not all screen reader users are blind, some use it because they might find it easier to read if they’re also hearing the content, for example. So…if they can see the content, but can’t get to it with the screen reader, it’d be a bad user experience.
  43. [garcialo] Here’s a pattern to help get you started…since you’ll want to be disabling the results content. https://ebay.gitbooks.io/mindpatterns/content/disclosure/dialog.html
  44. zakim-robot
    @zakim-robot
    Jun 28 16:03
    [garcialo] I’m thinking if you’re presenting more than just “loading” in that overlay, the user might find that information useful and want to share it with others…so it might be a good idea to give them control over whether it closes automatically once the results are finished loading.
  45. zakim-robot
    @zakim-robot
    Jun 28 16:39
    [dickson] Hey everyone, quick CSS-related question. I've encountered a page that does use HTML5 radios and checkboxes. For styling purposes, the element itself has been hidden (visually and from screen readers too), and the label is what sighted users can click on. My PR only hides it visually, using the CSS at http://webaim.org/techniques/css/invisiblecontent/ Author is worried that "Hiding stuff offscreen interacts poorly with various mobile browsers and rendering engines.". Any advice? This is for a damage calculator at http://pokemonshowdown.com/damagecalc/
  46. [cmegown] @dickson does the label still have a for attribute linking it to it's respective input elemtn?
  47. [dickson] Yup
  48. [cmegown] then you should be fine. i've never experienced an issue with limited interaction on either medium.
  49. [cmegown] make sure when you're styling custom radio buttons and checkboxes that you account for focus states. the native element may be visually hidden but it's still accessible via the tab keys
  50. [dickson] Yeah, its accessible via tab, but I believe a focus rectangle is not drawn
  51. [cmegown] you'd have to add custom focus styles to your custom elements
  52. zakim-robot
    @zakim-robot
    Jun 28 16:45
    [cmegown] the browser is still focusing on the input element but you can "transfer" it via css selectors
  53. [cmegown] [type='checkbox']:focus + label:before { /* focus styling */ }
  54. zakim-robot
    @zakim-robot
    Jun 28 16:54
    [dickson] Why the pseudo-element ::before?
  55. [dickson] If i understand right, this means "for all focused checkboxes's immediate label sibling, select the element before that", won't that just be the checkbox itself?
  56. [cmegown] well it depends on your html structure so you'll have to adapt what i wrote to fit your situation
  57. [cmegown] sorry, i could have been clearer on that.

  58. [ryan] Sorry to interject but I think this part may be misunderstood.

    select the element before that

  59. [ryan] ::before doesn't select the previous element but instead it appends a pseudoelement to the selected element itself.
  60. [ryan] Sorry if that was already understood. :)
  61. zakim-robot
    @zakim-robot
    Jun 28 17:00
    [dickson] @ryan great, thanks for the correction, I'm actually not that familiar with CSS, so didn't know that
  62. [dickson] Trying to pick up what I need to know to fix accessibility issues, since playing with colours and such isn't so interesting for me :d
  63. [ryan] Ok cool! What he was doing is using the pseudo-element to display the focus state on the label visually (instead of on the checkbox itself)
  64. [cmegown] yes, great catch @ryan. i was assuming a certain html structure when i shouldn't have.
  65. [dickson] That page has checkboxes/radio buttons immediately proceeded by their corresponding labels on the same level as a sibling
  66. zakim-robot
    @zakim-robot
    Jun 28 17:05
    [cmegown] the comes before the input element? that will make it tricky
  67. [dickson] Sorry its after
  68. [dickson] so like <input ...><label ...>
  69. [cmegown] ok, then you should be fine.
  70. zakim-robot
    @zakim-robot
    Jun 28 17:14
    [dickson] @cmegown @ryan thanks for the help =D its past 1AM here, so will do more reading on pseudo-elements later.
  71. [ryan] This should help as well. https://codepen.io/mpeace/pen/EKZqJP
  72. zakim-robot
    @zakim-robot
    Jun 28 17:23
    [jpdevries] Hey slackers. I’ve been slacking. :face_with_rolling_eyes: I’m on the board of MODX, a PHP CMS, and have drafted an accessibility mandate (kind of forks Wordpress’) for future major versions of the product, but am having a hard time ironing out some of the details. If anyone has any input, resources, advice would greatly appreciate it
    modxcms/mab-recommendations#3
  73. [tink] @jpdevries is it possible to read it in rendered version? Reading commit diffs is painful.
  74. [jpdevries] @tink certainly there is a “view the markdown preview” online link at the top
    https://github.com/jpdevries/mab-recommendations/blob/a11y-setup/proposed/a11y-setup.md#-accessible-setup-%EF%B8%8F
  75. [jpdevries] @tink certainly there is a “view the markdown preview” online link at the top
    https://github.com/jpdevries/mab-recommendations/blob/accessibility-mandate/proposed/a11y-mandate.md#goal-of-recommendation
  76. zakim-robot
    @zakim-robot
    Jun 28 17:30
    [tink] Thanks.
  77. [tink] NP - is there anyting in particular you want comments on?
  78. zakim-robot
    @zakim-robot
    Jun 28 17:35
    [tink] It looks good to me in general. Good advice and clear goals.
  79. [jpdevries] Mostly looking for general feedback. Some of the loose ends are kind of tricky, like who decides how accessibility advisors are appointed. Things like that
  80. zakim-robot
    @zakim-robot
    Jun 28 18:49

    [cielt] hi @jpdevries: glad MODX is taking this step +1 from a quick read, there are a couple of items i think bear elaborating on, namely:

    While MODX has acknowledged the importance of accessibility, to date the project hasn’t been able to accurately define accessibility – let alone a path towards it. It would be unrealistic to expect MODX Contributors to become accessibility experts capable of following the latest accessibility success criteria and other best practices over night. This is why supporting documentation, examples, and human resources will be needed to make accessibility best practices accessible to contributors.

    is this document a place in which it makes sense to define accessibility (since the need to do so was made plain) and / or mention some guidelines (e.g., [WCAG](https://www.w3.org/TR/WCAG20/)) to which software makers should aspire? for myself (especially if i am more in the novice category), specifics that define web a11y would be enormously helpful.

    And re the aforementioned “supporting documentation, examples, and human resources” the intent to provide support in individuals’ efforts to build a11y into the software is clear, but would this be a place in which some of these resources could be named? the document goes on at some length about certified MODX Accessibility Advisors (what their role is, the importance of access) but it seems that, even before an expert need be called in, some resources, readily available and free of cost, could go a long ways toward enabling devs and product teams to understand, build and test for a11y. would this be a place to list out some links to guidelines, tutorials, examples, testing software, etc.?

    Just a thought from the perspective of someone who is still trying to learn and has found it helpful to talk about a11y in concrete terms re:

    * what it means for a site / app to be accessible (e.g., provides as semantic / clear / operable a screen reader experience as possible; allows users to interact with the entire app using a keyboard only; includes captions / transcripts if there is video content, etc.)
    * what kinds of design and dev decisions will ensure accessible UX in a product.

    Getting access to an accessibility advisor sounds amazing, but even before that point it seems worth highlighting that many resources exist that will help folks equip themselves with knowledge to start building and testing for a11y. Maybe worth spending some time on these bits? Good luck!

  81. zakim-robot
    @zakim-robot
    Jun 28 23:08
    [jpdevries] cielt: Thank you so much for the feedback! I’ll respond in this thread