Archive index

A11y Slackers Gitter Channel Archive 21st of July 2017

What fresh hell is THIS now? - Patrick Lauke
  1. zakim-robot
    @zakim-robot
    Jul 21 00:12
    [quidkid] Should you use role=“presentation” on lists for menu navigation and/or footer links?
  2. zakim-robot
    @zakim-robot
    Jul 21 00:21
    [backwardok] menu aria practices: http://w3c.github.io/aria-practices/#menu
  3. [backwardok] i feel like if you were putting footer links in a list that it was for the semantic purpose of them being in a list, in which case you wouldn’t want to remove the semantics of that with role="presentation"
  4. [backwardok] more info on role="presentation": http://w3c.github.io/aria-practices/#presentation_role
  5. zakim-robot
    @zakim-robot
    Jul 21 03:12
    [nschonni] Not sure about the whole "card carrying" thing, but kind of an interesting idea about TBI http://www.bbc.com/news/av/health-40662562/why-bar-staff-will-not-serve-afghanistan-veteran
  6. zakim-robot
    @zakim-robot
    Jul 21 05:49
    [gemma-stiles] Hi guys, I am after some input around keyboard interaction on a tab / tab-list component, I am reading through https://www.w3.org/TR/wai-aria-practices-1.1/#tabpanel but Tab: When focus moves into the tab list, places focus on the active tab element . When the tab list contains the focus, moves focus to the next element in the page tab sequence outside the tablist, which is typically either the first focusable element inside the tab panel or the tab panel itself. isn’t making much sense at the moment.
  7. Mallory
    @StommePoes
    Jul 21 09:16
    Hi Gemma
  8. it means that whole bunch of tabs (the tablist) is a single tab stop
  9. so you tab to it (even though your focus only actually lands on ONE of the tabs inside), and the next time you hit the tab key, you leave the tablist to whatever would be next in line
  10. this, because to move focus between the tabs inside the tablist, you switch to arrows
  11. and so for this pattern I see aria-selected="true" for the currently-focussed tab makes total sense, I just can't figure out how to do that in a grid (which does the same pattern) where I might end up with aria-selected="true" (because specs say all cells should be focusable/navigable so users can explore context) but also have elements who are also aria-disabled="true" (they are dates which cannot be selected for some reason).
  12. I might bring that confusion of the specs up with Matt King and the others who asked for responses from devs getting horribly confused with trying to implement stuff based on the spec
  13. @gemma-stiles does that make sense?
  14. Mallory
    @StommePoes
    Jul 21 14:21
    Still not sure if https://www.w3.org/TR/wai-aria/states_and_properties#aria-selected is saying I MUST use it when I'm managing focus or if it's just a Good Idea
  15. zakim-robot
    @zakim-robot
    Jul 21 17:03
    [ugi] @gemma-stiles In essence, the W3C doc is recommending an approach that is almost identical to how radio button groups operate. Instead of each tab, the whole tab panel receives focus, and the user makes a selection using arrow keys.
  16. zakim-robot
    @zakim-robot
    Jul 21 17:23
    [cameron] yay, nice Slack logo Marcy et al!
  17. Chris O'Brien
    @a11ycob
    Jul 21 19:35
    If menus containing a submenu automatically expand when they receive keyboard focus is that an acceptable outcome? Or does the user need to activate it first?
  18. zakim-robot
    @zakim-robot
    Jul 21 20:31
    [deconspray] I recently discovered that the typical screen reader text CSS class to hide content from being presented visually, but available for screen readers caused the row count of the table to be incorrect (by 1+ rows). It appears to be related to the position:absolute declaration in the class. Is anyone else experiencing this issue?
  19. zakim-robot
    @zakim-robot
    Jul 21 20:52
    [deconspray] ...looks like placing visuallyhidden class on span within caption resolves issue.