Archive index

A11y Slackers Gitter Channel Archive 21st of August 2015

What fresh hell is THIS now? - Patrick Lauke
  1. zakim-robot
    Aug 21 00:12
    [Rick Brown, a11y] @alice this podcast talks about that, including an instant messenger that only allows emoticons: http://www.theallusionist.org/allusionist/emoji
  2. bkardell
    Aug 21 00:21
    @RickSBrown lol
  3. zakim-robot
    06:13
    [jitendra, a11y] Semantic code on stackoverflow
  4. StommePoes
    06:18
    What would you use?
  5. zakim-robot
    06:40
    [jitendra, a11y] I think table
  6. StommePoes
    06:42
    Oh, what does the whole page look like?
  7. StommePoes
    06:42
    I thought you meant the single div with the number.
  8. StommePoes
    06:43
    ah this one http://stackoverflow.com/10M
  9. StommePoes
    06:44
    hm, there's only three main things. One could get away with three p's, a list of three items, maybe a definition list or 2-column table but I think table would be the last things I'd consider, because it's a short list and no applicable headings.
  10. StommePoes
    06:56
    Man, I have all these shops with tab-panels and none of them have the right keyboarding... and I'm leaving the job in like 9 days
  11. StommePoes
    06:56
    Wonder if I'm able to fix that before I go, or if I should just strip all the aria stuff out instead so the next developer doesn't deal with it
  12. stevefaulkner
    08:20

    A11ySlackers chat log 20th August 2015 http://w3c.github.io/a11ySlackers/archives/2015/08/2015-08-20.html

  13. zakim-robot
    09:52
    [heydon, a11y] I’m quite new to VoiceOver OSX testing (in the past I’ve tested mostly with iOS). I get that I can cycle through headings with VO+H, but how do I actually move focus to that heading so when I tab, I focus the next focusable element under that heading? Is that possible?
  14. zakim-robot
    12:45
    [Katy Moe, a11y] Is <main role=“main”> a good way of marking up a main element?
  15. StommePoes
    12:47
    nah
  16. StommePoes
    12:47
    <main>'s good
  17. StommePoes
    12:47
    unless you know you'v got lots of old-IE users
  18. StommePoes
    12:47
    in which case you're doing <main role="main> + document.createElement('main')
  19. StommePoes
    12:47
    probably
  20. zakim-robot
    12:48
    [Katy Moe, a11y] The HTML5 spec says "Authors are advised to use ARIA role="main" attribute on the main element until user agents implement the required role mapping."
  21. StommePoes
    12:48
    so for Enterprise and libraries and schools actually I'd consider adding the role="main", but technically it's suppsoed to be a native role now
  22. StommePoes
    12:48
    yeah, it's a newer role than a lot of other roles
  23. StommePoes
    12:48
    but it's been a few years now
  24. zakim-robot
    12:49
    [Katy Moe, a11y] Cool, is there somewhere I can check which versions of IE don’t implement it?
  25. zakim-robot
    12:49
    [Katy Moe, a11y] We support IE9+
  26. StommePoes
    12:49
    So like deciding if you "can use" new css3 things without a fallback, it may depend most on who your audience is
  27. StommePoes
    12:49
    hm...
  28. LjWatson
    12:49
    Agree with @StommePoes - AFAIK IE doesn't support <main> in any version.
  29. StommePoes
    12:49
    there probably is, @stevefaulkner would know
  30. StommePoes
    12:49
    @LjWatson not even 11?
  31. zakim-robot
    12:49
    [Katy Moe, a11y] MDN says IE doesn’t support it
  32. StommePoes
    12:51
    for 9 and below, yeah, but 10 and 11? surprises me
  33. StommePoes
    12:51
    I thought main got added when they added footer, header etc
  34. zakim-robot
    12:52
    [Katy Moe, a11y] status.modern.ie says it’s not supported in IE
  35. zakim-robot
    12:52
    [Katy Moe, a11y] only Edge
  36. StommePoes
    12:53
    wow
  37. zakim-robot
    12:53
    [Katy Moe, a11y] It also says that ‘HTML Sections in Accessibility API’ is not supported in either IE or Edge - I think that means that AT won’t be able to access the main role anyway
  38. zakim-robot
    12:54
    [Katy Moe, a11y] https://dev.modern.ie/platform/status/htmlsectionsinaccessibilityapi/?filter=f3f0000bf&search=main
  39. LjWatson
    12:55
    Worth noting that Edge is not accessible to screen reader users on Windows at all, except for Narrator.
  40. zakim-robot
    12:55
    [Katy Moe, a11y] So to return to my original question, I guess it is redundant to add role=“main”, as the only browser that would need it doesn’t support the main role anyway!
  41. LjWatson
    12:56
    @Katy No, you should add it. IE exposes role="navigation" ok. What it doesn't do is expose that role automatically when you just use <main>
  42. StommePoes
    12:57
    and so then theoretically div role="main" would mean the same to IEs that knew what the role was. Is it then IE's under 9 or 8 that do not even expose authored roles?
  43. zakim-robot
    12:58
    [Katy Moe, a11y] @ljwatson Thanks - that makes sense.
  44. LjWatson
    13:00
    @StommePoes Yes, <div role="main"> and <main role="main"> are effectively the same thing in IE. I don't recall when IE introduced support for ARIA landmarks.
  45. zakim-robot
    13:01
    [dsturley, a11y] IIRC it was added in IE8
  46. StommePoes
    13:01
    ah nice, but the main role (and the element) appeared later, yes?
  47. StommePoes
    13:02
    I don't know the internals of how browsers deal with landmark roles so I dunno if it matters when a role is added if roles in general are supported
  48. LjWatson
    13:02
    Most browsers support explicit landmarks now I think, and all except IE support implicit landmarks too.
  49. zakim-robot
    13:03
    [dsturley, a11y] implicit landmarks get a little wonky anyway, like <header> is only a landmark if it is not contained by <section> or <article>
  50. LjWatson
    13:06
    @dsturley header and footer must be scoped to <body> to be considered a landmark.
  51. StommePoes
    13:14
    Ah, so according to the Guardian, Oreos are "biscuits". No wonder you can't have cookies
  52. StommePoes
    13:15
    semantics schemantics
  53. LjWatson
    13:15
    @Katy @PatrickLauke confirms that <main> does not expose the correct role in IE11, and also discovered that Chrome doesn't either.
  54. zakim-robot
    13:17
    [Katy Moe, a11y] @ljwatson Thanks for that. Surprising that Chrome doesn’t do it properly. What’s the best way of checking these things for myself?
  55. StommePoes
    13:17
    Honestly, anything Chrome does do right, pleasantly surprises me.
  56. LjWatson
    13:18
    @Katy use an accessibility inspector like aViewer (paciellogroup.com/resources/aviewer)
  57. LjWatson
    13:18
    @StommePoes we're wondring if it's a regression in Chrome - since it's previously noted as supporting these implicit roles.
  58. LjWatson
    13:19
    @Katy the Chrome dev and a11y tools are also worth using if you're a Chrome person.
  59. zakim-robot
    13:20
    [Katy Moe, a11y] @ljwatson I don’t suppose you know of anything like aViewer that works on OSX?
  60. zakim-robot
    13:21
    [dsturley, a11y] OS X has one built in, Accessibility Inspector
  61. zakim-robot
    13:23
    [Katy Moe, a11y] @dsturley: Ah, I couldn’t get that to work for Chrome. But the Chrome a11y dev tools are great.,
  62. StommePoes
    13:24
    also nice that those dev tools work on linux
  63. StommePoes
    13:25
    of chrome
  64. stevefaulkner
    13:49
    @patrickhlauke you sure chrome does not implement <main> role semantics??? are you looking in right place?
  65. stevefaulkner
    13:51
    @dsturley the header/footer mapping is by design, due to how header/footer is defined in html and used, having all instances as landmarks would be too verbose
  66. stevefaulkner
    14:07
    @LjWatson chrome does expose main as per http://w3c.github.io/aria/core-aam/core-aam.html#role-map-main (same way it exposes role=main) @patricklauke was having issue with his tool
  67. zakim-robot
    14:12
    [dsturley, a11y] yeah it makes sense, i just see it misused outside of <section> and <article> frequently
  68. patrickhlauke
    14:13
    his tool? not my fault if aViewer is flaky :clap:
  69. patrickhlauke
    14:14
    so, to recap - according to chrome://accessibility tree dump, the correct role is exposed via IA2; running NVDA over Chrome actually announces main etc correctly; it's just that for some reason aViewer isn't showing me any IA2 for chrome (though it does just fine for Firefox)...
  70. zakim-robot
    14:15
    [Katy Moe, a11y] Okay, thanks for clarifying
  71. stevefaulkner
    14:22
    @kmoe I removed the advice in the HTML 5.1 spec about adding role=main a week or so ago w3c/spork@ee00e6a but for some reason hasn't published yet
  72. zakim-robot
    14:24
    [Katy Moe, a11y] @stevefaulkner Thanks, I noticed it had been there since at least 2012 :simple_smile:
  73. stevefaulkner
    14:26
    @kmoe yeah when i first wrote the spec for main it was appropriate :-)
  74. zakim-robot
    14:28
    [Katy Moe, a11y] So does that mean I shouldn’t be adding role=“main” after all? Or just that the spec is no longer making a comment on what people need to do to support IE?
  75. zakim-robot
    14:39

    [Karl Groves, a11y] Keep in mind ARIA roles exist to add necessary semantics for cases where they don’t exist. So, if you’re working in HTML then roles like ‘main’, ‘button’, ‘heading’ don’t make any sense (for new work) because those semantics can be communicated to assistive technologies using existing HTML elements.

    But: What about SVG? Maybe “main” is still unnecessary, but there’s no such thing as a button or a heading in SVG.

  76. zakim-robot
    14:41
    [Katy Moe, a11y] @karlgroves: What do you mean by “for new work”? Do you mean “for new browsers”? Because the case for adding role=“main” is in order to support browsers like IE that don’t infer the ARIA semantics from the HTML elements properly.
  77. zakim-robot
    14:48
    [Karl Groves, a11y] What I mean by “new work” is entirely new. Sometimes there might be times when you gotta remediate stuff that already exists and adding a role is far less intrusive than changing markup. A good example would be the ubiquitous <div> that’s got JS events bound to it to behave like a button. There might also be a ton of CSS and stuff on the div that would b0rk if a <button> took its place, but not if it was <div role=“button”>
  78. zakim-robot
    14:50
    [Karl Groves, a11y] So, more direct to your question: poor browser support is a really good reason to add roles to stuff - and the lagging support in IE was a great reason to use role=“main”. If you’re in a situation where lots of users come by with legacy versions of IE, it might make sense to still use it
  79. zakim-robot
    14:51
    [johnbhartley, a11y] WCAG 1.4.3 Contrast Question. Is placeholder held to the same contrast standard as any other text? Realistically, the placeholder text would be read with a screen reader, so folks using AT would be fine, but for those that have trouble seeing low contrast, it seems like placeholder needs to be held to that same 4.5:1 contrast ratio. Thoughts?
  80. zakim-robot
    14:52
    [Karl Groves, a11y] @johnbhartley: First question: What is the purpose of the placeholder?
  81. zakim-robot
    14:52
    [Katy Moe, a11y] @karlgroves: According to status.modern.ie, no versions of IE support the main semantics, so it’s not just legacy versions.
  82. zakim-robot
    14:53
    [Karl Groves, a11y] blames @stevef
  83. zakim-robot
    14:53
    [johnbhartley, a11y] @karlgroves: currently it is just placeholder text for where someone will put a promo code. There is a label that defines it and is visible, but the placeholder is being used to identify what goes inside the input
  84. zakim-robot
    14:54
    [Katy Moe, a11y] @johnbhartley: The Understanding document states that placeholders are held to the same contrast ratio (http://www.w3.org/TR/UNDERSTANDING-WCAG20/visual-audio-contrast-contrast.html)
  85. zakim-robot
    14:54
    [Karl Groves, a11y] OK, so it really is sort of just an example?
  86. zakim-robot
    14:54
    [Thomas Logan, a11y] Hey everyone we just announced NYC’s first accessibility camp “NYC's first accessibility camp Sept 26. Register now, 50 spaces available. $10 https://www.eventbrite.com/e/a11y-camp-nyc-tickets-17611972885 … Details: http://a11ynyc.com/camp/ “ Please help spread the word
  87. zakim-robot
    14:54
    [Karl Groves, a11y] Yes, it should still meet contrast requirements
  88. zakim-robot
    14:54
    [Karl Groves, a11y] @johnbhartley: I have an example of meeting color reqs for placeholder. BRB
  89. zakim-robot
    14:55
    [johnbhartley, a11y] @karlgroves: yes, the placeholder is currently an example. Perfect, I thought I'd read that somewhere, but couldn't find the specific text saying "yes, placeholders too" :smile:
  90. zakim-robot
    14:55
    [Thomas Logan, a11y] If you are interested in presenting at a11ynyc camp here is the speaker form - https://docs.google.com/a/equalentry.com/forms/d/1oX_5Ui4_6uz80-6MzeGwjLYG9l7ZKvbaxdTeFCmEPjY/viewform?c=0&w=1
  91. zakim-robot
    14:55
    [Francis Storr, a11y] @techthomas: there’s also an @events channel for events.
  92. zakim-robot
    14:55
    [Karl Groves, a11y] @johnbhartley: http://jsfiddle.net/karlgroves/k8Lvjwo5/
  93. zakim-robot
    14:55
    [Thomas Logan, a11y] @fstorr thanks
  94. zakim-robot
    14:56
    [Katy Moe, a11y] @johnbhartley: "Note 3: The minimum contrast success criterion (1.4.3) applies to text in the page, and placeholder text is text in the page. If used, placeholder text needs to provide sufficient contrast."
  95. zakim-robot
    14:56
    [Karl Groves, a11y] In full disclosure hats off to Ted Drake for the fiddle example. I stole an example he made and put it in JS fiddle form
  96. zakim-robot
    14:56
    [Karl Groves, a11y] @techthomas: I’ll be there
  97. zakim-robot
    14:57
    [johnbhartley, a11y] awesome, thanks @katy and @karlgroves !
  98. zakim-robot
    14:58
    [Francis Storr, a11y] @johnbhartley @katy @karlgroves this is interesting. IIRC, @alice mentioned recently that the Chrome accessibility extension purposely doesn’t check placeholder text for contrast. Based on that jsfiddle example, there’s only a small amount of change needed for it to meet the contrast rules.
  99. zakim-robot
    14:59
    [Karl Groves, a11y] @fstorr: Yeah, it isn’t a huge difference to meet AA there.
  100. zakim-robot
    15:01
    [Thomas Logan, a11y] @karlgroves: awesome look forward to seeing you!
  101. zakim-robot
    15:01
    [Francis Storr, a11y] @karlgroves: makes me wonder why browser manufacturers don’t increase the contrast so it’s compliant out of the box.
  102. zakim-robot
    15:01
    [Karl Groves, a11y] Because designers! :wink:
  103. zakim-robot
    15:02
    [Karl Groves, a11y] @techthomas: I’ll be flying home from boston, sleeping, and getting up at asscrack of dawn to drive up
  104. zakim-robot
    15:02
    [Thomas Logan, a11y] @karlgroves: thats exactly the kind of energy we’re looking for! unpredictable and exciting
  105. zakim-robot
    15:03
    [Thomas Logan, a11y] also can we convince designers dark themes are hip and stylish.. i’m obsessed with dark themes
  106. stevefaulkner
    15:09
    @kmoe the latest conformance requirements for use of ARIA in HTML http://w3c.github.io/html-aria/ say implicit semantics SHOULD NOT be used, but it is helpful to understand what the conformance requirement terminology means - this may be helpful http://www.paciellogroup.com/blog/2015/08/short-note-on-html-conformance-checking/
  107. zakim-robot
    16:26
    [Alice Boxhall, a11y] @fstorr re https://web-a11y.slack.com/archives/general/p1440169132005852 - yes, that's right: because browsers tend to have low contrast text for placeholders we don't ding people for not correcting that. It's a bit of a judgement call because obviously WCAG says the opposite...
  108. zakim-robot
    16:27
    [Alice Boxhall, a11y] however, I think we tend to overlook the nuance that the placeholder text needs to not look like actual text in order to be usable
  109. zakim-robot
    16:27
    [Alice Boxhall, a11y] Placeholder text with sufficient contrast can look like an actual input, which is confusing and noisy
  110. zakim-robot
    16:28
    [Alice Boxhall, a11y] I think there is more design work needed to come up with placeholder text styles which are universally accessible and usable
  111. zakim-robot
    16:31
    [Alice Boxhall, a11y] contrast is hard.png
  112. deborahgu
    16:35
    it would be cool if accessibility checkers, when they see title attributes in the usual incorrect suspects, or see placeholder text, pop up a message saying !!! danger Will Robinson !!! These are frequently misused attributes! if you are using them in these ways, that's great, but if you are using them in these other frequently misused ways, don't do it!
  113. deborahgu
    16:36
    placeholder would probably be a losing battle, because that one is a style choice. But title attributes are frequently just misinformation all over the web. The number of people I meet who think that title on <a> or <img> Is an accessibility benefitis just astonishing.
  114. zakim-robot
    16:36
    [Alice Boxhall, a11y] @deborahgu Right - so many people use placeholder text as label which is unusable and potentially inaccessible
  115. zakim-robot
    16:36
    [Alice Boxhall, a11y] and we can detect that easily
  116. zakim-robot
    16:36
    [Alice Boxhall, a11y] Similarly title actually
  117. deborahgu
    16:37
    right!
  118. zakim-robot
    16:37
    [Alice Boxhall, a11y] if the only acc name source is placeholder or title, could easily show a warning
  119. zakim-robot
    16:37
    [Alice Boxhall, a11y] files bugs
  120. deborahgu
    16:37
    (as a sighted user, I run into the usability problem with placeholder text and label all the time. It's one thing when it's simply username/password or search, but for any other form concept placeholder as label actually does screw me up.)
  121. deborahgu @deborahgu cheerleads Alice
  122. zakim-robot
    16:39
    [Alice Boxhall, a11y] @deborahgu The killer for me is the combo of placeholder used as label and form autofilling
  123. zakim-robot
    16:40
    [Alice Boxhall, a11y] Not even a disability access issue - bad for literally everyone
  124. deborahgu
    16:41
    yup. And then there's password managers/robo form fillers, which are (hopefully) becoming more prevalent. I use Lastpass which does a really good job but does sometimes guess wrong about what the field should be, and so if it auto fills incorrectly, but the label is placeholder, I have no idea.
  125. zakim-robot
    16:42
    [Alice Boxhall, a11y] @deborahgu ADT bug here: GoogleChrome/accessibility-developer-tools#230
  126. zakim-robot
    16:42
    [dsturley, a11y] aXe used to have that rule until they made me remove it :disappointed:
  127. zakim-robot
    16:42
    [dsturley, a11y] H65 says title is OK in certain places http://www.w3.org/TR/2015/NOTE-WCAG20-TECHS-20150226/H65
  128. zakim-robot
    16:43
    [Alice Boxhall, a11y] What about placeholder?
  129. zakim-robot
    16:43
    [Alice Boxhall, a11y] Title is less bad I think
  130. zakim-robot
    16:44
    [Alice Boxhall, a11y] Though weird if you're on a phone?
  131. zakim-robot
    16:44
    [dsturley, a11y] aria-label is just as bad, if not worse
  132. deborahgu
    16:44
    title is okay on forms.
  133. deborahgu
    16:45
    but for keyboard-users, voice users, and mobile users, either user agent manufacturers need to get it together and support some way to make it something that can be perceived in any way, or it should be pulled from the spec as "never supported".
  134. zakim-robot
    16:46
    [dsturley, a11y] I guarantee that people would stop using it if it was visible on focus
  135. zakim-robot
    16:46
    [dsturley, a11y] particularly since you can’t style the title tooltip
  136. zakim-robot
    16:47
    [dsturley, a11y] we have a hard enough time getting people to accept visual focus styles :confused:
  137. zakim-robot
    16:49
    [Alice Boxhall, a11y] @dsturley: Did you read http://radar.oreilly.com/2015/08/proposing-css-input-modailty.html ?
  138. zakim-robot
    16:49
    [Alice Boxhall, a11y] Do you think people would use them if they were keyboard-only?
  139. deborahgu
    16:50
    Alice, I wonder. I've spoken to a bunch of people who just assumed that the tooltip on images that you get from title was also the alt; these are people who WANTED them to be the same. But of course they have different use cases, which is a problem.
  140. deborahgu
    16:51
    You get the same problem on tumblr, where they assume that the alt and the caption should be the same. I'm not sure we've done a good job of educating the general sighted population of content creators that "the thing that you see that is associated with the image" actually probably shouldn't be the same as the alt. so I worry about anything that is not easily available to sighted mouse users, because that's a big reason people don't do good alt.
  141. deborahgu
    16:51
    They can't get to it themselves so they don't think about it.
  142. zakim-robot
    16:51
    [Alice Boxhall, a11y] @deborahgu Absolutely. I've recently had to explain the difference to people as well :confused:
  143. deborahgu
    16:51
    :/
  144. deborahgu
    16:52
    how much do most mouse-using sighted folks use the keyboard outside of forms? I actually have no idea. I assume that most of y'all never touch it.
  145. zakim-robot
    16:52
    [Alice Boxhall, a11y] I made https://chrome.google.com/webstore/detail/image-alt-text-viewer/hinbolcnfifkhlcehoakdledkfjiaeeg?hl=en as a quick and dirty way to visualise alt text
  146. zakim-robot
    16:53
    [Alice Boxhall, a11y] Oh, that logo. I'll never be a designer ;_;
  147. rodneyrehm
    16:53
    @deborahgu sounds like something we should ask @alice et all to add to the internal browser statistics engine (whatever it’s called)
  148. deborahgu
    16:54
    good point. That would be a really fascinating thing to know! I suppose it probably also gives heatmap-style information.
  149. deborahgu
    16:54
    hey, lookee, working draft does say not to use title. \o/ http://www.w3.org/html/wg/drafts/html/master/dom.html#the-title-attribute
  150. rodneyrehm
    16:55
    the only thing I know for sure is that different people will use a computer ind different ways. I know a guy using the edit menu’s copy command over CTRL+C - I know a guy not even knowing there was such a menu
  151. rodneyrehm
    16:56
    I know people happily using the mouse for everything, but then finding themselves hit tab to advance to the next input (likely because they learned that in DOS way back when)
  152. deborahgu
    16:56
    @alice it may be quick and dirty but I like it. ;) I was doing some similar things with stylish.
  153. deborahgu @deborahgu misses Opera Presto and its single key image toggles
  154. rodneyrehm
    16:56
    how most people use computers? in a weird, non-explicable way :)
  155. zakim-robot
    16:58
    [dsturley, a11y] @alice We did something very similar for a client project recently. The biggest problem we have with that technique is mobile.
  156. rodneyrehm
    16:59
    didn’t microsoft recently blog/ do something about that title-tooltip-on-mobile issue?
  157. zakim-robot
    17:00
    [dsturley, a11y] designers always wanting to suppress focus styles makes irrationally angry… good design has hover styles, so just apply to focus too :neutral_face:
  158. rodneyrehm
    17:00
    I think I’m mixing up something. I guess I was thinking about “Using aria-haspopup to simulate hover on touch-enabled devices” https://msdn.microsoft.com/en-us/library/jj152135%28v=vs.85%29.aspx
  159. zakim-robot
    17:00
    [Alice Boxhall, a11y] @dsturley What's the issue with mobile?
  160. zakim-robot
    17:01
    [dsturley, a11y] might not have a keyboard attached
  161. zakim-robot
    17:01
    [Alice Boxhall, a11y] What's the problem? No keyboard -> focus isn't interesting
  162. deborahgu
    17:02
    but without keyboard focus or hover, you can't get to hover/focus-only states on mobile
  163. zakim-robot
    17:02
    [Alice Boxhall, a11y] Why would you want those states on mobile?
  164. deborahgu
    17:03
    if you have something like an actionable pop-up on focus or hover
  165. deborahgu
    17:03
    hover over this for the metadata, or to see how to subscribe to this person, or to see how many likes this post has, or something
  166. zakim-robot
    17:03
    [Alice Boxhall, a11y] then your problem isn't focus/hover styles, it's that your UI assumes you can focus or hover, which you can't do on mobile
  167. deborahgu
    17:04
    well, yeah. That's why need more UI designers to come to accessibility /UI school ;)
  168. zakim-robot
    17:04
    [dsturley, a11y] you can focus with VoiceOver on iOS, its completely differently but it can be done
  169. zakim-robot
    17:04
    [Alice Boxhall, a11y] Doesn't VO show its own focus ring?
  170. rodneyrehm
    17:04
    well, you can focus non-input elements on iOS
  171. deborahgu
    17:04
    (my understanding is that hover/focus states like that are also really difficult for magnification)
  172. stevefaulkner
    17:04
    @deborahgu the HTML5 REC says same about title but is stronger (warning) http://www.w3.org/TR/html5/dom.html#the-title-attribute don't know why HTML51 has it styled as note , will fix
  173. deborahgu
    17:05
    rodneyrehm: how?
  174. rodneyrehm
    17:05
    <div tabindex=“-1” onclick=“”> I’m focusable</div>
  175. deborahgu
    17:05
    stevefaulkner: ++
  176. zakim-robot
    17:05
    [Alice Boxhall, a11y] Right, but you can't do anything once you've focused it
  177. zakim-robot
    17:06
    [Alice Boxhall, a11y] so the focus ring is just confusing
  178. rodneyrehm
    17:06
    without the onclick iOS won’t engage the legacy click event cascade thingie and focus is applied upon “mousedown"
  179. rodneyrehm
    17:06
    correct, focus - aside from serving for styling - is utterly useless on iOS
  180. deborahgu
    17:07
    wait, you can make it focus of an iOS with a negative tab index? Not zero? That's... Counterintuitive.
  181. rodneyrehm
    17:07
    (I have no idea about android, but would assume the same)
  182. zakim-robot
    17:07
    [Alice Boxhall, a11y] +1 @rodneyrehm (unless you've attached a keyboard)
  183. deborahgu
    17:07
    s/of an/on
  184. zakim-robot
    17:07
    [Alice Boxhall, a11y] @deborahgu yep :disappointed:
  185. rodneyrehm
    17:07
    Alice, no, not even then
  186. rodneyrehm
    17:07
    the tab key of your keyboard does exactly the same thing the arrow-buttons of your on-screen-keyboard
  187. zakim-robot
    17:08
    [Alice Boxhall, a11y] only focuses input elements?
  188. rodneyrehm
    17:08
    ok, you could abuse the focused element as the “initial focus starting point”, but that’s not much either
  189. rodneyrehm
    17:08
    yes
  190. zakim-robot
    17:08
    [Alice Boxhall, a11y] yeah that's a bummer
  191. rodneyrehm
    17:09
    Alice: http://rodneyrehm.de/t/focusable.html - the table is a work in progress, the first safari 8.0 column is ios
  192. rodneyrehm
    17:10
    @deborahgu you can make any element focusable by giving it tabindex=“-1”
  193. rodneyrehm
    17:10
    focusable - by element.focus() and pointer (anything that has mousedown in the cascade)
  194. rodneyrehm
    17:11
    the other thing - tabbable - or keyboard focusable - is tabindex=“0”, basically an upgrade of the other two
  195. rodneyrehm
    17:12
    (and to make things weirder, there are things you can only focus by keyboard, but not mouse - checkboxes on OSX for example). and Firefox and Internet Explorer take it a step further - any <svg> <a> is only keyboard focusable, but not by script or mouse
  196. deborahgu
    17:16
    rodneyrehm: ah, I was not distinguishing between focus of and keyboard navigable, yeah
  197. deborahgu
    17:16
    but yeah, of course focusable and not keyboard is something you sometimes want, I was merging the terms in my head incorrectly. Thanks.
  198. zakim-robot
    17:16
    [dsturley, a11y] @alice I can’t remember what the rationale for requiring focus indication on mobile… or if it was even logical
  199. zakim-robot
    17:17
    [dsturley, a11y] i guess what if someone accidentally gets to the mobile site??
  200. zakim-robot
    17:18
    [Alice Boxhall, a11y] @dsturley: I'm reasonably convinced it's not something you'd want (modulo if you attached a keyboard and they worked properly) but I definitely want to hear evidence to the contrary
  201. zakim-robot
    17:18
    [Alice Boxhall, a11y] @dsturley: then they'll be using a keyboard?
  202. rodneyrehm
    17:19
    ah, focus does have a reason in case of mobile and external keyboard - the focused element is the one getting the keyboard events dispatched to
  203. zakim-robot
    19:12
    [Andres Lopez, a11y] Hi, does anyone know where in New York where I can print Braille documents? CCVIP was closed when I passed by their office today.
  204. zakim-robot
    19:35
    [Thomas Logan, a11y] @drelopez The Andrew Heiskell library is open until 5 http://www.nypl.org/locations/heiskell
  205. zakim-robot
    19:36
    [Thomas Logan, a11y] @drelopez hmm just checked their site the braille printing might be by request
  206. zakim-robot
    19:47
    [Thomas Logan, a11y] @drelopez closing the loop that Chancey responded to you that they do as long you know how to use embosser otherwise you make an appointment. The Andrew Heiskell library is awesome, it is where we host our a11ynyc meetup.
  207. zakim-robot
    20:00
    [Andres Lopez, a11y] Thank you techthomas, helps a lot!