Archive index

A11y Slackers Gitter Channel Archive 24th of October 2016

What fresh hell is THIS now? - Patrick Lauke
  1. zakim-robot
    @zakim-robot
    Oct 24 12:50
    [lefthandev] @miwayha works as expected for me on desktop. However explore by touch isn’t available on mobile as the list of suggestions will disappear when focus leaves the search input.
  2. [lefthandev] @miwayha that is - when using VO.
  3. zakim-robot
    @zakim-robot
    Oct 24 14:03
    [miwayha] @lefthandev Thanks for having a look. So it must be a configuration problem within my own Safari? I also sometimes have a problem with alerts not reading full text when in Safari, though this doesn’t seem to be a problem on Chrome. Maybe I’ll ask for help at the Apple forums.
  4. zakim-robot
    @zakim-robot
    Oct 24 14:09
    [joe] Is anyone part of specific channels on here? I’m in Higher Ed at an Institution in Michigan. Are the regional channels, or Industry specific?
  5. [miwayha] @lefthandev and it also seems to work just fine on one of my macs but not the other, so it’s probably a safari configuration problem somewhere. Thanks!
  6. zakim-robot
    @zakim-robot
    Oct 24 14:17
    [lefthandev] @miwayha if you try resetting VoiceOver to its default settings, that usually does the trick
  7. zakim-robot
    @zakim-robot
    Oct 24 14:27
    [miwayha] @lefthandev thanks!
  8. zakim-robot
    @zakim-robot
    Oct 24 14:55
    [heidi] Best way to mark up a search results page? I typically suggest an ordered list, but notice google isn’t doing this anymore - using just headings. Thought I’d check in with ya’ll about it.
  9. powrsurg
    @powrsurg
    Oct 24 15:15
    Okay, I just upgraded from El Capitan to Sierra and VoiceOver now understands trees much better.
  10. zakim-robot
    @zakim-robot
    Oct 24 16:09
    [miwayha] @heidi we’ve had some pretty good accessibility consultants come in and advise us on best practices, and they simply recommended headings
  11. [heidi] @miwayha cheers - that makes sense. Good to get confirmation!
  12. James Nurthen
    @jnurthen
    Oct 24 17:39
    Anyone think it would be useful if screen readers presented the currently selected tab in the list of headers on a page? They often act as visual headers but cannot be marked up as such
  13. Aha
    @nerdfiles
    Oct 24 17:41
    Yes, and I think tabs of that sort should minimally have a subset of the "pagination UI" where [prev] and [next] are available through aria-labels but also hoverable. 
  14. [ tab1 ][ tab2 ] ... (on hover, reveal: <(first tab)><prev tab><next tab><last tab>) [ content      ]
  15. If the first tab is already presented, the menu on reveal should ignore the first tab.
  16. James Nurthen
    @jnurthen
    Oct 24 17:45
    I'm not sure i see the need for all of that... I think I'd need to see a demo to understand it
  17. Thierry Koblentz
    @thierryk
    Oct 24 17:45
    @jnurthen actually they can, and in my opinion they should be marked up as headings. Check Tab Panels, the right way
  18. James Nurthen
    @jnurthen
    Oct 24 17:46
    but if you add role=tab it is no longer a heading
  19. so it would no longer be in the list of headings (or at least it shouldn't be if screen readers were following the spec)
  20. Thierry Koblentz
    @thierryk
    Oct 24 17:48
    Read the article. It's about starting with the right markup and complaining that we "have to" transform that for screen-readers (into a Tab Panel) even though it's a simpler mental model.
  21. James Nurthen
    @jnurthen
    Oct 24 17:48
    and you can't put a heading as a child of the tab as tab can only have presentational children
  22. Thierry Koblentz
    @thierryk
    Oct 24 17:50
    The gain is mostly for SR users who turn off JS ;)
  23. James Nurthen
    @jnurthen
    Oct 24 17:51
    I'd prefer to target SR users who use JS myself
  24. I really don't like the tab model on that where it bounces back up to the tabs after the content of the panel
  25. Thierry Koblentz
    @thierryk
    Oct 24 17:52
    Interesting, because that's the way most keyboard users prefer
  26. leaving the widget by tabbing through a panel makes little sense
  27. James Nurthen
    @jnurthen
    Oct 24 17:53
    I disagree for many many applications I work on.
  28. Thierry Koblentz
    @thierryk
    Oct 24 17:53
    because other tabs are part of the widget and should be reachable
  29. You may disagree but it seems to be the result of some research
  30. James Nurthen
    @jnurthen
    Oct 24 17:53
    they are reachable by the arrow keys so the user can select the correct tab first.
  31. it is very app dependent
  32. Thierry Koblentz
    @thierryk
    Oct 24 17:54
    many keyboard users don't know they can use the arrow key
  33. James Nurthen
    @jnurthen
    Oct 24 17:54
    Many of this research looks at web pages not web appications
  34. Thierry Koblentz
    @thierryk
    Oct 24 17:54
    we're talking about users in general, not just SR users
  35. James Nurthen
    @jnurthen
    Oct 24 17:54
    IMO they are 2 different things... web pages frequently should not use tab pages at all
  36. Thierry Koblentz
    @thierryk
    Oct 24 17:54
    a11y is not about SR
  37. James Nurthen
    @jnurthen
    Oct 24 17:55
    totally agree
  38. I don't want my keyboard users to have to tab through too many tabs to get to the content
  39. I want efficient keyboard access and not just rely on the tab key all the time
  40. Thierry Koblentz
    @thierryk
    Oct 24 17:56
    and to be clear, I think it's stupid to present a succession oh headings/divs to SR users when the basic underlying markup suffices
  41. check the example I have there. The escape key lets users leave the widget or go back to the first tab whenever they choose
  42. and yes, users can also use the arrow keys if they want
  43. I'd call these different way to navigate the widget "efficient"
  44. James Nurthen
    @jnurthen
    Oct 24 17:59
    some of those are nice... I just don't agree with bouncing back up to the top after going through a panel I know I would field a lot of customer complaints about that behaviour
  45. Aha
    @nerdfiles
    Oct 24 17:59 
             [ << < > >> ] /visibility: hidden/             \/ [ tab1* ] [ tab2 ] [ content ] [ first, previous, next, last ]
    Reads: Tab1 [content], Tab2 [content] ... [first tab] [previous tab] [next tab] [last tab]
    So now the user can search while oriented from whatever presented tab they are on:
    1. Search for /Prev/ while on Tab 3* — in one action I can use Ctrl + F to jump from Tab 3 to Tab 2 without even really knowing the full breadth of all the tabs. So below the critical landing viewpoint I can use my Browser Search to orient me to what is essentiallya sub-nav for my tabbed content.
  46. Just a thought; maybe way off. But it immediately sprung to mind as I saw your Q.
  47. It's basically a pagination with no numerical count in the middle.
  48. The crux is that for visible users, the hoverable nav maps to visual prev next while the core nav maps only to the active tab at the moment.
  49. Thierry Koblentz
    @thierryk
    Oct 24 18:04
    you do not bounce back up to the top. You have the choice to do that to avoid back pedaling to the 1st tab or you can simply tab through the "skip link" and reach the next focusable element after the widget
  50. oh you mean back to a tab, not to the top of the panel
  51. but that's considered best practice for most keyboard users
  52. for the reason we have discussed - not every keyboard users know they can navigate the tabs via arrow keys
  53. James Nurthen
    @jnurthen
    Oct 24 18:07
    Any keyboard user who has used a desktop application should know that
  54. again - i'm talking web applications here not generic web pages.
  55. zakim-robot
    @zakim-robot
    Oct 24 18:09

    [stefanjudis] Hey folks I wrote a short article on the proper use of aria-selected. Feedback very welcome. :)

    https://www.stefanjudis.de/aria-selected-and-when-to-use-it.html

  56. Aha
    @nerdfiles
    Oct 24 18:09

    Then your header included in the page can immediately show: Header [prev next, etc.] so that when people perceive the header it can be implied that it is a "special tab header" because subsequent to it it will have a nav as well which would give the user a hook to funnel directly into the "fork in the headers" that takes the user to the most relevant tab to them.

    So
    Header 1
    ....
    Header 2
    ....
    Special Tabbed Header 3
    First Prev Next Last
    Header 3
    .... Bullet ....
    .... Bullet ....

  57. James Nurthen
    @jnurthen
    Oct 24 18:11
    @stefanjudis you may want to point out that aria 1.1 introduces aria-current for exactly the situation listed
  58. https://www.w3.org/TR/wai-aria-1.1/#aria-current
  59. zakim-robot
    @zakim-robot
    Oct 24 18:56
    [stefanjudis] oh nice... thanks. I'll check that out
  60. zakim-robot
    @zakim-robot
    Oct 24 19:55
    [skerrvy] Canada’s new "minister of sport and persons with disabilities" is currently travelling the country consulting with Canadians on creating a new federal accessibility legislation.
  61. [skerrvy] http://www.cbc.ca/radio/thecurrent/a-special-edition-of-the-current-focused-on-disability-for-october-21-2016-1.3814141/minister-carla-qualtrough-says-canada-s-new-disability-act-will-make-history-1.3814165
  62. powrsurg
    @powrsurg
    Oct 24 20:12
    So I just spent the last few days testing my co-workers new treeview and things that interacted with it. Told him it was all good. Just did a final review and found he had a ton of <a tabindex="0" title="blah" aria-label="blah">Edit</a> and click handlers that would take you to places based on code. You can keyboard to it, but it doesn't fire the click handler because of that. I feel like an idiot for not catching that work ...