Archive index

A11y Slackers Gitter Channel Archive 10th of February 2016

What fresh hell is THIS now? - Patrick Lauke
  1. detlevhfischer
    Feb 10 05:51
    Thanks for that James! We just need to deal with the not infrequent pattern of alt="" and title carrying the alternative text doubling as tooltip when rating content. We would not recommend that either but we need to determine whether it meets the relevant 1.1.1 checkpoint or not. I will set up a test page and check with as many SR & settings as I can lay my hand on to see whether there are real disadvantages in some UA/AT situations that you'd think should be included in a wide accessibility support baseline.
  2. StommePoes
    Feb 10 08:46
    Detlev... what about using alt and then doing img:hover{content: attr(alt); + styles}?
  3. StommePoes
    Feb 10 08:46
    I have done this in the past where someone wanted images with tooltip and no separate alt text (I've also done it with an alt and different tooltip/title as well)
  4. StommePoes
    Feb 10 08:46
    @detlevhfischer
  5. zakim-robot
    Feb 10 09:24
    [florianbrinkmann] Hi all!
    I tried to create a social media menu with svg icons instead of icon fonts and stumbled over the following problem while testing it with the screen reader NVDA.
    This is my markup:
    <a href="https://twitter.com/"> <svg version="1.1" viewBox="0 0 512 512" role="img"> <title>Twitter-Account</title> <path d="m481 117c-13 18-28 34-46 47c0 3 0 7 0 12c0 25-3 50-11 74c-7 25-18 49-33 71c-14 23-32 43-52 61c-21 17-45 31-74 41c-29 11-60 16-92 16c-52 0-99-14-142-42c7 1 14 2 22 2c43 0 81-14 115-40c-20 0-38-6-54-18c-16-12-27-27-33-46c7 1 13 2 18 2c8 0 16-1 24-4c-21-4-39-15-53-31c-14-17-21-37-21-59l0-1c13 7 27 11 42 11c-13-8-23-19-30-32c-8-14-11-29-11-44c0-17 4-33 12-47c23 28 51 51 84 68c33 17 69 27 107 29c-2-8-3-15-3-22c0-25 9-47 27-65c18-18 40-27 66-27c26 0 49 10 67 29c21-4 40-11 59-22c-7 22-21 39-41 51c18-2 35-7 53-14z"/> </svg> </a>
    And this is, what NVDA shows me in the “Speech Viewer”:
    besucht Link Grafik Twitter-AccountTwitter-Account
    So the problem is the title “Twitter-Account” which is shown twice. Has anyone an idea, what is wrong with my code and why the title is displayed twice in the Speech Viewer Output? I used Firefox on Windows 10 for testing…
    Thanks in advance :simple_smile:
  6. detlevhfischer
    Feb 10 10:31
    @StommePoes Thanks for pointing out that option - it's just not the problem I am discussing.
  7. detlevhfischer
    Feb 10 10:32
    I have created a test page but not yet started screen reader testing http://3needs.org/en/testing/code/alt+title-test.html - if anyone does send me the results and I will add them.
  8. stevefaulkner
    Feb 10 11:01
    Morning @detlevhfischer may be of interest https://twitter.com/stevefaulkner/status/697374511784656896
  9. MichielBijl
    Feb 10 11:07
    @florianbrinkmann AFAIK the title attribute isn't supported by all AT. From some limited testing by StommePoes and me, it's best to use aria-label on the SVG.
  10. MichielBijl
    Feb 10 11:08
    https://github.com/MichielBijl/font-awesome
  11. FlorianBrinkmann
    Feb 10 11:12
    @MichielBijl thanks for the link! I tested it with aria-label and it works fine if I remove the role="img", so I will use it without the role attribute :)
  12. MichielBijl
    Feb 10 11:27
    So it doesn't work with the role? That seems odd. Which AT/Browser?
  13. FlorianBrinkmann
    Feb 10 11:29
    If I use the role, I have the same problem as with the title element—the content of aria-label is displayed twice. For testing I use NVDA and Firefox
  14. detlevhfischer
    Feb 10 11:35
    @stevefaulkner ah, great, you are quick! will read.
  15. stevefaulkner
    Feb 10 11:36
    @detlevhfischer was thinking about it last night and rembered previous stuff about it...
  16. detlevhfischer
    Feb 10 12:09
    My own test page may not be pointless since it would also show if and when title and alt values are spoken twice and what exactly happens in what browser / SR combos - but I guess this has been done before.
  17. StommePoes
    Feb 10 12:15
    Florian, the double-speaking is a known NVDA bug
  18. StommePoes
    Feb 10 12:15
    and to me, the best solution today is still not to use aria-anything but offscreen text
  19. StommePoes
    Feb 10 12:15
    why? JAWS+IE sux with aria-label+role=whatever
  20. StommePoes
    Feb 10 12:15
    on img on SVGs at least
  21. stevefaulkner
    Feb 10 12:15
    @detlevhfischer not useless, as I haven't recorded hard results... yet
  22. StommePoes
    Feb 10 12:16
    Detlev: my proposal was mostly to get around this: "One rationale for this design pattern may be to avoid the potential redundant rendering of alt and title title values in screen readers - chatty redundant output which can be very distracting. "
  23. StommePoes
    Feb 10 12:16
    Also you can change your SR settings to either read titles or not, and who knows how much people do that?
  24. FlorianBrinkmann
    Feb 10 12:31
    Okay thanks @StommePoes!
  25. StommePoes
    Feb 10 12:32
    Leonie does titel and desc with aria-label + aria-describedy linking both but I can't recall if that got her around the NVDA issue
  26. zakim-robot
    Feb 10 12:46
    [florianbrinkmann] Yeah, I tried the tips from her sitepoint article. I tested the speeking with Microsoft Edge now and it seems that the solution with a span as offscreen text is the best solution at the moment … Edge can’t aria-label or title, I just get empty as value…
  27. StommePoes
    Feb 10 12:48
    Edge has issues, but you did test on IE?
  28. stevefaulkner
    Feb 10 12:48
    @FlorianBrinkmann I wouldn't bother much with edge at this time as its accessibility implementation is still in progress
  29. StommePoes
    Feb 10 12:48
    I kinda suspect the Edge team were working like mad squirrels on Edge but MS as a whole wanted to announce something early and the team just couldn't make the deadline.
  30. FlorianBrinkmann
    Feb 10 12:49
    ah okay, thanks @stevefaulkner
  31. stevefaulkner
    Feb 10 12:50
    @StommePoes yes they are working hard on it, so expect to see a usable implementation by year end (fingers crossed)
  32. StommePoes
    Feb 10 12:50
    So I see the offscreen span thing as a kludge because eventually when stuff's supported we'd be ripping that out and using what we should be using, <title> and <desc> tags etc. But support isn't quite there yet.
  33. StommePoes
    Feb 10 12:50
    @steveFaulkner yeah they get a lot of shit and I know they're not like the Slack people, talking but not doing. on the other hand, people getting auto-upgraded to Win10 with the Edge file system kinda sucks.
  34. StommePoes
    Feb 10 12:51
    Though it sorta works.
  35. FlorianBrinkmann
    Feb 10 12:51

    So I see the offscreen span thing as a kludge because eventually when stuff's supported we'd be ripping that out and using what we should be using, <title> and <desc> tags etc.

    Yep, that sounds good

  36. StommePoes
    Feb 10 12:52
    There's also Dragon... I'm still not proficient enough to have figured out how to use Dragon but while 13+ has some support for ARIA I'm always kinda thinking, how can I offer speech users text so they know what the name is?
  37. StommePoes
    Feb 10 12:52
    And with offscreen spans there's always the possibility of maybe showing that text on :focus or something
  38. StommePoes
    Feb 10 12:52
    as an element, you can move it around.
  39. StommePoes
    Feb 10 12:53
    Esp buttons with icons only, ug. Aria-label can't save that unless the user can guess real well what the name of that might be.
  40. StommePoes
    Feb 10 12:53
    so on a page full of those you have to do click button and see which number it got assigned.
  41. FlorianBrinkmann
    Feb 10 13:01
    Yes, I see. Thanks very much for the interesting thoughts!
  42. powrsurg
    Feb 10 14:02
    So we just launched a new, unified responsive login / registration form for our site. It passed aXe tests and for nice-ness it will auto focus on each form based on what you were going for ... https://collabornation.net/login#register-form and https://collabornation.net/login#login
  43. powrsurg
    Feb 10 14:02
    thoughts?
  44. powrsurg
    Feb 10 14:06
    Also on the main page https://collabornation.net/login we did CSS transition for the skip to main content link coming in. Debated on if it was too slow or not ...
  45. zakim-robot
    Feb 10 14:10
    [karlgroves] I disagree with the practice of focusing on the first form field. This practice prevents SR users from knowing where they actually are first.
  46. powrsurg
    Feb 10 14:15
    Well, the presumption is that they are coming from a page where they just clicked on login or register ...
  47. powrsurg
    Feb 10 14:18
    But I'll bring that point up. Hadn't considered that
  48. zakim-robot
    Feb 10 14:18

    [karlgroves] Ok. So lets that the registration use case first: Why should I register? What will I get? Registration is a conversion event. We’re turning a visitor into a lead at that point. Well, you’re trying to make that case with the content on the left, correct? Except a user who can’t see that content won’t get it, because they’ve been shuffled off into a form.

    Put another way: why is that content on the left there if we don’t intent (some) people to ever consume that content?

  49. powrsurg
    Feb 10 14:22
    That's actually a good point. We are more B2B where organizations have their employees register. The stuff on the left is feedback in case they forgot what was in their email from their employer
  50. powrsurg
    Feb 10 14:25
    in our markup it actually has the login, then the content on the left, then the registration form.
  51. FionaTG
    Feb 10 14:27
    @powrsurg Your skip link isn't working in Chrome - you need to add tabindex -1 to the main content div
  52. powrsurg
    Feb 10 14:29
    Chrome won't let you skip to an id unless it has a tabindex?
  53. FionaTG
    Feb 10 14:32
    For a while now, yeah. It means 99% of skip links out in the wild are broken in Chrome
  54. FionaTG
    Feb 10 14:33
    I blogged about it a while back: http://myaccessible.website/video-guides/skip-to-main-content/
  55. powrsurg
    Feb 10 14:34
    Okay, definitely did not know about that. Wow. I made a big thing about improving our skip to main content so that it actually seemed nice. Had just assumed that what it linked to actually worked ... and since I test mostly in Firefox it did ...
  56. FionaTG
    Feb 10 14:35
    Skip links seem incredibly browser dependent, I've seen quirks in all the major ones
  57. powrsurg
    Feb 10 14:37
    Hmmm ... I know a lot of people that thought to skip to something it had to be an anchor tag, so maybe for them it would work?
  58. FionaTG
    Feb 10 14:38
    I've seen that fail in other browsers, can't remember which off the top of my head, possibly IE
  59. powrsurg
    Feb 10 14:41
    well regardless, I'm adding that now. Need to talk to the team about Karl's point
  60. garcialo
    Feb 10 15:01
    @powrsurg I agree with @karlgroves. That said, I'm not always against autofocus; I would say it's okay if the only thing on the page is the form that needs to be filled out, the title of the page reflected that function, and the form should be the first thing in the main content with any additional content/instructions/etc. falling after the primary function of the page so you're not throwing your AT users over any content that isn't header-type stuff.
  61. powrsurg
    Feb 10 15:03
    Yeah, but now that we've unified things the intent of the page has split. We used to have login and register as different pages and this was done to make it more Facebook like ...
  62. powrsurg
    Feb 10 15:04
    We have ways to make the content on the left shift based on the client. They get alternative login URLs just for them.
  63. FionaTG
    Feb 10 15:04
    That's an even better reason to not skip it - it sounds important
  64. garcialo
    Feb 10 15:04
    @ FionaTG :+1:
  65. powrsurg
    Feb 10 15:05
    yeah ... I think so. Wish we considered that at the time
  66. powrsurg
    Feb 10 15:06
    when there is no # in the URL then it's just the normal page load
  67. StommePoes
    Feb 10 15:19
    IE has a bug on skip link destinations based on styling. Blink's (Chrome's) is inherited from Webkit, who was begotten from KHTML, who was begotten by...
  68. StommePoes
    Feb 10 15:19
    The negative tab index just works for both bugs everywhere, so nice enough to use.
  69. StommePoes
    Feb 10 15:20
    @steveFaulkner @michielBijl + any spec people, I'm here https://www.w3.org/TR/accname-aam-1.1/#mapping_additional_nd_name and I'm clicking on these little arrow thingies called "Example" and they get focus but they don't do anything. Are they supposed to do anything?
  70. MichielBijl
    Feb 10 15:21
    Arrow thingies?
  71. MichielBijl
    Feb 10 15:21
    §?
  72. MichielBijl
    Feb 10 15:22
    Or do you mean under https://www.w3.org/TR/accname-aam-1.1/#terminology
  73. StommePoes
    Feb 10 15:22
    Autofocus also pisses off dragon users and many keyboarders-- if we see a page with things that look focusable and we start tabbing and esp if the JS loads late (like it does on the twitter login page often) then we think we're tabbing from the top but actually from your autofocus, or we start tabbing and then autofocus hijacks us. That sucks most of the time.
  74. MichielBijl
    Feb 10 15:22
    Comment:
  75. MichielBijl
    Feb 10 15:23
    Those are detail/summaries, but seem broken :/
  76. StommePoes
    Feb 10 15:23
    arrow_thingies.png
  77. StommePoes
    Feb 10 15:23
    yeah those
  78. StommePoes
    Feb 10 15:25
    Didn't Paciello Group blog have a human-English version of this page on accessible name calculation?
  79. garcialo
    Feb 10 15:25
    @StommePoes Wouldn't the autofocus issue be mitigated by having sufficient focus indication?
  80. StommePoes
    Feb 10 15:26
    it's not so much the not-finding bit (esp in a browser like Chromium which has a pretty good focus indicator), it's the "I didn't expect someone to grab my shoes out from under me" bit
  81. StommePoes
    Feb 10 15:26
    and for example the login page of github does this
  82. StommePoes
    Feb 10 15:26
    oh not github, what was it
  83. StommePoes
    Feb 10 15:26
    It was a black page where you were autofocussed into the field Make an account
  84. StommePoes
    Feb 10 15:27
    and I always started tabbing to try to get to Sign In (which was in the header) before realising I had to shift-tab halfway out the page for that
  85. StommePoes
    Feb 10 15:27
    github.com is white so it wasn't that page. It also had really huge fonts.
  86. StommePoes
    Feb 10 15:27
    oh it is github
  87. StommePoes
    Feb 10 15:27
    when you're not signed in.
  88. garcialo
    Feb 10 15:27
    yeah, they do some autofocus
  89. garcialo
    Feb 10 15:27
    yeah, I think we just had the same exact experience =p
  90. garcialo
    Feb 10 15:28
    So is it a "Visitor starts using page before they realize that autofocusing has been done?"
  91. StommePoes
    Feb 10 15:29
    People start using a page the moment there visually looks to be a page worth using
  92. powrsurg
    Feb 10 15:29
    It seems like a problem where a person interacted with a page before DOMContentReady was called. I don't know how you could detect something like that
  93. StommePoes
    Feb 10 15:30
    you ever open an article link and start scrolling right away, only to have the way-later-loading ads hijack everything? :P
  94. garcialo
    Feb 10 15:30
    Yeah, of course.
  95. StommePoes
    Feb 10 15:30
    People don't get told when DOMContent is ready. They start to use as soon as they think they can.
  96. StommePoes
    Feb 10 15:31
    I think the github main page is an example of autofocus as an abomination-- the page cannot tell if the user wants to make an account, just assumes it. Google search page, and possibly login-only pages like Twitter web are examples of where it likely does more good than evil.
  97. StommePoes
    Feb 10 15:32
    I know Deborah feels similarly.
  98. jnurthen
    Feb 10 15:34
    If you were using JS to do your autofocus then all you have to do it look to see if there is already a focus in the page before you move the focus. If there is then don't move the focus with your JS. If the page has loaded and the user hasn't interacted with it yet then there wouldn't be a focus and you are safe to move it.
  99. StommePoes
    Feb 10 15:34
    Hm, that's an idea.
  100. garcialo
    Feb 10 15:34
    Oh, nice idea.
  101. garcialo
    Feb 10 15:34
    @jnurthen You're too awesome for your own good.
  102. powrsurg
    Feb 10 15:35
    Oh I know they don't get told when DOMContent is ready. I meant it would programmatically difficult to call something to detect if any keystrokes occurred to prevent the autofocus from happening if they're already using the page
  103. StommePoes
    Feb 10 15:35
    It still doesn't prevent me from needing to shift-tab out to get to a login (so the principle of, your auto-focus page ought to be REAAAAALLLY 1-reason-to-use), but it could help the user-started-moving-early bit.
  104. StommePoes
    Feb 10 15:35
    I always assumed twitter added it later simply because their JS is so bloated, it really just takes that long for it to load.
  105. StommePoes
    Feb 10 15:37
    I'd say it's an issue straddling between "give the user as few choices as possible to improve usability" and "making incorrect assumptions about the user making them rage and throw the computer out the window"
  106. powrsurg
    Feb 10 15:49
    I think it stems from a lack of a focus on performance and actual testing of software and just focusing on NEW FEATURES. A good autofocus would happen superfast and would have good focus management so you would at least know where you are in the page instead of having things hijacked.
  107. FionaTG
    Feb 10 16:35
    Can I ask you guys a favour? I'm authoring a course for Pluralsight on accessibility and have a few worked examples.
    Anyone spot any issues with the accessibility of this page? It's like a hotel booking form: http://myaccessible.website/pluralsight-example/booking.html
  108. StommePoes
    Feb 10 16:37
    sort of a minor thing, I wouldn't say don't use a star for required since that's practically a standard, but know some people have to make their punctuation more verbose to get those (with specifically screen readers)
  109. StommePoes
    Feb 10 16:38
    I'm curious, why the spans for visible labels and then aria-label?
  110. StommePoes
    Feb 10 16:39
    date star is after the end of the last input, but all other inputs put the star right after the visible label. I'd likely miss the first date star visually.
  111. FionaTG
    Feb 10 16:40
    I've used aria-label only in the cases where the spans don't explain well. For example expiry date has two selects, but one label and I'd like to explain which is month and which is year
  112. StommePoes
    Feb 10 16:40
    If I were on very high mag, I prefer labels not too far away from the inputs. Also a nit pick, but it made me wonder why location is so wide... localisation?
  113. StommePoes
    Feb 10 16:42
    I can't get the list to appear for desired breakfast times.
  114. StommePoes
    Feb 10 16:42
    Is that dependent on me filling out an earlier input first?
  115. StommePoes
    Feb 10 16:43
    I'm on chromium/linux
  116. FionaTG
    Feb 10 16:43
    @StommePoes Larger font support mainly, though I could just be less lazy and have it cope better, I hadn't thought about magnification with regard to that design
  117. FionaTG
    Feb 10 16:44
    @StommePoes On closer inspection, that's because I'd forgotten to put any options in it yet - oops. This is still somewhat of a work in progress!
  118. StommePoes
    Feb 10 16:44
    Ah ok.
  119. StommePoes
    Feb 10 16:44
    I saw a content tag and wondered, you're using web components?
  120. StommePoes
    Feb 10 16:44
    card type also empty.
  121. FionaTG
    Feb 10 16:45
    Not using web components
  122. StommePoes
    Feb 10 16:45
    Even tho hte labels are physically far away, I can click them to get focus on the input. but then the ones like expiry date don't have that because spans.
  123. FionaTG
    Feb 10 16:45
    Ah, nice spot - I really have been lazy with the selects...
  124. StommePoes
    Feb 10 16:45
    oh, maybe my browser is just showing me an internal representation.
  125. jkva
    Feb 10 16:46
    Interesting CAPTCHA-ish system, but can't really use it on a screen reader
  126. jkva
    Feb 10 16:46
    blob
  127. jkva
    Feb 10 16:47
    alt= an image of a resistor where the user has to match colors to resistor values in order to post a comment on adafruit.com
  128. jnurthen
    Feb 10 16:47
    @StommePoes IMO - how autofocus should really be done is using the autofocus attribute. Then browsers deal with it (and could actually have a preference to allow users to turn off the behaviour if they wanted to). Obviously they would have to be talked into doing that but in the meantime i imagine an addon could remove the attribute. Far better than JS anyway.
  129. StommePoes
    Feb 10 16:47
    normally I would say be careful with a button without a type in a form (the cancel button) but looks like you catch that with JS
  130. FionaTG
    Feb 10 16:47
    @StommePoes Hmm, that's a good point on the expiry dates. Can't really associate the label with the field without screen readers stating it twice though...
  131. jnurthen
    Feb 10 16:48
    @jkva So many issues in the CAPTCHA. Looks like they are trying to exclude as many people as they can
  132. StommePoes
    Feb 10 16:48
    yeah it's tricky, I ran into the same issues with multi-input dates back in the day
  133. FionaTG
    Feb 10 16:49
    @StommePoes I suppose label associated with the first select and then an aria-label on the second may be the best solution
  134. StommePoes
    Feb 10 16:49
    "and could actually have a preference to allow users to turn off the behaviour if they wanted to" <-- I've wished for this for so long
  135. jnurthen
    Feb 10 16:51
    I wonder if it is possible to simply remove it in an addon/extension before the browser behaviour kicks in.
  136. jnurthen
    Feb 10 16:51
    should be trivial to write
  137. stevefaulkner
    Feb 10 16:52
    @jnurthen in case you missed it follow on from alt/title discussion last night https://www.paciellogroup.com/blog/2016/02/short-note-on-use-of-alt-and-the-title-attribute/
  138. jnurthen
    Feb 10 16:52
    @stevefaulkner can you detail where title isn't accessibility supported (when alt is missing)
  139. StommePoes
    Feb 10 16:56
    Yeah what I think I did was label on the first and had aria-describedby for the second text, but that was kinda more with speech users in mind
  140. StommePoes
    Feb 10 16:56
    though they can also otherwise just tab to the next one too
  141. FionaTG
    Feb 10 16:57
    @StommePoes Makes sense, thanks :)
  142. StommePoes
    Feb 10 16:57
    So, as a keyboarder I should fill in the dates, with a mouse I can click them?
  143. jnurthen
    Feb 10 16:57
    @stevefaulkner - you state "Absence of an alt attribute results, in some screen reading screen reader software, not conveying the <img> to users." can you detail what screen reading software because I have never seen this.
  144. StommePoes
    Feb 10 16:57
    Or is there a keyboard way I don't know? Most sites assume I'm as stupid as I am and let me tab into them
  145. StommePoes
    Feb 10 16:58
    anyway, that's all I noticed with it. I didn't actually use it with high mag, I'm on Linux
  146. StommePoes
    Feb 10 16:58
    But that's always interesting
  147. stevefaulkner
    Feb 10 17:00
    @jnurthen will do
  148. FionaTG
    Feb 10 17:01
    @StommePoes jQuery UI Datepicker is usually pretty keyboard friendly though yes, you can just type the date in
  149. StommePoes
    Feb 10 17:01
    I vaguely seem to recall back with the JAWS demo (so this would have been 10) that an img with alt="" and title read out the filename. So would be a good thing to check again (unless you already have @jNurthen and got, with default settings, the title text)
  150. jnurthen
    Feb 10 17:01
    @stevefaulkner just one will do to convince me :) (to be clear I NEVER recommend not supplying alt - but I really think title should work just fine)
  151. StommePoes
    Feb 10 17:02
    jQuery datepicker prolly uses some secret keystrokes I don't know but are written down in some spec somewhere :P
  152. StommePoes
    Feb 10 17:02
    Me, I'm like 90% of users: I mostly tab. When that fails, I arrow. When that fails, I start hitting random special keys like alt and crtl. When that fails, I ctrl-w
  153. jnurthen
    Feb 10 17:02
    @StommePoes alt="" and title set should have the image marked as decorative. I'm interested in the case with no alt set, but a title set.
  154. StommePoes
    Feb 10 17:03
    oh
  155. StommePoes
    Feb 10 17:03
    <img src="foo" title="a foobar">?
  156. jnurthen
    Feb 10 17:03
    @StommePoes yes
  157. FionaTG
    Feb 10 17:04
    @StommePoes Ctrl and arrows seems to be the magic combination in this case
  158. jnurthen
    Feb 10 17:04
    @StommePoes - yeah it is documented here - http://api.jqueryui.com/datepicker/
  159. jnurthen
    Feb 10 17:04
    @StommePoes @FionaTG I know they are rewriting it though as I think everyone agrees it isn't ideal!
  160. FionaTG
    Feb 10 17:05
    @jnurthen Good to know!
  161. StommePoes
    Feb 10 17:05
    yay, works
  162. StommePoes
    Feb 10 17:05
    the jQuery thing
  163. StommePoes
    Feb 10 17:13
    I hope they rewrite tab-panels so they stop hijacking my down arrows!
  164. StommePoes
    Feb 10 17:13
    Man I see that more and more on like house sale sites
  165. StommePoes
    Feb 10 17:13
    bugs me to no end
  166. powrsurg
    Feb 10 17:13
    Does anyone have any good examples for providing sighted keyboard users with a list of keyboard commands?
  167. StommePoes
    Feb 10 17:13
    pgDown is not a decent substitute
  168. StommePoes
    Feb 10 17:13
    I guess twitter and duckduckgo
  169. StommePoes
    Feb 10 17:13
    with "?"
  170. jnurthen
    Feb 10 17:14
    the down arrow on tab panels is defined in the APG
  171. StommePoes
    Feb 10 17:14
    oh ddg doesn't do the ? anymore
  172. StommePoes
    Feb 10 17:14
    I know it's defined there
  173. jnurthen
    Feb 10 17:14
    please log an issue against it if this is causing an issue
  174. StommePoes
    Feb 10 17:14
    it also sucks huge hairy balls
  175. StommePoes
    Feb 10 17:14
    I did
  176. StommePoes
    Feb 10 17:14
    long ago
  177. jnurthen
    Feb 10 17:14
    do you remember which bug tracker ;)
  178. StommePoes
    Feb 10 17:14
    nobody cares because they never have to read long panels on a small screen
  179. StommePoes
    Feb 10 17:14
    it was via github
  180. StommePoes
    Feb 10 17:14
    as an issue
  181. jnurthen
    Feb 10 17:15
    ok... i'll search is out.
  182. StommePoes
    Feb 10 17:15
    like, issue issue, those aren't necessarily bugs.
  183. StommePoes
    Feb 10 17:15
    I ahd the link earlier today actually
  184. StommePoes
    Feb 10 17:15
    w3c/aria#113
  185. jnurthen
    Feb 10 17:15
    yeah - got it
  186. StommePoes
    Feb 10 17:16
    I mean, with some large/long panels, you'll see what I mean.
    Having the next Tab move to the panel itself though would work.
  187. jnurthen
    Feb 10 17:17
    now tablist supports aria-orientation I see no need to support up/down on tab lists which aren't vertical. Would that help?
  188. StommePoes
    Feb 10 17:18
    Depends, do UAs support that? And also, I'm filing that as a sighted keyboarder. How does a sighted grandma using keyboard know left/right arrows will move up/down? (I would love just left/right but I'm aware people would get confuzled)
  189. StommePoes
    Feb 10 17:18
    Mostly because traditionally, tabs were tab-focusable as they were often made up of anchors
  190. StommePoes
    Feb 10 17:18
    sometimes buttons
  191. StommePoes
    Feb 10 17:19
    so the web taught us to single-click, and the web taught us to tab.
  192. jnurthen
    Feb 10 17:19
    thats not what i meant. I mean on a traditional tab interface left/right would change tabs, up down would scroll the page as usual
  193. StommePoes
    Feb 10 17:19
    It'll be a while before web users realise desktop behaviours are comoing
  194. jnurthen
    Feb 10 17:19
    on a "vertical" tab up/down would change tabs, left/right would do nothing
  195. StommePoes
    Feb 10 17:20
    then we still need to be able to focus on the panels so we can scroll down long panels, right?
  196. StommePoes
    Feb 10 17:20
    The tabs may be on the side (that is what they mean, right?) but the panels can still go offscreen to the bottom.
  197. jnurthen
    Feb 10 17:20
    for vertical tabs yes but these are exceedingly rare
  198. StommePoes
    Feb 10 17:20
    I haven't seen vert tabs in a while
  199. StommePoes
    Feb 10 17:21
    mostly full interfaces, which don't seem to use the tab-panel setup. But visually it looks like tabs.
  200. jnurthen
    Feb 10 17:21
    it would solve your horizontal tab problem which is the 99% case right?
  201. StommePoes
    Feb 10 17:21
    yeah.
  202. StommePoes
    Feb 10 17:21
    Most websites I run into with tab panels are using horizontal.
  203. StommePoes
    Feb 10 17:21
    and often the panels don't have any native focusables in them... headings, images, text.
  204. jnurthen
    Feb 10 17:21
    IMO we need to focus on the 99% - if we focus on the corner cases we end up with horribly overengineered solutions
  205. jnurthen
    Feb 10 17:22
    I'll add this suggestion to the issue and add it to the agenda for an upcoming meeting
  206. StommePoes
    Feb 10 17:23
    zomg HUGE HUG
  207. StommePoes
    Feb 10 17:23
    I would be sooooooo happy
  208. StommePoes
    Feb 10 17:23
    Me. Happy.
  209. StommePoes
    Feb 10 17:23
    Two words rarely seen next to each other without a negative somewhere.
  210. StommePoes
    Feb 10 17:24
    If you're coming to CSUN I'll give you a Stomme Poes pin
  211. jnurthen
    Feb 10 17:24
    I am at CSUN
  212. StommePoes
    Feb 10 17:24
    w00ts
  213. MichielBijl
    Feb 10 17:24
    Already? :P
  214. jnurthen
    Feb 10 17:24
    LOL
  215. StommePoes
    Feb 10 17:24
    He's fast
  216. jnurthen
    Feb 10 17:24
    writing my presentations at the moment :(
  217. MichielBijl
    Feb 10 17:25
    You don't want to write a presentation?
  218. MichielBijl
    Feb 10 17:25
    Want to swap with me? :P
  219. jnurthen
    Feb 10 17:25
    I hate writing them - ok giving them but I am normally super last minute
  220. jnurthen
    Feb 10 17:26
    I also have to do the demos as my colleague who normally does them isn't coming this year
  221. jnurthen
    Feb 10 17:26
    and when you don't use a screen reader every day giving screen reader demos in front of people who do use it every day is a little daunting
  222. StommePoes
    Feb 10 17:27
    zomg yeah
  223. StommePoes
    Feb 10 17:27
    from now on, SR-only ALL the things
  224. jnurthen
    Feb 10 17:28
    I am ok with JAWS and NVDA as long as I don't try to get too fancy
  225. StommePoes
    Feb 10 17:29
    heh
  226. FionaTG
    Feb 10 18:25
    As someone currently recording screen reader demos for Pluralsight - I feel your pain!
  227. garcialo
    Feb 10 18:37
    Heck, even as someone that uses a screen reader pretty much everyday for testing, I don't feel comfortable giving those demos.
  228. jnurthen
    Feb 10 18:38
    @garcialo I use one pretty frequently myself - but nowhere near as much as someone who relies on one.
  229. garcialo
    Feb 10 18:38
    Exactly
  230. jnurthen
    Feb 10 18:38
    at least no one is asking me to read a braille display
  231. FionaTG
    Feb 10 18:46
    "So, as you can see here ... uh ... dots"
  232. jpdevries
    Feb 10 18:46
    "so braille is a series of…dots?"
  233. jpdevries
    Feb 10 18:46
    “I invented braille!” - Al Gore
  234. MichielBijl
    Feb 10 18:47
    Those conversations always get of on a bumpy start…
  235. MichielBijl
    Feb 10 18:47
    jnurthen at least no one is asking me to read a braille display
  236. jnurthen
    Feb 10 18:48
    maybe we should rename this group to a11yPuns
  237. jkva
    Feb 10 18:48
    sarcastica11y
  238. jnurthen
    Feb 10 18:48
    i like that ;)
  239. MichielBijl
    Feb 10 18:49
    I'm sure some members won't see the fun in that…
  240. zakim-robot
    Feb 10 18:51
    [karlgroves] :laughing:
  241. StommePoes
    Feb 10 18:53
    karl needs to make a11y punx
  242. powrsurg
    Feb 10 19:55
    So Facebook just came up with auto captions for video ads ...
  243. jasonday
    Feb 10 20:38
    Karl Groves - I thought I recognized the name from our email exchange today
  244. jasonday
    Feb 10 20:40
    Question for the group - corporate a11y training. Any experiences? Is webaim the defacto group for that sort of thing?
  245. zakim-robot
    Feb 10 20:51
    [marcysutton] I think there are quite a few companies that do that sort of thing. TPG, Deque and SSB Bart to name a few.
  246. MichielBijl
    Feb 10 20:54
    Knowability?
  247. garcialo
    Feb 10 20:55
    Knowbility, and yes they also do training
  248. jnurthen
    Feb 10 20:55
    there's also Derek Featherstone's Simply Accessible too
  249. jasonday
    Feb 10 20:56
    awesome, I didn't know about Knowbility and forgot about Simply Accessible
  250. jkva
    Feb 10 21:11
    You'd think http://www.globalaccessibilityawarenessday.org/ would be more something like globa11y.org
  251. jasonday
    Feb 10 21:15
    how about accessibility for javascript programming... a11y-OOP
  252. jkva
    Feb 10 21:15
    =D groan
  253. jkva
    Feb 10 21:16
    That would be terrib11y
  254. powrsurg
    Feb 10 21:16
    and globalaccessibilityawarenessday.org's home page has 2 elements without sufficient color contrast :p
  255. jasonday
    Feb 10 21:16
    @jkva arguaba11y, yes
  256. jkva
    Feb 10 21:16
    hahaha
  257. powrsurg
    Feb 10 21:22
    ... actually why does aXe say that the links in that callout box don't have sufficient color contrast? The links have the same color as every other link on that page, and the same background too.
  258. zakim-robot
    Feb 10 21:41
    [marcysutton] Looks like it’s actually a warning, but we haven’t added support for warnings in the extension yet. dequelabs/axe-core#116
  259. MichielBijl
    Feb 10 21:45
    @jasonday an a11y oop could be a basketball thing too ;)
  260. garcialo
    Feb 10 21:46
    @MichielBijl That one was painful.
  261. jasonday
    Feb 10 21:46
    @MichielBijl - exactly. I was playing off of Object Oriented Programming in javascript
  262. garcialo
    Feb 10 21:46
    ah, I thought yours was a serious question =p
  263. jnurthen
    Feb 10 21:53
    None of the links on globalaccessibilityawarenessday.org meet the colour contrast ratio
  264. jnurthen
    Feb 10 21:57
    The ones in the box have white as the background so aXe can actually check them (so it shows an error). The rest have a gradient (or image) as their background so aXe ignores them. Their real background colour varies as their is a grey transparent image on the body element. My checker estimates #f8f8f8-#ffffff for the background colour of the base page so all the blue links fail with a ratio of somewhere between 3.67-3.89:1
  265. jasonday
    Feb 10 22:30
    last pun of the night - a11y for Vlasic pickles, dilly da11y