Archive index

A11y Slackers Gitter Channel Archive 7th of August 2017

What fresh hell is THIS now? - Patrick Lauke
  1. zakim-robot
    @zakim-robot
    Aug 07 00:24
    [scottohara] Hey @seankeegan, take a look at this listing of courses. Hopefully something there that might help: https://github.com/mgifford/a11y-courses
  2. zakim-robot
    @zakim-robot
    Aug 07 00:37
    [seankeegan] @scottohara excellent - thank you
  3. zakim-robot
    @zakim-robot
    Aug 07 01:56
    [cameron] oh snap https://github.com/rails/rails/issues/30096#issuecomment-320549490
  4. [cameron] georgeclaghorn commented 7 minutes ago Thanks for the clarification. I’m in favor of removing the fallback in Rails and leaving it up to the screen reader. 😄
  5. [cameron] that's exciting
  6. [cameron] thanks @scottohara and @mgifford for chiming in!
  7. [cameron] fires up the PR engines
  8. zakim-robot
    @zakim-robot
    Aug 07 13:08
    [mtribone] @cameron Yeah I’ve had a similar issue with the image tag helper. I override it in my application, but changing the default behavior is even better! http://www.mtribone.com/code/image-tag-helper.html
  9. zakim-robot
    @zakim-robot
    Aug 07 15:44
    [melsumner] has anyone worked with Java Access Bridge from Oracle?
  10. zakim-robot
    @zakim-robot
    Aug 07 17:31
    [quidkid] For accessibility how should read more links work?
  11. [marcysutton] there was a whole discussion on that...you could scroll back a few days
  12. zakim-robot
    @zakim-robot
    Aug 07 18:06
    [quidkid] @marcysutton thanks for responding!! although mine, sorry I should’ve been more specific, but currently if a screenreader user read through this, when they hit the div with the content, they will be able to read all of it before they hid the read more button. Visually, you can’t unless you click “Continue reading” which expands the div with the content. I’m wondering then whether I should hide the continue reading button from the screenreader
  13. zakim-robot
    @zakim-robot
    Aug 07 18:43
    [melsumner] Does anyone have a good way to explain the difference between screen reader "focus" and visible focus indicator
  14. [melsumner] (it's okay if not, it will just save me some thinking if someone else has already put this into words)
  15. zakim-robot
    @zakim-robot
    Aug 07 18:55
    [johnbhartley] screen reader focus generally focuses on whatever it is reading, while visible focus is only the items on a page that are in the tab order (default tab order or items you've added to the tab order)
  16. zakim-robot
    @zakim-robot
    Aug 07 19:00
    [alexlande] I usually think of it as browser focus vs screen reader cursor to help differentiate
  17. zakim-robot
    @zakim-robot
    Aug 07 19:13
    [johnbhartley] ahhh that's right @alexlande i was trying to think of the term "virtual cursor" for screen readers
  18. zakim-robot
    @zakim-robot
    Aug 07 20:31
    [garcialo] @melsumner visible focus is used by sighted keyboard only users; with few exceptions, visible keyboard focus is only put on interactive page elements. “screen reader focus” (regardless of whether a visible virtual cursor is displayed) represents the screen reader’s currently position on the page, and kind of by definition is used by people using a screen reader. Non-presentational content on the page should be able to receive “screen reader focus;” not just interactive elements.
  19. zakim-robot
    @zakim-robot
    Aug 07 20:39
    [melsumner] for example, when in browse mode, pressing the down arrow should allow me to reach items via "screen reader focus"
  20. [melsumner] @garcialo that's helpful wording, thank you
  21. [garcialo] np
  22. zakim-robot
    @zakim-robot
    Aug 07 21:19
    [melsumner] I tried to explain it with an example (from RL, something I was asked to make at work): https://codepen.io/melsumner/pen/ZJeYoP - if anyone was available to give me a sanity check, I'd be grateful.
  23. zakim-robot
    @zakim-robot
    Aug 07 22:13
    [quidkid] Should tabs for tab panels be a tags or button tags?
  24. zakim-robot
    @zakim-robot
    Aug 07 22:23
    [ugi] @quidkid If you are using role=“tab” to override the semantics, I’d probably go with the button, because it can also be activated with the Space bar. If it’s a simpler implementation without the use of Aria, then a simple <a> is probably a better choice, because in essence it is just an in-page link, possibly linking to the start of the tab panel content.
  25. [ugi] See http://w3c.github.io/aria-practices/examples/tabs/tabs-2/tabs.html and http://simplyaccessible.com/article/danger-aria-tabs/