Archive index

A11y Slackers Gitter Channel Archive 23rd of October 2015

What fresh hell is THIS now? - Patrick Lauke
  1. MichielBijl
    08:05
    @garcialo this is what I use: 
    <div role="progressbar" aria-busy="true" aria-label="Loading the page"></div>
  2. MichielBijl
    08:05
    Example here: http://codepen.io/Michiel/pen/xiKfC?editors=100
  3. MichielBijl
    08:06
    And for screen reader users, here is a direct link to the html: http://s.codepen.io/Michiel/debug/xiKfC
  4. stevefaulkner
    13:21
    This message was deleted
  5. stevefaulkner
    13:24

    :point_up: October 22, 2015 9:51 PM

    @deborahgu I belive that the progressbar role is used for native loading type widgets

  6. MichielBijl
    14:02
    @stevefaulkner @deborahgu: The spec states: “The author should supply values for aria-valuenow, aria-valuemin, and aria-valuemax, unless the value is indeterminate”
  7. MichielBijl
    14:02
    So it is not required.
  8. MichielBijl
    14:04
    My implementation is incorrect in that it sets aria-busy on the progress bar instead of the region it is loading.
  9. zakim-robot
    14:04
    [Joe Watkins, a11y] @jiatyan Sounds like you have it wired up well :simple_smile: I'd stray from assuming what is a pain for the AT user as they can get around very well in interfaces that are coded well.
  10. zakim-robot
    14:32

    [Joe Watkins, a11y] @jiatyan Modals can be tough for non-AT users. Consider the flow of a sighted user in the pattern and push to provide that same experience opportunity for the AT user.

    Sighted user flow: Sighted user visually focusses on next button and clicks it, new image appears, user moves visual focus to image, takes in visual information and reads caption, user sends visual focus back to next button.

    Giving the AT user this same opportunity is the goal. AT user focusses on next button and clicks it, new image appears, user moves focus to image, takes in ALT information and is fed caption, user moves focus back to next button.

  11. MichielBijl
    14:39
    @Joe Watkins: you can just move focus for them right?
  12. zakim-robot
    14:48
    [Cameron Cundiff, a11y] having fun with Voiceover and emoji right now
  13. zakim-robot
    14:52
    [Cameron Cundiff, a11y] voiceover’s visual captions panel renders the emoji in image form, but announces it as text
  14. zakim-robot
    14:52
    [Cameron Cundiff, a11y] seems kinda goofy to me
  15. zakim-robot
    14:54
    [Cameron Cundiff, a11y] also, Voiceover doesn’t announce that the character is emoji, it simply announces "grinning face with normal eyes” for example
  16. zakim-robot
    14:54
    [Cameron Cundiff, a11y] curious if that is surprising to people using screenreaders
  17. zakim-robot
    14:57
    [Cameron Cundiff, a11y] Screenshot of list of emoji icons and characters with voiceover visuals panel overlay, showing a rendered emoji
  18. zakim-robot
    15:02
    [Carolyn MacLeod, a11y] @jiatyan @joe-watkins: Can the photo area receive typed arrow keys when it has focus? If not, then maybe this a situation where role="application" might be helpful on the photo area? That is, if you want users to be able to navigate through photos by just typing arrow keys. I don't know... just asking.
  19. zakim-robot
    15:30
    [Carolyn MacLeod, a11y] @cordelia: I haven't tried this custom select, but Heydon talks about it in his "Apps For All" book:
    http://www.456bereastreet.com/archive/201111/an_accessible_keyboard_friendly_custom_select_menu/
  20. zakim-robot
    15:31
    [Carolyn MacLeod, a11y] Hey @heydon, I bought a copy of your book... have a beer - on me! :)
  21. zakim-robot
    15:39
    [Jiatyan Chen, a11y] @joe-watkins @car @michiel : Thanks for walking me through the workflow of the sighted user. That makes me think that perhaps we can match that workflow with a live region on the photo frame. Ideally, yes, would live the SR to just read the alt-text as they arrow-key through the the photos.
  22. zakim-robot
    16:03
    [Joe Watkins, a11y] @MichielBijl yes sending focus is an option for sure :simple_smile:
    @car tying the next/prev button functionality to the keyboard would be super handy.
    @jiatyan It's a tough one because you have basically two challenging patterns in one... a carousel/slider in a modal. I haven't tested this but it looks promising in the carousel department: http://kenwheeler.github.io/slick/
  23. zakim-robot
    16:04
    [Jiatyan Chen, a11y] @joe-watkins: Thanks, I'll have my developer investigate this. :simple_smile:
  24. zakim-robot
    17:57
    [David Newton, a11y] does anybody know how header levels should operate across iframes?
    e.g. if i have nav, site title, breadcrumbs in the parent frame with the title in an h1, and all the content is in the iframe, should the iframe’s first heading (the title of the page) be an h2 or another h1?
  25. powrsurg
    18:43
    Are the keyboard commands for using with tabs as listed on http://oaa-accessibility.org/example/34/ still recommended? Given the way Firefox and Chrome act I wondered if the page up and page down are still recommended
  26. powrsurg
    18:44
    also I wasn't sure if the "If focus is on an element in a tab panel" section means the tabs should be activated as well.
  27. powrsurg
    18:45
    I think not based on the way the page functions, but I wasn't reading it as such
  28. powrsurg
    18:45
    the fact that the DHTML Style Guide Working Group doesn't exist anymore (or the link is dead) and that is such an old name I wondered how outdated things were
  29. powrsurg
    18:46
    I wasn't aware that anything ARIA related was even around when people were still using the phrase DHTML
  30. zakim-robot
    18:46
    [Cordelia McGee-Tubb, a11y] For tabs, I’ve only been doing arrow key support. I didn’t implement page up/page down because of the different browser handling.
  31. powrsurg
    18:48
    I was kinda surprised to see the ctrl + up/left. It seems more natural for that to be ctrl+home
  32. zakim-robot
    18:52
    [Cordelia McGee-Tubb, a11y] Even the Aria Best Practices guide has some misgivings about Ctrl+Up: “This is not standard behavior - is this something we want to implement? Is it necessary if we provide a mechanism to change the active tab?” http://www.w3.org/TR/wai-aria-practices-1.1/#tabpanel
  33. powrsurg
    18:55
    Okay, ctrl+left doesn't seem to be recommended anymore. I guess I'll take that out
  34. powrsurg
    18:55
    also, I am so confused about when to use aria-hidden vs aria-expanded. The way that page is structured I feel it should be aria-expanded
  35. zakim-robot
    18:57
    [Cordelia McGee-Tubb, a11y] I’m confused about why you even need to use aria-hidden in that context. It’s being applied to elements that have style=“display:none”, so they should already be hidden from the accessibility tree, no?
  36. zakim-robot
    19:00
    [Cordelia McGee-Tubb, a11y] I don’t think aria-hidden is necessary for that example. It would be if you are visually hiding the non-selected tab panels with something other than display: none.
  37. powrsurg
    19:55
    when should aria-expanded ever get used?
  38. powrsurg
    19:56
    my understanding for aria-hidden was to ensure something was not read by screen readers, though it appear visually
  39. powrsurg
    19:57
    and aria-expanded to be used whenever you show/hide content (like when changing display)
  40. stevefaulkner
    20:09
    @powrsurg aria-expanded is commonly used on controls that control the display of other elements such as disclosure widgets
  41. stevefaulkner
    20:10
    When the control recieves focus screen readers will generally announce the state expanded or collapsed
  42. stevefaulkner
    20:14
    example http://codepen.io/stevef/pen/jiCBE
  43. zakim-robot
    20:18
    [Cordelia McGee-Tubb, a11y] (correct me if I’m wrong, steve) In the tab context, it seems like aria-expanded should only be used when multiple tabs can be open at the same time, as in an accordion: http://oaa-accessibility.org/example/37/ … In a standard set of tabs where only one tab is displayed at a time, you don’t need to use aria-expanded.
  44. garcialo
    20:26
    Why would there need to multiple things that can be expanded? What if you have a button that toggles whether one thing is displayed or not.
  45. garcialo
    20:27
    That was in response to @cordelia, btw. Also I haven't read everything.
  46. zakim-robot
    20:28
    [Cordelia McGee-Tubb, a11y] Oh, garcialo, I’m just talking specifically about the tablist context.
  47. garcialo
    20:28
    Ah, okay then.
  48. zakim-robot
    20:29
    [Cordelia McGee-Tubb, a11y] A simple tablist where there’s always one - and only one tab - selected doesn’t need aria-expanded, IMO.
  49. powrsurg
    20:34
    @stevefaulkner that seems to go against http://oaa-accessibility.org/example/20/
  50. stevefaulkner
    21:53
    @cordelia yeah I wouldn't use on tabs
  51. stevefaulkner
    21:56
    @powrsurg yeah I think that Oaap is a poor example of aria-expanded mainly because aria-expanded make sense when on an actionable control as the state information will be conveyed
  52. stevefaulkner
    21:58
    @codelia accordions (to me) are more like chained disclosure widgets than tabs
  53. stevefaulkner
    22:00
    FYI @cordelia @powrsurg I chimed in response to @powrsurg without reading backlog so missed the context 😜