Archive index

A11y Slackers Gitter Channel Archive 5th of November 2015

What fresh hell is THIS now? - Patrick Lauke
  1. zakim-robot
    Nov 05 00:48
    [ldavis] @stevef: There appears to be more variables at work here. I need to study this problem some more.
  2. zakim-robot
    03:34
    [car] @ldavis: When you say "table layout", do you mean CSS table (i.e. display: table; display: table-row; display: table-cell;) or do you mean HTML table element (<table> <tr> <td>) ? I would guess that JAWS switches to <table> reading mode when in a <table>, and I would hope (?) that JAWS does not switch when in an element with display: table;.
  3. garcialo
    05:17
    He means an HTML table that is being used solely for layout and not tabular data. When you do that, you should use role="presentation " so the screen reader will ignore the native semantics. http://www.webaxe.org/layout-tables/
  4. zakim-robot
    14:12
    [callumacrae] If I have an aria-live attribute on an element with display: none, will it be read out when it becomes visible?
  5. powrsurg
    14:24
    Do you want it read out immediately?
  6. zakim-robot
    14:35
    [car] Thanks, @garcialo - good link. I didn't know about removing <caption>, <thead>, summary, title, aria-labelledby, aria-label, and aria-describedby before adding role="presentation" to <table> can work well with AT. Maybe one of those is causing @ldavis "layout <table>" to unexpectedly switch modes.
  7. zakim-robot
    14:57
    [callumacrae] @powrsurg: Yep. It's an error element
  8. cptvitamin
    15:03
    trying to establish some patterns here. When building a control that sends focus to a non-focusable element, is there a preference either way to add the tabindex=-1 to the target element at the time of click, or to have the tabindex=-1 always present on the target element? I’ve seen it done both ways and was wondering if there were pros/cons to either method.
  9. cptvitamin
    15:06
    for automated testing purposes, its easier to have it always present, because you can check for its value in the static page.
  10. cptvitamin
    15:07
    but adding it only at time of click prevents other code on the page from inadverntly sending focus to the wrong non-focusable element.
  11. cptvitamin
    15:07
    those are the only two things I can think of
  12. powrsurg
    15:17
    @callumacrae I would suggest adding role="alert" to the aria-live="assertive"
  13. zakim-robot
    15:18
    [callumacrae] done. thanks :simple_smile:
  14. cptvitamin
    15:27
    @callumacrae I would definitely do some testing. I’ve found that the most consistent results are achieved when the div with the aria-live attribute is always present and visible in the DOM and messages are added and removed with JS.'
  15. cptvitamin
    15:29
    some screen readers will not read the contents of the live region when the visibility of the live region itself is toggled.
  16. zakim-robot
    15:30
    [callumacrae] I'll do some testing
  17. zakim-robot
    15:50
    [cameron] hey folks, great article on CSS driving accessibility from ebay http://www.ebaytechblog.com/2015/11/04/how-our-css-framework-helps-enforce-accessibility/
  18. zakim-robot
    15:50
    [cameron] worth a read
  19. zakim-robot
    15:56
    [car] Does anyone know if ARIA attributes will ever be settable using JS "dot notation", i.e. element.role = "dialog"; ? Currently, you need to use element.setAttribute("role", "dialog"); even though there are lots of default ARIA roles in the HTML5 spec. It would be nice if "role", in particular, would be available/settable as a DOM node property. But I guess then we would need an "undefined" role for HTML Elements (therefore DOM nodes) that don't have a default role? I am just wondering, because last night I noticed 8 places (that's a lot!) in our code where well-meaning devs tried to set a role with element.role = "something", and the role was never set.
  20. zakim-robot
    16:04
    [ldavis] @car, @garcialo Thanks for your responses. I think the table was a red herring in my case. There is something else on this page that is triggering a mode change (JAWS). The table was only reacting differently with the mode changed, not the actually cause. I need to pick this page apart and investigate more closely then I will report back my findings. I'm hoping it is something trivial after all this confusion. :smile: Thanks!
  21. garcialo
    16:05
    np, good luck =)
  22. cptvitamin
    16:22
    @car there were discussions about this at the most recent ARIA face to face in Japan last week. There are currently 3 competing proposals to get something like this standardized. So, yes, it will likley happen some day, but it will take quite some time time before we start seeing implementations.
  23. zakim-robot
    16:23
    [car] Thanks, @cptvitamin!
  24. zakim-robot
    17:18
    [bkardell] Hey all, @ljwatson just published a piece on o'reilly http://radar.oreilly.com/2015/11/panels-and-panel-sets.html
  25. zakim-robot
    17:20
    [bkardell] I may be biased, but I like it :simple_smile:
  26. benpetersen
    17:41
    @zakim-robot Love the TDD idea for css selectors
  27. zakim-robot
    19:44
    [fstorr] Menus with "fly-outs" (such as the “categories” one on target’s site: http://www.target.com/): is there a spec on how focus should be managed and keyboard interaction? I like Target’s implementation but I’ve been asked if we should manage focus so that when a user tabs to the last element on an exposed submenu, their focus is bounced back to the first submenu item instead of the next link in the DOM. I can’t find a spec for this but that doesn’t mean that one doesn’t exist. Is anyone aware of one?
  28. zakim-robot
    19:48
    [fstorr] @cameron: what that article doesn’t mention is that Frankensteining a button together with spans, ARIA, JS, CSS, etc violates the first rule of ARIA use: http://www.w3.org/TR/aria-in-html/#first-rule-of-aria-use It’s odd because the author clearly knows their stuff but at no point says “just because you can do this, you should”.
  29. cptvitamin
    19:59
    @fstorr the WAI-ARIA Authoring practices guide covers some expected widget behaviors like that. http://www.w3.org/WAI/PF/aria-practices/ rule of thumb is to emulate desktop paradigms.
  30. cptvitamin
    20:00
    IMO you should trap keyboard focus inside of the flyout.
  31. cptvitamin
    20:04
    ESC would return focus to the parent/triggering element
  32. fstorr
    20:07
    @cptvitamin thanks. Emulating desktop behaviour is interesting here. If I take an Office app on OSX, hitting the tab and arrow keys move me through the top-level items (File, Edit, View, etc) . Using the down arrow opens a dropdown panel. Once I get to the bottom of that, I get stopped. But if I use the tab or arrow keys in a dropdown, it moves me to the next top-level menu item, which isn't standard behaviour for moving through a list of menu links on the web.
  33. cptvitamin
    20:10
    @fstorr it often depends on the context and complexity too. the target example is not like anything you would see in a desktop app. that is almost a modal dialog box, in which case you would trap focus within and cycle back to the top. it would be nice to include some landmarks that would indicate you have reached the end, like an explicit close button that closes the flyout and returns focus to the trigger
  34. cptvitamin
    20:11
    one of those things where its useful to do some user testing
  35. fstorr
    20:13
    @cptvitamin My menu structure is similar in that it has top-level categories and some "fly out" submenus, but the submenus are waaaaay less complicated. And, yes, we'll do user testing, but I'm trying to find a spec in conjunction with that.
  36. cptvitamin
    20:14
    @fstorr i would look through the aria-practices document then, it covers menu behaviors pretty well
  37. fstorr
    20:15
    @cptvitamin just doing that now. Fun lunchtime reading!
  38. cptvitamin
    20:15
    This message was deleted
  39. cptvitamin
    20:15
    :smile:
  40. fstorr
    20:25
    @cptvitamin Found what I need: http://www.w3.org/WAI/PF/aria-practices/#relations_haspopup_header and http://www.w3.org/WAI/PF/aria-practices/#popupmenu Trapped focus it is. Thanks again.
  41. zakim-robot
    21:01
    [astevens] Hi all. With http://www.w3.org/WAI/GL/wiki/Using_aria-describedby_for_link_purpose (examples 2 & 4) as a reference, I’m trying to get screenreader (JAWS 17) to acknowledge and enunciate additional descriptive text for links, yet only the actual link screen text is spoken, as if the aria-describedby tag isn’t even there…
    Checking the settings of JAWS and it appears to offer me choice for links of reading screen text, title, tooltip, longest of above, and so on— but definitely don’t want to have to muck w/ settings like that. I’d like the aria-describedby to be honored in this case as it is for my previous usages (on inputs and images). Thanks in advance for any feedback.
  42. zakim-robot
    21:43
    [cameron] @fstorr: thanks for the note. I did see a passage in that article that calls out what you’re talking about
  43. zakim-robot
    21:43
    [cameron] > So please, and I really can’t emphasize this strongly enough, do everybody a favor and always use an actual button element for buttons.