Archive index

A11y Slackers Gitter Channel Archive 9th of November 2015

What fresh hell is THIS now? - Patrick Lauke
  1. stevefaulkner
    07:30
    @StommePoes Desktop notifications not accessible: Not read by screen reader, and fade away https://bugzilla.mozilla.org/show_bug.cgi?id=1052776
  2. stevefaulkner
    07:31
    @StommePoes ignore, different issue, not reading clearly, morning eyes and brain
  3. StommePoes
    10:02
    @jitendra he could try via an accessible IRC client. I used pidgin to access this (although this is gitter and not straight slack)
  4. StommePoes
    10:02
    @MichielBijl so I've been playing with the toggle buttons and the tab panels
  5. StommePoes
    10:03
    I can't get anyone to anything with aria-expanded on the panels for the multi-opener, but I might have just built it wrong.
  6. StommePoes
    10:03
    Everything I've tested seems to rely on aria-selected to tell if a tab/panel combination is open and whether you can do anything to open it.
  7. StommePoes
    10:18
    Hm, I think the multi-tabpanel opener thing needs the tabs to act way different: toggle buttons maybe, where instead of focus, space and enter set them open/close.
  8. StommePoes
    10:19
    @stevefaulkner thanks for looking
  9. MichielBijl
    15:27
    @StommePoes aria-selected has nothing to do with tab/panel combination begin open.
  10. MichielBijl
    15:27
    @StommePoes your space/enter to open is correct.
  11. MichielBijl
    15:27
    Arrow keys should move focus.
  12. MichielBijl
    15:28
    (between the tab things)
  13. LjWatson
    15:29
    +1 to @MichielBijl aria-selected just indicates which tab has been selected. It doesn't invoke any action.
  14. StommePoes
    15:37
    But I am opening the panels on focus (for the exclusive panel)
  15. StommePoes
    15:38
    not hitting enter. But I think I would need to have to have enter/space for the multi.
  16. StommePoes
    15:39
    By aria-selected I meant if I moved to a tab where aria-selected wasn't true, I would hear that it could be activated. aria-expanded never announced anything
  17. zakim-robot
    18:35
    [heidi] hi. Is there an aria attribute to specify sub-navigation vs. main navigation item?
  18. garcialo
    18:36
    Like primary site navigation links and "this part of the site" navigation links?
  19. zakim-robot
    18:39
    [heidi] garcialo - i think so! like click on the “about” link and then about page has sub-nav within it for the about area.
  20. zakim-robot
    18:41
    [heidi] it is a sub list within main nav list, so would aria-level be meaningful in this context?
  21. zakim-robot
    18:42
    [heidi] http://www.w3.org/TR/wai-aria/states_and_properties#aria-level doesn’t mention navigation
  22. zakim-robot
    19:07
    [joe-watkins] @heidi: Leaning a pattern like <nav role="navigation"><ul>...</ul></nav> should do the trick. Less of a 'sub-nav' frame of mind and more of a 'major navigation block' approach.
  23. zakim-robot
    19:10
    [heidi] @joe-watkins: thanks! yeah i’m thinking the fact that it is its own <ul> within a main item's <li> is already relaying the semantic “this is a sub nav” info
  24. zakim-robot
    19:16
    [rodneyrehm] I have a table of contents in a <nav>. is it ok to put that in an <aside> with a bunch of other “possibly related” links?
  25. zakim-robot
    19:19
    [joe-watkins] @heidi: ahh yes.. I was picturing like a side column nav on an inner page dislocated from main nav.. :simple_smile: if you were really wanting to convey that information to AT you could lean on aria-label on the child <ul>
  26. zakim-robot
    19:21
    [heidi] @joe-watkins: yeah, i was wondering about that scenario as well! good old aria-label - agreed that’s prob the best in that context.
  27. zakim-robot
    19:22
    [joe-watkins] @heidi: great! have fun!
  28. zakim-robot
    19:23
    [heidi] @rodneyrehm: TOC sounds too important for an aside i think? <nav> makes sense tho.
  29. zakim-robot
    19:23
    [rodneyrehm] does a TOC need a special headline or something?
  30. zakim-robot
    19:24
    [heidi] @rodneyrehm: perhaps <details> ? check out http://html5doctor.com/the-details-and-summary-elements/ - there’s a TOC example there.
  31. zakim-robot
    19:25
    [heidi] not sure how you’re using it within the site
  32. zakim-robot
    19:26
    [heidi] you could also put it in the <header>
  33. zakim-robot
    19:28
    [rodneyrehm] the site nav is in the header…
  34. zakim-robot
    19:28
    [rodneyrehm] I’ll put it in <main>, it’s the only <nav> in there, so that’s probably fine
  35. zakim-robot
    19:30
    [heidi] @rodneyrehm: a heading tag would be good. i think your “related links” work as an <aside>
  36. zakim-robot
    19:35
    [rodneyrehm] ok, thx
  37. zakim-robot
    19:49
    [newtron] anybody have a link to a good description of why creating custom form elements is a terrible idea?
  38. zakim-robot
    19:53
    [dylanb] my favorite articulation of why http://www.heydonworks.com/article/reinventing-the-hyperlink
  39. zakim-robot
    19:53
    [dylanb] and form inputs are just a little bit more complicated than anchors
  40. zakim-robot
    19:54
    [newtron] awesome, thanks dylan
  41. zakim-robot
    20:02
    [dylanb] no, thank @heydon
  42. zakim-robot
    20:04
    [dylanb] but seriously, if, after sending that link to people, they still come back wanting more:...
  43. zakim-robot
    20:04
    [dylanb] a) Flip the bozo bit on them
  44. zakim-robot
    20:05
    [dylanb] b) ask them to enumerate all the "behavior" that a browser implements on the type of input they want to re-create...and then mock them when they forget half of it
  45. zakim-robot
    20:05
    [dylanb] :simple_smile:
  46. zakim-robot
    20:11
    [newtron] :smile: ya, that’s a really good piece @heydon :+1:
  47. zakim-robot
    20:11
    [newtron] i’m hoping this and http://www.karlgroves.com/2013/06/06/custom-ui-widget-accessibility-problems/ do the trck
  48. StommePoes
    21:05
    appeal to developers' laziness. Nobody wants to have to hand-build all that free browser goodness if they don't have to
  49. zakim-robot
    21:22
    [jdan] @dylanb @newtron how about for semantic elements that are inconsistent between browsers? like <input type=“file”> (and <button>s have some edge cases I think?)
  50. zakim-robot
    21:23
    [jdan] because with all the fun new component architectures on the web (and NPM of course), it’s pretty feasible to make a super accessible+reusable link/button/input out of divs
  51. zakim-robot
    21:24
    [jdan] (I still use <a>s, just playing devil’s advocate)
  52. zakim-robot
    21:25
    [jdan] though, reading the comments on @heydon’s post there are some good arguments to use semantics for SEO purpose and things like opening in a new tab (from the right click menu)
  53. zakim-robot
    21:35
    [dylanb] @jdan: there are some situations where it is a good idea and file upload might be one. The point is to make developers aware of all the stuff they no longer get for free so they can give whoever makes the cost-benefit trade off decision all the information on what the real cost is.
  54. zakim-robot
    21:41
    [jdan] :ok_hand: agreed. I really would love to hear why huge apps like gmail use <div>s though. (code-size? 100% control?)
  55. zakim-robot
    22:32
    [jdan] some big account RTd my question - lots of good responses! https://twitter.com/jdan/status/663835261948837888