Archive index

A11y Slackers Gitter Channel Archive 28th of August 2015

What fresh hell is THIS now? - Patrick Lauke
  1. zakim-robot
    01:16
    [Michael Lockrey, a11y] I have been unable to publish a caption track on YouTube for the past 12 hours
  2. zakim-robot
    01:17
    [Michael Lockrey, a11y] Is anyone else having trouble with YouTube and publishing captions?
  3. zakim-robot
    01:17
    [Michael Lockrey, a11y] It doesn't seem to matter if I upload a transcript and try to sync it or upload a completed caption file
  4. zakim-robot
    01:18
    [Michael Lockrey, a11y] Just gets stuck on publishing stage of the workflow
  5. zakim-robot
    01:18
    [Michael Lockrey, a11y] If there's anyone here from YouTube please help ASAP
  6. zakim-robot
    01:20
    [Michael Lockrey, a11y] Here's a screenshot:
  7. zakim-robot
    01:22
    [Michael Lockrey, a11y] Slack for iOS Upload
  8. zakim-robot
    04:12
    [Marcy Sutton, a11y] It does look like the controls are missing from the player, huh? And the captions never seem to populate?
  9. zakim-robot
    04:14
    [jitendra, a11y] Is <b> tag deprecated in HTML 5?
  10. zakim-robot
    04:39
    [Michael Lockrey, a11y] @marcysutton Just been advised by Media Access Australia that there's been issues for the last 36 hours or so
  11. zakim-robot
    04:40
    [Michael Lockrey, a11y] Let's hope it's rectified sooner rather than later as there's already plenty of uncaptioned content out there
  12. zakim-robot
    05:58
    [Michael Lockrey, a11y] You can check out the number of YouTube videos with captions published on or after 27 Aug 2015 here:
  13. StommePoes @StommePoes waves at @Michael Lockrey
  14. zakim-robot
    05:58
    [Michael Lockrey, a11y] nomorecraptions.com/beta/search.html
  15. StommePoes
    05:59
    @stevefaulkner re invalid/required states, I didn't write that code, that's added by the javascript of the email/newletter provider system.
  16. StommePoes
    06:01
    @jitendra they didn't deprecate <b>, but they did change what it "means". I still use it as just a sandbag for CSS :)
  17. StommePoes
    09:00
    Question
  18. StommePoes
    09:00
    http://dev.w3.org/html5/alt-techniques/#hao I'm unsure which part is the "willfull violation of HTML"
  19. StommePoes
    09:00
    <div class="aspectRatioPlaceholder is-locked" style="max-width: 400px; max-height: 397px;">
  20. StommePoes
    09:00
    <div class="aspect-ratio-fill" style="padding-bottom: 99.3%;"></div>
  21. StommePoes
    09:00
    </div>
  22. StommePoes
    09:00
    <img class="graf-image" data-image-id="1*MUEFB9g7B3EHNJxwNmlV5g.jpeg" data-width="400" data-height="397" src="https://cdn-images-2.medium.com/max/800/1*MUEFB9g7B3EHNJxwNmlV5g.jpeg">
  23. StommePoes
    09:01
    I've just come across this, and I can't see why this image should get away with not having an alt (there is also, not posted, a figcaption with a caption talking about the page topic, but not providing a true alternative description of the image)
  24. StommePoes
    09:06
    but then the question is, at least an empty alt="" to improve usability? (or let everyone's default verbosity levels read out that horrid, terrible, useless src url?)
  25. StommePoes
    09:08
    Although I believe on medium the writers do choose the images themselves... I'm not sure if they can access the alt attribute but I would say this author would have known good alt text.
  26. StommePoes
    09:08
    The example on the alt-techniques page shows a graph, which I would think also can't fall under the "author doesn't know at time of posting"
  27. StommePoes
    09:08
    it is true that the example follows that HTML5 page though: there is a non-empty figcaption and no other text in the box
  28. StommePoes
    09:09
    But it's a caption, which doesn't satisfy alternative image text (and here I'd say the image is used as a visual illustration of the caption's point, but only if you know what's in the image)
  29. MichielBijl
    09:21
    Question: how do you lock focus within a modal?
  30. MichielBijl
    09:21
    dialog*
  31. StommePoes
    09:21
    you mean, trap keyboard?
  32. StommePoes
    09:21
    or where to move focus to?
  33. MichielBijl
    09:22
    Uhm, pressing tab
  34. MichielBijl
    09:22
    So yeah, keyboard :)
  35. StommePoes
    09:22
    but do you mean, when it opens? or after someone's already inside?
  36. StommePoes
    09:23
    When they're already inside, I've tried javascripts that checked for the e.target's ancestors and cancelled if they didn't match the modal, but that was not consistent cross-browser (or I did it wrong), so I add a manual <a href="#" class="trap"></a>
  37. StommePoes
    09:23
    and then with javascript move focus to the close button usually
  38. MichielBijl
    09:24
    It's a dialog that is open by the default—sign, I know—and gives you two opens (download some shitty pdf or continue to the site).
  39. MichielBijl
    09:24
    Checking ancestor is not a bad idea
  40. StommePoes
    09:25
    I had something like this, on a modal that sometimes opens onload and sometimes opens after click (depending):
  41. StommePoes
    09:25
                    $form_html.find('.button-close').focus();                   
    
  42. StommePoes
    09:25
                    event.stopPropagation();                                    
    
  43. StommePoes
    09:25
    $('.container').on('focusin',function() {
  44. StommePoes
    09:25
                }                                                               
    
  45. StommePoes
    09:25
            });
    
  46. StommePoes
    09:25
                if (!$(event.target).is('#ajax_lightbox')) {                    
    
  47. Heydon
    09:26
    On blur, just refocus an appropriate part of the modal
  48. StommePoes
    09:26
    well not just so
  49. Heydon
    09:26
    *dialog
  50. StommePoes
    09:26
    On blur you have to listen for the shift key
  51. StommePoes
    09:27
    because I should be able to go backwards until the first focusable without focus going anywhere weird too.
  52. Heydon
    09:27
    True. So, on blur of last focusable item, refocus the first.
  53. Heydon
    09:28
    So you can cycle through.
  54. StommePoes
    09:28
    I think ideally you'd want focus to circle around though: if you shift-tab from the first focusable, you should end up at the last focusable in the modal etc
  55. StommePoes
    09:28
    yeah
  56. StommePoes
    09:28
    endless cycle of modal pain and terror
  57. Heydon
    09:28
    FTW
  58. Heydon
    09:28
    :-D
  59. StommePoes
    09:28
    UNLIKE FOR EXAMPLE THE MODAL ON 9292.NL
  60. StommePoes
    09:29
    which blocks your view of the page but lets you TAB BLINDLY UNTIL YOU DIE
  61. Heydon
    09:29
    In my practical ARIA examples version, you can shift tab out of the modal up to the browser chrome
  62. StommePoes
    09:29
    I should be able to ctrl-L or whatever to chrome whenever, but that sounds useful if you had to take those from me for some reason
  63. Heydon
    09:30
    True, that should still work as well.
  64. rodneyrehm
    09:32
    truly trapping focus within an element is “slightly” more complicated than simply listening for tab/shift-tab. mostly because that’s not the only way to move focus
  65. StommePoes
    09:32
    hm all I see in your code is listening for tabbing from the last focusable
  66. StommePoes
    09:33
    it's not, but it's the most common way one accidentally moved focus
  67. StommePoes
    09:33
    oh heydon I see it's due to the rest of the page being mod-hidden huh
  68. StommePoes
    09:34
    I guess removing the focusability of ALL THE THINGS except your thing works
  69. StommePoes
    09:34
    no different that a page which simply indeed only has the modal as content.
  70. StommePoes
    09:35
    s/that/than
  71. rodneyrehm
    09:35
    I have some (outdated) examples for trapping focus: http://medialize.github.io/ally.js/examples/trap-focus.html and not having to trap focus by disabling focus of elements that are currently deemed inert: http://medialize.github.io/ally.js/examples/disable-focus.html
  72. StommePoes
    09:35
    Yeah heydon does similar to the last one in his example
  73. StommePoes
    09:36
    one thing I have regular trouble with is the fact that once I take over focus, I can't "give it back"
  74. rodneyrehm
    09:36
    what do you mean by that?
  75. StommePoes
    09:36
    So for example in mega dropdown menus, I'm listening to the keyboard but when the user's at the end (or beginning) of the menu, the next tab or shift-tab I'd like to just let the browser do what it normally does
  76. Heydon
    09:36
    I cheat by setting the the page outside the dialog to visibility:hidden, meaning nothing in that tree can be focused. Much easier than finding all the individual focusable elements.
  77. StommePoes
    09:37
    in other words, if i'm managing focus like "don't go to next focusable within the menu, but do x instead", I have trouble saying "except when we're at the beginning and there's shift, or we're at the end and there's no shift"
  78. StommePoes
    09:37
    Heydon yeah, that's something I should try next time
  79. Heydon
    09:39
    Only problem is, the page elements have to disappear, so no nice subtle faded overlay thingyWHATEVER I DON'T CARE
  80. StommePoes
    09:40
    make the modal cover ALL THE THINGS and the visual part of the modal is actually the child
  81. StommePoes
    09:40
    <div le modal><div>all the stuff you see, centered to its parent le modal</div></div>
  82. StommePoes
    09:41
    as in, the "outside" of the modal does the job of the usual overlay junk
  83. rodneyrehm
    09:41
    yeah, hiding the irrelevant content would be best, but can’t always be applied that way.
  84. rodneyrehm
    09:43
    @StommePoes I don’t understand your problem with “not handling keyboard”? simply don't call event.preventDefault() unless you’re actually doing things yourself
  85. StommePoes
    09:43
    I'm looking at my dropdown code to remember where my issue was
  86. StommePoes
    09:43
    so actually going backwards was never an issue, but forwards, there are focusables between the "last" item and the rest-of-page.
  87. StommePoes
    09:43
    What I have is a menu where you can tab across the main items, and the submenus show when the main items are in focus
  88. StommePoes
    09:44
    you have to switch to something else (in this case, arrows) to cycle around the submenus
  89. StommePoes
    09:44
    but if you're on the last main item, and you want to leave, the next tab should take you out
  90. StommePoes
    09:44
    kinda similar to tab-panels where the last showing panel might have focusables
  91. rodneyrehm
    09:44
    ah, understood
  92. StommePoes
    09:44
    so looks like what I'm currently doing is, on page load, looking to see who's the next focusable after the menu
  93. StommePoes
    09:45
    and now that my newer shops detect that automatically, I no longer have the problem I created where I looked for menu's nextSibling's 'a' (because sometimes it's not an a, or not in the sibling, or whatever)
  94. StommePoes
    09:46
    Even though we're using jQuery, the :tabbables was waaay too expensive to use. Some pages we have have like gazillions of tabbables
  95. rodneyrehm
    09:46
    @StommePoes you remember this table, right? http://rodneyrehm.de/t/data-tables/focusable.html
  96. StommePoes
    09:46
    yeah
  97. StommePoes
    09:47
    wow
  98. rodneyrehm
    09:47
  99. rodneyrehm
    09:47
    that’s how much jQueryUI’s :focusable and :tabbable get wrong
  100. StommePoes
    09:47
    oh I believe it
  101. StommePoes
    09:47
    the uber-slow loading time wasn't the only problems I ran into while trying to test it
  102. StommePoes
    09:47
    and then the other developer wanted to add lazy-load
  103. StommePoes
    09:47
    that made it even worse
  104. rodneyrehm
    09:48
    and while you’re looking at the first table, please comment on the footnotes in the cells. right now they#re only links to the bottom of the document, but I think I want to display them on hover
  105. StommePoes
    09:49
    it ended up being better to start from the menu and look around from there. This also fixed the issue where sometimes new focusables would appear after the menu and before the usual focusable due to people logging in or changing status
  106. StommePoes
    09:49
    (having a separate function who was smarter than nextSibling find 'a')
  107. rodneyrehm
    09:50
    do you have that code online somewhere? I don’t understand why you need to know the menu’s surrounding at all
  108. rodneyrehm
    09:50
    (considering you have all the focusable menu items at hand, and can judge from there)
  109. StommePoes
    09:50
    is 12.10240 some version of edge or is it something else? (IE)
  110. rodneyrehm
    09:50
    -judge + decide
  111. StommePoes
    09:51
    lemme see if someone's using the latest version
  112. rodneyrehm
    09:51
    that’s the current edge preview on regular IE10, yes
  113. StommePoes
    09:53
    http://www.paardekooper.nl/ although it's still got its own specific focusable checker
  114. StommePoes
    09:54
    the file is in the paardekooper folder and called javascripts2.js (which has everything, jquery etc), so our own code is nearer the bottom. The onload listening stuff is inside the ($function() bit and the other, called functions are after it.
  115. StommePoes
    09:55
    The onload part of the menu is after // menu focus
  116. StommePoes
    09:55
    the called-after functions are //keyboardable menu though it calls the find_focusable which comes before it.
  117. StommePoes
    09:56
    the code also looks for some sub-sub menu items which actually this shop doesn't have, nor does it have much in the submenu of the last item (only one item).
  118. StommePoes
    09:57
    But the slider thingie after the menu, that's placed there by the client, not us, via a CMS. So I cannot know what they may add in there.
  119. rodneyrehm
    09:57
    hm, looking at minified code is… urgh
  120. StommePoes
    09:57
    hm, that's jquery
  121. StommePoes
    09:57
    skip it
  122. StommePoes
    09:57
    further down it's not minified
  123. rodneyrehm
    09:58
    ok, I don’t think you need to know the next focusable
  124. StommePoes
    09:58
    I'm not able to throw all the minified jq, plugins, etc at the bottom of the page because the other developer randomly adds scripts expecting jquery in the templates, and we don't use anything like require.js
  125. StommePoes
    09:59
    if you're focussed on "Specials", the normal next focusable is the submenu's "specials", instead of the whatever that comes next
  126. StommePoes
    09:59
    way back in an earlier iteration of this menu, when you got to the last main item you had to then tab through the submenu items, because when their parent isn't display: none anymore, they become the next natural focusables.
  127. StommePoes
    10:00
    And I lived with that for a while until we had a client who had super-huge-nasty submenus
  128. StommePoes
    10:00
    bigger than my page, and ug, attached to a fixed header so I couldn't scroll the suckers either
  129. StommePoes
    10:00
    But if you know a nice shortcut where I can dump a bunch of code, yay!
  130. rodneyrehm
    10:01
    the “trick" is to hide the sub-menu on TAB when the last menu item has focus.
  131. StommePoes
    10:01
    You mean, they first tab to it, the submenu shows, and when they hit tab again, it interrupts the tab, hides the submenu, and then... how to tell it to continue?
  132. rodneyrehm
    10:02
    that way the browser will not consider the sub-menu’s items as focusable anymore once it actually runs the “focus next item in tabbing order"
  133. rodneyrehm
    10:02
    you don’t need to tell it to continue, you just need to NOT tell it to abort
  134. StommePoes
    10:02
    ah like, if last menu item, don't run all this other code
  135. StommePoes
    10:02
    unless they hit arrows because they do want to explore the submenu?
  136. StommePoes
    10:03
    (this example is kinda bad as they only have a single item in that submenu)
  137. rodneyrehm
    10:05
    actually, I think your TAB handling is quite unnecessary
  138. StommePoes
    10:06
    because I should find some other way to make the submenu items non-tabbable when they appear, but still focusable?
  139. rodneyrehm
    10:06
    the only thing you need to do is hide the sub-menu when the tab key is hit. the browser will focus the next menu item, or next item after the menu automatically
  140. rodneyrehm
    10:06
    when they’re hidden, they’re not focusable
  141. StommePoes
    10:06
    right
  142. StommePoes
    10:06
    hm
  143. StommePoes
    10:06
    if I can wrangle that, that would be nice
  144. Heydon
    10:06
    @rodneyrehm Yeah, that seems right. Are we missing something, @StommePoes ?
  145. rodneyrehm
    10:06
    and since we’re taking milliseconds here, nobody would notice a difference
  146. StommePoes
    10:06
    yeah
  147. StommePoes
    10:07
    actually, also my current menu is broken... but only on some shops (and not others with the same version of code), and only on safari/default iThing browser and then only after the Yosemite update (older versions work)
  148. StommePoes
    10:07
    That's been a puzzle too as I don't own any iThings
  149. StommePoes
    10:07
    and one shop that works while another doesn't, seems to have the same code.
  150. StommePoes
    10:08
    The click event seems to get interrupted or ignored
  151. rodneyrehm
    10:08
    @StommePoes you actually need to activate tabbing content on OSX
  152. StommePoes
    10:08
    the submenus flash for a moment and focus seems to be placed on the main menu item (it gets the "active" class) but the user can't navigate
  153. rodneyrehm
    10:08
    there’s a system setting for the OS, and there’s a Safari option to include <a> in the sequential navigation order
  154. StommePoes
    10:09
    my colleague, who does have an iThing, can click on shop.hoogerwerf.nl the menu items and navigate to an inner page, but cannot on shop.noordhuis.nl
  155. StommePoes
    10:10
    In any case, not only can we not tell customers of our clients to upgrade their OS or not, we also can't tell them to activate something to use our site-- they expect it to work however they got there. Since one site works and another does not, the problem must be somewhere with my code.
  156. rodneyrehm
    10:10
    not necessarily
  157. StommePoes
    10:10
    And on a demo of the non-working site I've played with adding other versions of other shops, even a direct copy-pasta of the shop that does work, with no effect according to the colleague with the iThing
  158. StommePoes
    10:11
    It works on everything on Android according to another colleague with like 4 browsers on his Android. And the stagier here has an older iPhone with saffy 7, works there too. Also firefox on her phone.
  159. rodneyrehm
    10:11
    if one component is able to register event handlers BEFORE your menu code runs and performs an event.stopImmediatePropagation(); you’d never see the event ;)
  160. StommePoes
    10:12
    That makes sense, though I'm actually not dealing directly with the onclicks though
  161. rodneyrehm
    10:12
    Dev Tools show you the registered events per element. walk through the tree and see if something is borked
  162. StommePoes
    10:12
    I wrangle focus, and there seems to be a change in saffy' focus order with regards to touch starts and clicks, but I'm not sure whta
  163. StommePoes
    10:12
    what
  164. StommePoes
    10:12
    I can't borrow my colleague's private phone that long :P
  165. StommePoes
    10:13
    but he would be able to open a dev tools something on his phone?
  166. StommePoes
    10:13
    The original client who complained had an iPad-something with latest iOS and default browser, but nobody here has a tablet.
  167. StommePoes
    10:14
    (wouldn't it be great if, a company who tells its clients that our stuff works on mobiles, that said company would supply mobiles for testing to the front-ender?)
  168. rodneyrehm
    10:14
    safari will only focus an element if it has an onclick handler - because otherwise mousedown is not executed, which happens to be the event that contains the focus-dispatcher
  169. StommePoes
    10:14
    our "normal" links don't have any special click handlers
  170. StommePoes
    10:14
    so what exactly do you mean?
  171. StommePoes
    10:15
    because I had been thinking of, only on the problem sites, adding a listen for touchstart
  172. rodneyrehm
    10:15
    also that could be failing because something like FastClick is intercepting the native events and dispatches synthetic events instead - those will not trigger focus either
  173. StommePoes
    10:15
    and forcing a redirect to that link's url
  174. StommePoes
    10:15
    We're certainly not (directly, ourselves) running any mobile-like stuff like fastclick, nor has my colleague installed anything on his phone (he's a sales consultant, he just buys-and-uses)
  175. StommePoes
    10:16
    tho somethign could come in a plugin
  176. StommePoes
    10:16
    I don't think any of our plugins mess with that 300ms delay tho
  177. rodneyrehm
    10:16

    but he would be able to open a dev tools something on his phone?

    Mobile Chrome -> Chrome,
    Mobile Safari -> Safari/WebKit (need to enable developer tools in Safari, and remote debugging on the phone)

    you’ll then get the DevTools for the content on your phone

  178. StommePoes
    10:16
    so his phone has, or can download, a DevTools?
  179. StommePoes
    10:16
    Because maybe I can convince him to do that
  180. StommePoes
    10:17
    Isn't mobile chrome the "default" browser on Android?
  181. rodneyrehm
    10:17
    he does not need to download anything on his iphone
  182. StommePoes
    10:18
    ok his saffy will just have it, it just needs to be turned on then
  183. rodneyrehm
    10:18
    he needs to activate an option on his iphone - that’s it
  184. StommePoes
    10:18
    cool
  185. MichielBijl
    10:18
    I give up, of course the project is built in Backbone; so a simple event listener for keypress doesn't work. FML
  186. rodneyrehm
    10:19
  187. rodneyrehm
    10:19
    “keypress” may be the problem, @MichielBijl
  188. rodneyrehm
    10:21
    @MichielBijl see http://medialize.github.io/ally.js/tests/event-sequence/table.html for an indication - Firefox is the only browser to actually dispatch "keypress"
  189. StommePoes
    10:21
    Yeah I avoid keepress because PPK said it was flaky as hell
  190. StommePoes
    10:22
    but I waffle on keyup/down, I tend to use up I guess because it's last (usually)
  191. rodneyrehm
    10:22
    you’ll want to go with “keydown”, as that is the the event containing the browser’s focus handling stuff
  192. StommePoes
    10:22
    @rodney good to hear this debugger can work on linux, no way my company would purchase a mac for me, lawlz
  193. rodneyrehm
    10:22
    event.preventDefault() on keyup should do just about nothing to focus, because it already happened at that point
  194. StommePoes
    10:22
    @rodney oh? good to know (keydown)
  195. MichielBijl
    10:22
    @rodneyrehm keydown, keyup etc don't work either
  196. rodneyrehm
    10:23
    @StommePoes your company sounds like a dream…
  197. MichielBijl @MichielBijl doesn't work with Backbone that ofter, so it's probably my fault
  198. StommePoes
    10:23
    It's in the clouds... :)
  199. rodneyrehm
    10:23
    … or, nightmare, actually
  200. StommePoes
    10:23
    Both.
  201. StommePoes
    10:23
    I'm leaving it.
  202. rodneyrehm
    10:23
    hehe, ok
  203. StommePoes
    10:23
    Signed wednesday for some place that likes accessibility and wants me to care about it
  204. rodneyrehm
    10:24
    @MichielBijl I have no idea what you’re doing / trying. I have not had issues with Backbone in that way.
  205. MichielBijl
    10:25
    @rodneyrehm I'll explain in bit, have to push this now
  206. StommePoes
    10:25
    @michiel I'd direct you to my other half, he used backbone for quite a while and liked it, and would likely know or be able to figure out what it's maybe doing, but today he's busy on a project.
  207. rodneyrehm
    10:25
    no worries, I actually need to get some work done here, too ;)
  208. LjWatson
    11:38
    Yeah, that's the danger with lightening talk. Think he was just ttrying to convey excitement.
  209. StommePoes
    11:40
    wrong window?
  210. MichielBijl
    11:46
    For the backbone experts: this is what I was doing:
  211. MichielBijl
    11:46
    ```var Overlay = Backbone.View.extend({
        initialize: function() {         $(document).on('keydown', this.manageFocus, this);     } });```
    
  212. MichielBijl
    11:46
    Thanks Gitter -.-
  213. MichielBijl
    11:47
    var Overlay = Backbone.View.extend({          initialize: function() {             $(document).on('keydown', this.manageFocus, this);         }     });
    
  214. StommePoes
    11:47
    totally readable hier on pidgin
  215. MichielBijl
    11:47
    That didn't do anything, but it's not really a11y specific; so this might be the wrong place to ask.
  216. MichielBijl
    11:47
    Same code without Backbone works like a charm
  217. rodneyrehm
    11:48
    initialize just means the view has been created - not rendered, not added to the dom
  218. rodneyrehm
    11:48
    maybe you’re looking for onRender instead?
  219. MichielBijl
    11:49
    I'll try that :)
  220. rodneyrehm
    11:49
    also, when adding stuff outside of your view, make sure to clean up onDestroy or you’ll orphan that event handler
  221. rodneyrehm
    11:50
    since when does the jQuery on method accept a context?
  222. rodneyrehm
    11:50
  223. rodneyrehm
    11:51

    ok, so you’d want to change

    $(document).on(‘keydown’, this.manageFocus, this);
    

    to

    $(document).on(‘keydown’, this.manageFocus.bind(this));
    
  224. MichielBijl
    11:52
    I can't find onRender on the backbone website
  225. MichielBijl
    11:52
    Isn't that something from marionette?
  226. rodneyrehm
    11:53
    crap, of course it is
  227. rodneyrehm
    11:53
    sorry
  228. MichielBijl
    11:53
    No worries :)
  229. rodneyrehm
    11:54
    I’ve never used Backbone without Marionette for actually rendering things
  230. MichielBijl
    11:54
    Good news for me though, that thingy you did with bind seems to have done the trick
  231. MichielBijl
    11:54
    :D
  232. MichielBijl
    11:54
    It's a rather old project
  233. stevefaulkner
    12:18
    @StommePoes you are looking at a very old version of the alt tech doc
  234. stevefaulkner
    12:24
    @StommePoes you are looking at a very old version of the alt doc "W3C Editor's Draft 05 October 2012" latest standalone working draft
    http://www.w3.org/TR/2014/WD-html-alt-techniques-20141023/ latest folded into HTML http://www.w3.org/TR/html51/semantics.html#alt
  235. StommePoes
    12:27
  236. StommePoes
    12:27
    the note I mean
  237. StommePoes
    12:27
    is the note out of date
  238. stevefaulkner
    12:28
    That is from the draft you are looking at, so yes
  239. StommePoes
    12:28
    and then also a question: can we prevent the image src from being read out when there's no alt, or does that lie then with the AT vendors or the users ?
  240. StommePoes
    12:29
    We do want the image to be announced as in, there's a graphic, but does figcaption need then extra aria-isation to be considered teh accessible name of the image inside the figure?
  241. stevefaulkner
    12:30
    @StommePoes that is a user preference of the aural UI provided by AT
  242. StommePoes
    12:30
    it says there the figure/figcaption provide an association but is that so?
  243. StommePoes
    12:30
    ok because it's the default (or was the default) for many readers
  244. StommePoes
    12:31
    hm ok it says if at+browser support
  245. LjWatson
    12:31
    @StommePoes AFAIK only Jaws actually uses the figcaption text as acc name for the figure, and actually announces it when the figure is entountered.
  246. LjWatson
    12:31
    Amongst screen readers I mean.
  247. StommePoes
    12:31
    Nice, if it's agreed that that's what we all want then I assume mick and jamie are on it already
  248. LjWatson
    12:31
    Actually, I'm not sure it is what we want.
  249. StommePoes
    12:32
    I'm not either, tho there are cases where a caption and alt text would be conceptually the same
  250. LjWatson
    12:32
    It makes sense in theory, but if the figcaption is lengthy, you get to hear it twice in the current Jaws implementation.
  251. StommePoes
    12:32
    but the example I ran into on Medium was not one of those.
  252. koalie
    12:32
    @stevefaulkner Hai!
  253. StommePoes
    12:32
    Twice? I thought the figcaption would be the acc name of the image if there's no alt.
  254. LjWatson
    12:32
    Sure, it works if figcaption is short... but there is no constraint on the possible length of a figcaption.
  255. StommePoes
    12:33
    Hm true, nor should there be I don't think.
  256. StommePoes
    12:33
    I've seen long captions under graphs and charts, all that content needed to be there.
  257. LjWatson
    12:33
    No, figcaption is the acc name for figure, not it's content.
  258. StommePoes
    12:33
    Oh.
  259. stevefaulkner
    12:33
    Hey @LjWatson I read that pF is looking at adding figure role, suggest a caption role is also desirable ( as I have argued in past)
  260. LjWatson
    12:33
    @stevefaulkner yes, that's come up through SVG too, so I think there will be a proposal in the works.
  261. StommePoes
    12:33
    can roles have attributes? that would be nice.
  262. StommePoes
    12:34
    or, things with roles get certain attributes with them.
  263. LjWatson
    12:34
    Hmm. They don't at the moment, although some roles have required attributes - like role="heading" and aria-level="n"
  264. StommePoes
    12:35
    yeah. currently they sort of mimic a name attribute like when a region has a heading inside it, or if a landmark has aria-label
  265. StommePoes
    12:35
    because caption seems more like an attribute of a figure (or really, of the content of a figure)
  266. LjWatson
    12:36
    It does, but making figcaption the acc name of figure is the only way to cater for any kind of content in the figure I guess.
  267. StommePoes
    12:37
    A long caption is... honestly a type of figure content, in my mind. At least, if I think about those very very long captions in technical books and reports, under diagrams etc.
  268. StommePoes
    12:37
    Visually in a book people would call it a caption because it's the text under the image, but it could also be seen as an image + a <p>description and extra info</p>
  269. StommePoes
    12:38
    depending. The examples in the URLS from steve are more like traditional image caption-captions.
  270. LjWatson
    12:38
    Yes, I think that makes sense. It's just not how I'm seeing figure/figcaption used in the wild - most often they're not being used as traditional figures at all, but for associated content/caption in a more general sense.
  271. StommePoes
    12:38
    yeah me too.
  272. Heydon
    12:38
    @LjWatson @StommePoes @stevefaulkner I think <figcaption> should either be left as content or treated as the accessible description, not accessible name.
  273. StommePoes
    12:38
    Not that I'm seeing them often.
  274. StommePoes
    12:38
    yeah, with something else being the acc name.
  275. LjWatson
    12:38
    @Heydon that's an interesting idea.
  276. StommePoes
    12:39
    It seems to me that short captions are the exception rather than the rule
  277. LjWatson
    12:39
    So for s/readers it could be requested, not read automatically I guess.
  278. StommePoes
    12:39
    and Photo 1 or "Figure 12" are not really the same thing as the descriptions in the html5 ecxample
  279. LjWatson
    12:39
    @Heydon you got a whole bunch of shout outs at FrontEnd Conf CH yesterday BTW :)
  280. Heydon
    12:39
    @LjWatson Maybe, or when you move to the image itself, the figcaption is read after the accessible name, as if it were connected like aria-describedby
  281. LjWatson
    12:40
    You'd still get duplication then though - once for the acc desc, and again as th eactual figcaption content.
  282. LjWatson
    12:41
    Got to run... @Heydon @StommePoes would be good to talk more about this another time.
  283. StommePoes
    12:41
    ja
  284. Heydon
    12:42
    @LjWatson True, although there would be a pause. I was just wondering if there was any benefit in the acc name and acc description being concatenated. Perhaps not.
  285. stevefaulkner
    12:42
    @Heydon @Heydon yeah duplication is the problem that's why I originally proposed figure and caption roles so caption content can be recognised as such
  286. Heydon
    12:42
    @LjWatson Cheers!
  287. stevefaulkner
    12:42
    But it was nixed at the time
  288. Heydon
    12:44
    @stevefaulkner Interesting. What would the proposed behavior for these roles be?
  289. Heydon
    12:48
    @stevefaulkner Occurs to me that the relationship should actually be figcaption -> image like an aria-owns type thing where the behavior could be to tell you appended info about the image when you are on the figcaption.
  290. stevefaulkner
    12:49
  291. Heydon
    13:03
    Yeah, I think scenario 1 is my favorite semantically. I just wonder if a relationship thing like aria-owns is worth a while.
  292. Heydon
    13:04
    I guess not, since figure+caption relationship is implicit.
  293. MichielBijl
    13:23
    To trap focus I did this:
    manageFocus: function(event) {             if (!this.$el.attr('aria-hidden') && event.keyCode === 9) {                 var insideOverlay = this.$el.has($(event.target)).length;                 if (!insideOverlay) {                     $('a', this.$el).focus();                 }             }         }
    
  294. MichielBijl
    13:24
    It's not brilliant, but there are only two focusable elements in the dialog, so it works
  295. MichielBijl
    13:24
    And my other excuse is that the page is only live for 5 days…
  296. rodneyrehm
    13:46
    !this.$el.attr('aria-hidden’)
    

    is bad, because “false” is truthy. go with

    this.$el.attr('aria-hidden’) !== ’true'
    

    instead

  297. stevefaulkner
    13:47
    @Heydon the fig caption is contained within the figure so not implicit
  298. stevefaulkner
    13:48
    As in child of
  299. rodneyrehm
    13:54
    var insideOverlay = this.$el.has($(event.target)).length;
    

    will query the sub-tree, where

    var insideOverlay = this.el.compareDocumentPosition(event.target) & Node.DOCUMENT_POSITION_CONTAINED_BY
    

    won't

  300. Heydon
    13:59
    @stevefaulkner Sorry, I didn't mean technically implicit, I meant in the mind of the user :-)
  301. stevefaulkner
    13:59
    Right it's all in your mind 😜
  302. MichielBijl
    14:00
    @rodneyrehm thank you so much! MDN document for those interested: https://developer.mozilla.org/en-US/docs/Web/API/Node/compareDocumentPosition
  303. Heydon
    14:01
    haha
  304. MichielBijl
    14:02
    Maybe there is a tiny door somewhere through which we can enter Heydon's mind, and finally see all the weird shit that's going on.
  305. rodneyrehm
    14:02
    I’d rather not ;)
  306. MichielBijl
    14:03
  307. Heydon
    14:09
    @MichielBijl The door is not located in an accessible place.
  308. MichielBijl
    14:11
    No wheelchair ramp?
  309. MichielBijl
    14:11
    Bastards!
  310. stevefaulkner
    14:25
    @MichielBijl reading 'Gravity's Rainbow' will give you some insight
  311. MichielBijl
    14:28
    I'll add that to my already way too long reading list ;)
  312. stevefaulkner
    15:34
    @MichielBijl "Traversing an immense range of knowledge, the novel transgresses boundaries between high and low culture, between literary propriety and profanity, and between science and speculative metaphysics."
  313. zakim-robot
    15:54
    [monastic.panic, a11y] hi ya'll
  314. zakim-robot
    15:54
    [monastic.panic, a11y] I come baring Modal a11y questions again...
  315. zakim-robot
    15:56
    [monastic.panic, a11y] focus should work the same as if there was nothing else on the page right?
  316. zakim-robot
    15:56
    [monastic.panic, a11y] some implementations i've seem immediately return focus to the first focusable after leaving the modal
  317. zakim-robot
    15:56
    [monastic.panic, a11y] vs letting it loop out of the browser window
  318. zakim-robot
    15:57
    [monastic.panic, a11y] which would be teh behavior of tabbing from the last focusable on a page
  319. rodneyrehm
    15:58
    most implementations - apply the trap focus idea - are not able to let focus escape the document (to the browser ui). Chrome’s implementation of the <dialog> element allows just that.
  320. rodneyrehm
    15:59
    if your modal dialog is the last element of the document, you can allow focus to leave the document. But if your dialog is anywhere else in the dom, it’s not possible to mimic that behavior when trapping focus
  321. rodneyrehm
    16:01
    I don’t like the idea of trapping focus very much. It meddles with user input - a thing you should never be sure about how it actually happens. It only works by overruling the browser, without the browser giving us the low-level functionality to actually do it properly.
  322. zakim-robot
    16:02
    [monastic.panic, a11y] in this case its relatively sure to be the last focusable thing, jsut by nature of how its added to the DOM
  323. rodneyrehm
    16:02
    I’ve implemented a proof of concept that allows me to not interfere with user interaction, simply by making sure no element outside of my dialog is focusable: http://medialize.github.io/ally.js/examples/disable-focus.html
  324. rodneyrehm
    16:03
    a dialog being the last element of the document depends on the implementation. In my case it is not.
  325. zakim-robot
    16:04
    [monastic.panic, a11y] yeah definately
  326. zakim-robot
    16:04
    [monastic.panic, a11y] i like the idea of disabling focus everywhere else
  327. rodneyrehm
    16:04
    but if you are sure that’s the case for your implementation, simply not interfere with focus when leaving the last element?
  328. zakim-robot
    16:05
    [monastic.panic, a11y] we do that now, focus will shift to the browser ul bar
  329. zakim-robot
    16:05
    [monastic.panic, a11y] that to mean feels like the "correct" behavior
  330. rodneyrehm
    16:06
    agree
  331. zakim-robot
    16:06
    [monastic.panic, a11y] the problem is shift-tab...
  332. rodneyrehm
    16:06
    hehe
  333. zakim-robot
    16:06
    [monastic.panic, a11y] are you using the PoC in anything legitmate?
  334. zakim-robot
    16:07
    [monastic.panic, a11y] i like the idea...even if not for this
  335. rodneyrehm
    16:07
    yeah, well, unless you hide the entire content except for the dialog, you won’t make the dialog be the first and last tabbable element :D
  336. rodneyrehm
    16:07
    define legitimate
  337. zakim-robot
    16:08
    [monastic.panic, a11y] production?
  338. rodneyrehm
    16:08
    I’m using this in an application (no, it’s not a website). running on desktop and mobile. without a hitch. in production.
  339. rodneyrehm
    16:08
    although, modern browsers only
  340. zakim-robot
    16:08
    [monastic.panic, a11y] adding inert to stuff is more analogous to adding aria-hidden as well
  341. rodneyrehm
    16:08
    Android 4.4+, IE11+, iOS7+
  342. rodneyrehm
    16:08
    yes and no
  343. rodneyrehm
    16:09
    aria-hidden spans the entire sub-tree, inert (as it does not exist), does not
  344. zakim-robot
    16:09
    [monastic.panic, a11y] ah i thought adding invert to a top element appied to teh whole subtree
  345. zakim-robot
    16:09
    [monastic.panic, a11y] also i did not even realize invert was a thing that html5 was removing :stuck_out_tongue:
  346. rodneyrehm
    16:10
    well, ok, if the inert attribute had stayed in html5, it would’ve behaved the same way, yes. but there is no such attribute and no such behavior. to manually make something inert, you need to know what that something is. that means it can’t inherit from the tree
  347. rodneyrehm
    16:10
    inert was proposed for html5, but dropped before becoming recommendation
  348. zakim-robot
    16:11
    [monastic.panic, a11y] so html5 is adding a more robust concept but not an attribute?
  349. zakim-robot
    16:11
    [monastic.panic, a11y] i.e. the dialog element makes stuff inert
  350. rodneyrehm
    16:12
    it is defining inert subtrees (to some extent) for implementors (browser vendors), but it is not exposing that feature to authors ("web developers")
  351. zakim-robot
    16:12
    [monastic.panic, a11y] that's annoying
  352. rodneyrehm
    16:13
    well, opening a dialog element will make the browser run through the activation process. and somwhere in there it says to make sure no element outside of <dialog> can be interacted with. so in a way “the dialog element makes stuff inert” has some truth to it :D
  353. brunopulis
    16:20
    Hi folks i have a doubt about how to use ARIA on html anyone can help me?
  354. rodneyrehm
    16:22
    just ask your question and have some patience, @brunopulis - eventually someone will pick up on your issue
  355. brunopulis
    16:32
    Thanks to feedback @rodneyrehm :smile:
  356. brunopulis
    16:32

    I have a simple html markup when it valid in https://validator.w3.org/nu/ it displays:

    "Warning: Element header does not need a role attribute.

    <header role = "banner" class = "uai__cabecalho"> "

    It is wrong to use the aria attribute?

  357. rodneyrehm
    16:33
    not necessarily wrong, but not required anymore
  358. brunopulis
    16:33
    why is not necessary anymore?
  359. rodneyrehm
    16:45
    because it is set on the element by default
  360. brunopulis
    16:46
    @rodneyrehm Thanks! :+1: :smile:
  361. rodneyrehm
    16:46
    Steve has a support table on that sort of stuff: http://stevefaulkner.github.io/HTML5accessibility/
  362. zakim-robot
    17:02
    [Marcy Sutton, a11y] Unless you’re supporting IE, and then you might want to keep it
  363. zakim-robot
    18:38
    [Jordan Scales, a11y] should a “Skip to main content” link focus anything when clicked?
  364. garcialo
    18:39
    You mean putting focus somewhere in addition to going to the main content?
  365. zakim-robot
    18:40
    [Jordan Scales, a11y] @garcialo it looks like most sites will simply scroll the user somewhere on the page, but I’m wondering if it should focus the content as well
  366. zakim-robot
    18:40
    [Jordan Scales, a11y] so that subsequent presses of the tab key can, in fact, skip to the main content
  367. garcialo
    18:41
    Doesn't the focus move to the main content when you follow the link to it?
  368. garcialo
    18:42
    I guess if the skip link is acting like a button that scrolls the page, then yeah, you would want to move the focus to the main content.
  369. zakim-robot
    18:42
    [Jordan Scales, a11y] on gov.uk and collegeboard.com if you tab, skip to main content appears, hit enter, the window scrolls to the main content, hit tab again, skip to main content appears
  370. garcialo
    18:44
    Ah, I see
  371. garcialo
    18:44
    That's probably because they have tabindex="1" on it
  372. zakim-robot
    18:44
    [Marcy Sutton, a11y] That’s a bug in Chrome, works in FF
  373. zakim-robot
    18:45
    [Marcy Sutton, a11y] <main id=“content”> needs tabindex=“-1”
  374. zakim-robot
    18:49
    [Jordan Scales, a11y] our main issue is that we focus #page-container, which has a tabindex=“-1”, but this is causing issue for some of our dropdown menus :disappointed:
  375. zakim-robot
    18:50
    [Jordan Scales, a11y] I’m thinking our best bet is to focus something right before #page-container, but the question is what to put in it
  376. zakim-robot
    18:56
    [Marcy Sutton, a11y] What are the issues with dropdown menus?
  377. zakim-robot
    18:57
    [dylanb, a11y] @marcysutton: have you tested whether tabindex=-1 works in Safari too?
  378. zakim-robot
    18:58
    [dylanb, a11y] @jdan: you should have a heading in the page container, why not focus that?
  379. zakim-robot
    18:59
    [Jordan Scales, a11y] @dylanb good point!
  380. zakim-robot
    19:04
    [Jordan Scales, a11y] @marcysutton some focusin troubles :disappointed: clicking on a label bubbles up to page-container, causing our custom dropdowns to collapse
  381. cptvitamin
    19:06
    you can put nothing in it <div style=“outline:none;” tabindex="-1"></div>
  382. cptvitamin
    19:06
    move focus to that
  383. cptvitamin
    19:12
    is anyone else surprised to find that Safari/Voiceover reports a div with a tabindex=“-1” as a group?
  384. cptvitamin
    19:12
    i wouldn’t think a tabindex with a particular value (-1 in this case) would affect the role of an element
  385. cptvitamin
    19:13
    even more confusing is that putting an aria-label attribute on that div changes where Voiceover cursor lands when focus is moved to the div
  386. cptvitamin
    19:14
    i put together this little demo file: http://output.jsbin.com/resomi
  387. zakim-robot
    19:14
    [Marcy Sutton, a11y] Oh yes thanks for the reminder about device fatigue :pensive:
  388. cyns
    19:18
    @stevefaulkner thanks, that's better than what I had found.
  389. dylanb
    19:55
    @cptvitamin having no focus style on something will lose visual focus indication, which should never happen
  390. cptvitamin
    20:11
    @dylanb of course, but in this use case, it’s clear something happens (page scrolls) subsequent tabs are logical. It’s never unclear what is happening. I agree, it’s not best practice, but I’ve user tested this and the result is very logical
  391. zakim-robot
    21:42
    [Marcy Sutton, a11y] @dylanb that fix works for Safari as well, which suffers from the same problem
  392. stevefaulkner
    22:05
    @cptvitamin group is default generic role in AX API , what adding tab index does is cause VO to announce the role, when it is generally not announced. and yes adding tabindex to non interactive elements does weird things, it's on my todo list for specifying...
  393. stevefaulkner
    22:11
    @cptvitamin role=presentation?