Archive index

A11y Slackers Gitter Channel Archive 10th of October 2015

What fresh hell is THIS now? - Patrick Lauke
  1. MichielBijl
    13:32
    I'm working on a code example for the Authoring Practices Guide (APG), and have a question about name calculation. The APG states that the Alert must have a aria-labelledby referencing the alert title, if there is no visible title, you should use an aria-label. Next point is that you should have an aria-describedby referencing the body (content). Is there anyone here that could test this with anything other than VoiceOver? This is the plain html: http://codepen.io/Michiel/pen/0f9ce27964f35b55d3e7628d91874c2e.html, this is a live version: http://s.codepen.io/Michiel/debug/0f9ce27964f35b55d3e7628d91874c2e?
  2. MichielBijl
    13:34
    In VoiceOver it reads the aria-label, but not the description.
  3. MichielBijl
    13:34
    I'm not sure if I should trigger the description in VO in some way.
  4. stevefaulkner
    14:02

    The APG states that the Alert must have a aria-labelledby referencing the alert title

    do you mean dialog or alertdialiog?

  5. MichielBijl
    14:10
    alertdialog
  6. MichielBijl
    14:11
    • The Alert dialog has an aria-labelledby that references the title of the dialog. If there is not a visible title, use an appropriate aria-label instead.
    • The element with role alertdialog has an aria-describedby referring to the message element that has role document.
  7. MichielBijl
    14:11
    From: https://rawgit.com/w3c/aria/master/practices/aria-practices.html#alertdialog
  8. MichielBijl
    14:15
    role="alert" doesn't require anything in the form of aria-label or aria-labelledby
  9. stevefaulkner
    20:19
    @MichielBijl Right that's why I was confused by what you wrote 😀
  10. MichielBijl
    21:35
    Yeah, sorry :(
  11. MichielBijl
    21:36
    Now struggling to manage focus within the dialog
  12. MichielBijl
    21:36
    Someone here explained it to me a while back, but totally forgot to bookmark it.
  13. MichielBijl
    21:49
    Node.DOCUMENT_POSITION_CONTAINED_BY
  14. MichielBijl
    21:49
    That's the one!
  15. MichielBijl
    22:38
    Apparently you can just do element.contains(otherElement) :)
  16. MichielBijl
    22:45
    Is there anyway to list focusable nodes within another node?
  17. MichielBijl
    22:46
    Otherwise it would be very hard to set focus to the first/last focusable element within a dialog.
  18. MichielBijl
    22:46
    Depending on whether you use tab or shift+tab.
  19. MichielBijl
    22:50
    This states that there is no such list, but it's from 2011: http://stackoverflow.com/questions/7870544/simplest-way-to-tab-only-through-focusable-descendants-of-a-particular-element
  20. MichielBijl
    23:01
    So you can do something like this: 
    var focusableElements = dialogNode.querySelectorAll(':matches(input:not([disabled]), button:not([disabled]), a[href]), [tabindex="-1"], [tabindex="0"]');
  21. MichielBijl
    23:02
    This will return a non-live list with all inputs and buttons that are not disabled, anchors that have a href-attribute, and elements that have a tabindex of either '-1' or '0'. Not sure about speed impact of this.
  22. MichielBijl
    23:09
    So, I now have this to manage focus: 
    function manageFocus(event) {   var target = event.target;   var key = event.keyCode;   var insideDialog = alertDialog.contains(target);    // Only fire if focused element is not inside the dialog   if(!insideDialog) {     if(event.shiftKey && key === 9) {       // When shift + tab is pressed,       // set focus on last focusable element inside dialog       focusableElements[focusableElements.length - 1].focus();     } else if (key === 9) {       // If tab is pressed,       // set focus on first focusable element inside dialog       focusableElements[0].focus();     }   } }
  23. MichielBijl
    23:10
    It is triggered like this: document.addEventListener('keyup', manageFocus);
  24. MichielBijl
    23:11
    Problem is that for a split second focus is set outside of the dialog. And I'm not sure if that is a problem.
  25. MichielBijl
    23:13
    Another problem with this is that you cannot tab to something in the UI; you are really trapped inside the dialog.
  26. MichielBijl
    23:37
    I've added a check on whether the dialog is actually visible, seemed handy :P
  27. MichielBijl
    23:39
    Hmm, of course you have to actually remove a dialog for its children not to be focusable after you close it.
  28. MichielBijl
    23:41
    Oh no wait, that is me forgetting display: none doesn't work in animations 🙈