Archive index

A11y Slackers Gitter Channel Archive 19th of June 2017

What fresh hell is THIS now? - Patrick Lauke
  1. zakim-robot
    @zakim-robot
    Jun 19 03:32
    [car] Excellent a11ycast on Accessible Modal Dialogs by @robdodson!
    https://www.youtube.com/watch?v=JS68faEUduk
  2. zakim-robot
    @zakim-robot
    Jun 19 06:48
    [geekf] I was working on making dialog accessible and this was a helpful talk I must say.
  3. [geekf] But I have a few questions on it. All the usual examples use aria-hidden for background elements and I don't see how doing that is fundamentally different from using inert. I agree it's a better term but I think that's about it.
  4. [geekf] Also, I think it is bad to modify other elements when I have to make a small section accessible as modal. I believe aria-modal does exactly that and so I like it much more.
  5. James Teh
    @jcsteh
    Jun 19 06:51
    /notifications-announcements
  6. zakim-robot
    @zakim-robot
    Jun 19 06:53
    [geekf] The company I work for makes widgets for third-party website and so I am wary of adding any attribute on the parent site until and unless it is on a pre-determined tags/elements, like body tag or adding some meta tags.
  7. zakim-robot
    @zakim-robot
    Jun 19 07:11
    [dani-c] if you just set aria-hidden, i think you can still focus everything on the page. You still need to make those elements "inert" somehow. Correct me if i'm wrong please.
  8. [geekf] I think the tabbing still remains. So, yes it is a combination of setting tabindex -1 and aria-hidden to true to elements. That's what I think I saw in usual examples of dialog
  9. [geekf] The reason we have to set these attributes is because if a mobile user tries finding elements in discovery mode voiceover+safari even focuses the elements hidden behind the modal. I didn't see that behaviour in Talkback+Chrome
  10. zakim-robot
    @zakim-robot
    Jun 19 07:18
    [geekf] Note that the basis of what I am saying is my somewhat limited experience with accessibility focused development I have done. I could still be pretty wrong on it and would appreciate if someone corrects me :)
  11. zakim-robot
    @zakim-robot
    Jun 19 17:57
    [conley] Unfortunately no, I'm on Moto X w/vanilla android
  12. [conley] https://support.google.com/accessibility/android/answer/2633135?hl=en&ref_topic=3529932
  13. [conley] There are navigation settings that might be of interest
  14. zakim-robot
    @zakim-robot
    Jun 19 18:02
    [shavaughn] How well does talkback (Google's version) work with chrome from your experience? For me on the Samsung test devices, I can control granularity properly when the chrome UI has focus, but as soon as I enter the page area the granularity options get reduced and none of them actually do what they claim. :/
  15. [shavaughn] Thanks for the link, Conley. The stuff described there is what I'm expecting, but not what I'm seeing in practice.
  16. zakim-robot
    @zakim-robot
    Jun 19 18:17
    [conley] Np. In my experience it can be frustrating, I run into inconsistency as well
  17. zakim-robot
    @zakim-robot
    Jun 19 18:27
    [johnbhartley] One thing to consider is that you can determine which elements inside your modal have focus. Because of that you could look for the first and last focusable items and have them loop to each other. If on the last, tab is pressed, focus on the first. If on the first and shift+tab, the last would get focus. Where this gets tricky is on mobile as shift+tab does not work the same way. With the looping inside the modal, all you need is aria-hidden on the children of the body and you can't read back through. Because tabbing is locked in the modal, you won't be able to tab out. Make sense? I put together a codepen with those thoughts in mind https://codepen.io/johnbhartley/pen/EXWXrW?editors=0100
    I think the tabbing still remains. So, yes it is a combination of setting tabindex -1 and aria-hidden to true to elements. That's what I think I saw in usual examples of dialog
  18. zakim-robot
    @zakim-robot
    Jun 19 20:24
    [starla175] @shavaughn On my Samsung Galaxy S4 I can turn on TalkBack and then swipe down to change the read mode from default to characters, words, lines, paragraphs and finally pages. It may have changed in the newer phones, but this is how it works on mine. Also, you have to use Chrome, the default app called "internet" produces a lot of errors.
  19. zakim-robot
    @zakim-robot
    Jun 19 20:30

    [shavaughn] Thanks for the info @starla175. Are you able to do this whole the page content is selected, or while the chrome UI is selected.

    I'm using a galaxy S6 and one of the newer Samsung tablets. Both are running Android 7.0 with chrome. Maybe the behaviour has changed.

  20. zakim-robot
    @zakim-robot
    Jun 19 21:12
    [robdodson] @geekf you'll have to set tabindex=-1 on all interactive elements on the page. The better approach is probably to listen for when focus tries to leave the modal and direct it back to the first focusable element in the modal.
  21. [robdodson] inert gives you the ability to make an entire tree of elements non-focusable. In my opinion this is nicer than having to write your own javascript keyboard focus trap. You can just make <main> inert and then focus is naturally trapped in the modal. Very little js required
  22. [robdodson] inert will also set the element to aria-hidden. It removes it from the a11y tree
  23. [robdodson] i guess i should rephrase that to, inert is kind of like setting things to aria-hidden. It doesn't literally set aria-hidden but it does remove the element from the a11y tree, so the effect is the same.
  24. [johnbhartley] iirc if everything is inert, tabbing wouldn't stay in the modal and would wind up in the browser chrome, either going forward tabbing or backwards tabbing
  25. [robdodson] yes you can get out of the modal into the browser chrome, but then your next tab takes you back into the modal
  26. [robdodson] having said that, I don't think a user should be entirely trapped in the modal. that's a security risk IMO
  27. [robdodson] discussed more here: https://developers.google.com/web/updates/2017/03/dialogs-policy
  28. [johnbhartley] yeah, @scottohara was mentioning the same thing. if you (in general) are in charge of the site though, is it still a risk? would keyboard users/AT users be distrusting?
  29. [robdodson] i'm not sure about their trust level but I'd never want to force someone to take an action if all they want to do is close the tab. Even if it's my own site.
  30. zakim-robot
    @zakim-robot
    Jun 19 21:17
    [johnbhartley] and by closing the tab you mean from the browser chrome and not via an ESC or a modal close button
  31. [robdodson] yeah
  32. [robdodson] VoiceOver announces when the user is leaving the page so hopefully it's not a surprise that they're out of the document now
  33. [johnbhartley] true. well cool, thanks for the additional conversation around modals =D
  34. [garcialo] @robdodson Did you our jQuery plugin for trapping focus in the modal. It…might be linked to from the Modal MIND Pattern
  35. [garcialo] did you see* our
  36. [johnbhartley] that's where i had initially decided to trap it Overlay must confine TAB and SHIFT-TAB to it's focusable children.
  37. zakim-robot
    @zakim-robot
    Jun 19 21:23
    [robdodson] @garcialo I think i recall seeing that. I (secretly) wanted to show off inert cuz I want other browsers to get interested in it :)
  38. [garcialo] Ah yes, “Dialog” pattern, not Modal :p
  39. [garcialo] of course
  40. [garcialo] I think we’d agree with that :p
  41. [robdodson] yeah @johnbhartley I think the ARIA authoring practices guide also say to trap it. I was on board with that until I read that Chromium blog post. Now I'm like "hm.. yeah it would be bad if some ad or malware thingy trapped folks"
  42. [garcialo] But until inert becomes well supported…our plugins are quite useful for those using jQuery - https://ebay.gitbooks.io/mindpatterns/content/disclosure/dialog.html#useful-plugins
  43. [robdodson] fwiw the inert polyfill should work down to IE10
  44. [geekf] @robdodson While I understand how inert is better than the combo of aria-hidden and tabindex="-1", what I was saying is I consider aria-modal="true" as a better solution
  45. zakim-robot
    @zakim-robot
    Jun 19 21:28
    [geekf] Instead of setting inert to everything else why not declare everything apart from this child tree doesn't belong to the modal and request the browser to disable it.
  46. [johnbhartley] as of january aria-modal was only supported in iOS i believe
  47. [robdodson] @geekf I don't think aria-modal really does much today with assistive technology does it? I know the spec says it should have certain behaviors but that would break with how all other aria attributes work. Typically they don't affect behavior at all, they just add semantics
  48. [robdodson] @geekf To the point about setting everything to inert. I agree, inert is not the perfect tool for modal dialogs. We're working on a separate standard called blockingElements which specifically solve this case. But since inert has a polyfill and is behind a flag in Chrome, it may be here sooner and it can be used to achieve this effect.
  49. [robdodson] I wrote a blog post on this a while back to try and tease the two apart: http://robdodson.me/building-better-accessibility-primitives/
  50. [geekf] aria-modal works only on iOS and I am expecting support for it in other browsers but yeah I agree with your point that they should not alter the behaviour of browser as per the definition of aria tags.
  51. [robdodson] @geekf does it trap focus on iOS or just move focus into the modal?
  52. zakim-robot
    @zakim-robot
    Jun 19 21:35
    [geekf] It traps the focus in the modal and doesn't let the users go to other pages of the webpage. It still lets the user go to the browser's chrome.
  53. zakim-robot
    @zakim-robot
    Jun 19 21:41
    [geekf] The main reason I have to use aria-modal in iOS but don't miss it on Chrome is because in the discovery mode iOS also focuses elements which are hidden in the background of the modal. Chrome does a good job at that
  54. zakim-robot
    @zakim-robot
    Jun 19 21:59
    [robdodson] @geekf hm I'm not sure I quite follow your last point... Can you explain that a bit more?
  55. [geekf] When I move my finger on mobile to discover elements below it and if my modal dialog covers the complete screen I expect that it would only read the visible elements (visually, not display css property). Instead of doing this iOS also focuses elements which are hidden below the dialog.
  56. zakim-robot
    @zakim-robot
    Jun 19 22:05
    [geekf] Note that I am not disabling the elements hidden behind the dialog
  57. zakim-robot
    @zakim-robot
    Jun 19 22:11

    [marcysutton] In my inbox today:

    The most talkative member of your team last week was Scott O'Hara, with 94 messages. Nice work, Scott!

  58. [marcysutton] That was from Slack, for this team! shout-out to @scottohara! :)
  59. [marcysutton] About aria-modal...don't you still have to prevent focusing of interactive controls in the background somehow, with a tool like inert? The ARIA 1.1 spec calls this out: "When a modal element is displayed, authors should mark all other contents as inert (such as "inert subtrees" in HTML) if the ability to do so exists in the host language."
  60. zakim-robot
    @zakim-robot
    Jun 19 22:23
    [higley] Do you have a preferred inert polyfill? I want to use the Google one but I’m running into an issue when the inert element contains the last focusable elements on the page. I made a codepen, and if you try tabbing through it, you can see it still has tab stops for the elements in the hidden, inert modal: https://codepen.io/smhigley/pen/RVYMpE/
    fwiw the inert polyfill should work down to IE10
  61. [marcysutton] the WICG-inert one. I cover it in my modal dialog video too https://egghead.io/lessons/html-5-accessible-modal-dialogs
  62. [higley] Yeah, the WICG one works. I was kind of hoping for Google’s because I didn’t want to rely on mutation observers
  63. [higley] (Sorry, I meant to make the above threaded. Monday brain is in full force today :P)
  64. zakim-robot
    @zakim-robot
    Jun 19 22:36
    [garcialo] Do threads go through to the Gitter? Might be better to leave it unthreaded
  65. zakim-robot
    @zakim-robot
    Jun 19 22:43
    [marcysutton] Nope.
  66. Michael Ball
    @cycomachead
    Jun 19 22:48
    Hey all, are there some good references for doing custom focus rings? Part of the app I'm working on has a teal/blue color that has very poor contrast with most of the browser default colors. So far the WCAG doesn't seem to make anything more specific than "highly visible".