Archive index

A11y Slackers Gitter Channel Archive 2nd of February 2016

What fresh hell is THIS now? - Patrick Lauke
  1. cr2a-graphique
    13:08
    hi there !
    Have you one exemple of article slide who use aria and are A11y compliant
  2. MichielBijl
    13:12
    What's an article slide?
  3. cr2a-graphique
    13:13
    slideshow ^^
  4. MichielBijl
    13:16
    Ah, a carousel type thing.
  5. cr2a-graphique
    13:16
    yep
  6. MichielBijl
    13:17
    Hmm, I've build one that is sort of accessible.
  7. MichielBijl
    13:18
    But that's not live yet.
  8. MichielBijl
    13:18
    There is an ARIA plugin for Owl Carousel
  9. MichielBijl
    13:18
    But only version 1 I believe.
  10. MichielBijl
    13:25
    Is it a plugin you're looking for or just an example?
  11. cr2a-graphique
    13:26
    exemple
  12. cr2a-graphique
    13:37
    an example
  13. MichielBijl
    13:37
    @cr2a-graphique I've send you a private message.
  14. MichielBijl
    13:38
    The best place to look is tab panel interfaces I think.
  15. MichielBijl
    13:38
    http://w3c.github.io/aria/practices/aria-practices.html#tabpanel
  16. MichielBijl
    13:39
    Those are essentially the same; they differ in visual style.
  17. MichielBijl
    13:39
    Also see common panel: https://github.com/bkardell/common-panel
  18. MichielBijl
    14:10
    To pester Steve, I've nominated him as an emerging leader in the accessibility field >:)
  19. stevefaulkner
    14:27
    @MichielBijl think @karlgroves got that last year (he has been coming out for 15 years) I got this https://twitter.com/stevefaulkner/status/575990662723698688
  20. MichielBijl
    14:28
    So there might be another award in it for you this year ;)
  21. stevefaulkner
    14:28
    heh
  22. stevefaulkner
    14:29
    I want the web standards ASShat award
  23. MichielBijl
    14:31
    Can I nominate you?
  24. stevefaulkner
    14:34
    :+1:
  25. jasonday
    15:19
    I'll leave this here: http://shouldiuseacarousel.com/
  26. MichielBijl
    15:21
    @jasonday that is always good to remember.
  27. MichielBijl
    15:21
    If you don't have a choice however, you're better off making it accessible :)
  28. jasonday
    15:22
    true, but making it accessible can be a huge undertaking - one more reason not to use one :smile:
  29. jasonday
    15:22
    but, they sneak in from time to time
  30. jasonday
    15:25
    Question for the group - I have a small project team that I need to get up to speed on a11y (mixed devs & biz folks). Is there a good starting point for training (online MOOC, or something similar)?
  31. cr2a-graphique
    15:28
    like that : https://www.w3.org/WAI/intro/wcag.php ^^
  32. jasonday
    15:30
    @cr2a-graphique - yeah, but I was also hoping for something a bit more 'approachable' as a first introduction - the w3 site can be overwhelming when someone initially dives in
  33. cr2a-graphique
    15:30
    haha, take a scuba :)
  34. cr2a-graphique
    15:31
    i got french web site exemple but not english version
  35. LjWatson
    15:32
    @JasonDay try webaim.org for some good introductory materials.
  36. deborahgu
    15:36
    @jasonday, also, after the initial hour or so, your devs and biz folks should not be doing the same training
  37. jasonday
    15:37
    @deborahgu - very true, and I have materials both directions - but I suppose I need to author something for the intro
  38. deborahgu
    15:38
    And make sure that the devs get the nitty-gritty of accessible javascript; too many intro traings start and stop and alt + headings
  39. deborahgu
    15:38
    although I suppose the modern web is sadly lacking in people who write alt or headings, so there's that. /o\
  40. deborahgu
    15:50
    @jasonday some non-free resources you may have access to (can create free trial accounts on these sites):
  41. deborahgu
    15:50
    Joshue O'Connor, Pro HTML5 Accessibility: Building an Inclusive Web: https://www.safaribooksonline.com/library/view/pro-html5-accessibility/9781430241942/
  42. deborahgu
    15:50
    And two detailed books I love:
  43. deborahgu
    15:50
    Introduction for devs, not detailed, video, freely available, Cassidy Williams, "Accessibility in the Browser" https://www.safaribooksonline.com/library/view/accessibility-in-the/9781491936504/ -- there's a transcript available at https://teamtreehouse.com/library/accessibility-in-the-browser
  44. deborahgu
    15:50
    Katie Cunningham, Accessibility Handbook: https://www.safaribooksonline.com/library/view/accessibility-handbook/9781449322847/
  45. deborahgu
    15:55
    And a recent issue of Smashing Magazine is a11y focused and has a bunch of great articles, including bits by ljwatson henny marcysutton chaals and others. "Practical Approaches For Designing Accessible Websites", August 2015, https://www.safaribooksonline.com/library/view/practical-approaches-for/9783945749227/
  46. jnurthen
    16:01
    @deborahgu thanks for all those links. We have safari so I'm going to add those to our resource kits for our developers
  47. MichielBijl
    16:02
    @jasonday, you'll have to come up with the words yourself, but you may totally rip these: http://dir.rawr.eu/introduction-to-accessibility-(for-managers).zip / http://dir.rawr.eu/introduction-to-accessibility.zip
  48. MichielBijl
    16:02
    O butcher them into something that fits your needs.
  49. MichielBijl
    16:02
    Or ignore them all the same…
  50. zakim-robot
    16:52
    [bmeunier] Copy Box
  51. zakim-robot
    17:18
    [george_zamfir] Hey everyone, any advances in detecting accessibility features on mobile beyond screen readers?
  52. powrsurg
    17:21
    Detecting accessibility features?
  53. MichielBijl
    17:23
    How do you detect a screen reader?
  54. MichielBijl
    17:23
    And why would you?
  55. powrsurg
    17:27
    wasn't there talk about media queries for detection? I don't know how far that ever got
  56. zakim-robot
    17:29
    [callumacrae] Why would you want to detect a screen reader?
  57. zakim-robot
    17:30
    [george_zamfir] I mean detecting whether the screen reader is running on the user's phone. You can currently detect that on Android & iOS (
    UIAccessibilityIsVoiceOverRunning(), https://developer.apple.com/library/ios/documentation/UIKit/Reference/UIKitFunctionReference/#//apple_ref/c/func/UIAccessibilityIsVoiceOverRunning)
  58. zakim-robot
    17:31
    [george_zamfir] The detection happens in the apps. It's great for analytics / tracking. My question is, has there been any developments in tracking more than screen readers?
  59. MichielBijl
    18:12
    @powrsurg: there was for the DPUB WG, but that never made it into a spec thing AFAIK
  60. MichielBijl
    18:12
    @George Zamfir: why would you want to know if a screen reader is running?
  61. MichielBijl
    18:12
    Do you also want to know how many people use a keyboard?
  62. MichielBijl
    18:12
    Or a styling pen thing?
  63. MichielBijl
    18:12
    Or how many drink whisky while behind the computer?
  64. MichielBijl
    18:13
    I don't see the significance.
  65. MichielBijl
    18:16
    It's just a way to input command, same as keyboard, mouse, stylus things, switches, punch cards, whatever…
  66. powrsurg
    18:17
    well, to be fair I think there shouldn't be any reason why that shouldn't be detectable -- we can detect thousands of other things for the sake of analytics. Saying that people using AT are special and shouldn't be detectable is a form of discrimination I'd say. I understand that they wouldn't want that because then there is the potential for custom sites being made just for them, but we can do that for other things now too (like if the user is on a mobile device) so signalling people with AT off seems bad too
  67. powrsurg
    18:17
    and actually, CSS4 does allow you to detect things like if they're using a stylus ... it just hasn't made it into many browsers yet
  68. powrsurg
    18:19
    I've added scripts I've found in here to detect if a person is using a keyboard primarily to move around and thus add more focus styling to things and hid the styling for people that click. I found the site more pleasant to use overall because of that.
  69. powrsurg
    18:21
    ... and I just got an email with an emoticon in gmail that I have no idea what it is even with the alt text ... :-$
  70. powrsurg
    18:21
    heck, that looks different in gitter than gmail ...
  71. powrsurg
    18:21
    : - $
  72. powrsurg
    18:21
    without the spaces
  73. MichielBijl
    18:23
    @powrsurg: I'm against detection/tracking in general, so that doesn't change my view.
  74. MichielBijl
    18:23
    Feature detection is okay, but AT is not a feature.
  75. MichielBijl
    18:23
    And how would one detect a stylus?
  76. MichielBijl
    18:24
    Further more, that we can detect thousands of other things should be scary in and by itself; don't need to add more stuff to that.
  77. jnurthen
    18:24
    @powrsurg http://git.emojione.com/demos/ascii-smileys.html says that : $ is "flushed"
  78. powrsurg
    18:25
    I haven't looked at it much, but you'd need to do some combination of any-pointer and any-hover I imagine
  79. jnurthen
    18:26
    I know someone who is working on this for analytics but I don't want to out them publicly (it is a sensitive topic) - I'll ping them offline and see if they want to comment
  80. powrsurg
    18:26
    eh, I am a "I want as many tools possible to build something kick-ass and has great performance". Feature detection is nice, but that can lead to a user downloading a ton of crap that won't be useful for them
  81. powrsurg
    18:27
    I mean, it would be great if a site like statcounter actually could detect screen reader type usage and thus would make that available as a stat instead of needing the webaim survey
  82. powrsurg
    18:28
    that would eliminate the ambiguity where we now think zoomtext went from something like 1% market share to 20% market share in a year
  83. powrsurg @powrsurg is that evil guy that prefers separate mobile web sites for the better performance aspect over responsive design ... which is why sites like FB use separate sites over responsive
  84. MichielBijl
    18:30
    @powrsurg: so put less crap in your website ;)
  85. powrsurg
    18:30
    now, I wouldn't build a separate site for AT, but it would be great to have an idea how this work that we've done actually benefited actual users
  86. MichielBijl
    18:30
    Have you asked your users?
  87. powrsurg
    18:31
    occasionally we get some stuff, but we more get requests from potential clients (or active ones) that simply ask "are you 508 compliant"
  88. powrsurg
    18:33
    I mean, I push for it because it's the right thing to do. You don't really care about the user experience unless you care about all of your user's experience. But it would be nice to know how many we're actually helping from a development standpoint.
  89. MichielBijl
    18:33
    I sent a survey to my websites users a while back to ask them what they thought of the accessibility of it all; both responded very positively.
  90. jnurthen
    18:33
    LOL
  91. powrsurg
    18:35
    heh. That reminds me that I really need to update my personal site ... I haven't touched the design since before people started using monitors > 1280 .....
  92. zakim-robot
    18:43
    [mattmay] Like I said to george_zamfir privately, the subject of reporting AT status makes me uncomfortable.
  93. zakim-robot
    18:44
    [mattmay] First because of privacy, and because telegraphing someone's disability status is only one step away from enabling people to discriminate against them.
  94. zakim-robot
    18:44
    [mattmay] That's why there's no AT sniffing in the Web platform, historically.
  95. powrsurg
    18:46
    I get that, but isn't saying someone is of a special class that you're not allowed to report on a form of discrimination? I get what the intent is and I half-agree, but denying it too makes me feel funny ...
  96. zakim-robot
    18:46
    [mattmay] But second, in terms of analytics, numbers are not_ our friends. Anybody who wants that data is looking for a number larger than ground scatter, and if they get 1% or whatever, that's enough for most of them not to bother. The argument is that if even _one user pops up, they should be accommodated.
  97. zakim-robot
    18:47
    [mattmay] I don't understand what you're saying here.
  98. powrsurg
    18:48
    think of it the other way though -- seeing that of the X users that run AT there are Y (where Y is large) that use JAWS that might make it easier to justify to higher ups that you need to spend the money on it
  99. powrsurg
    18:52
    I was just going with the concept of soft discrimination. Similar to the discrimination of low expectations. I get the argument that if there is a way to detect then people could do bad stuff, but not allowing it and then allowing say, that a person is using Firefox on an Android phone is detectable sets up a hierarchy of acceptable detection. One being more allowed than the other is just odd
  100. powrsurg
    18:53
    I know you can use javascript to detect if a person is using a high-contrast theme/ high contrast mode
  101. zakim-robot
    18:54
    [george_zamfir] @michiel, you're overreacting. And not answering my question at the same time. Keep in mind we're all accessibility advocates here. Luckily I work with an organization who is already committed to accessibility, so no I'm not using analytics to discriminate anyone. The point is to put some metrics around accessibility (just like we do with performance, etc.) that we can track and improve over time.
  102. zakim-robot
    18:58
    [george_zamfir] Also, while on this topic. We can't talk about making accessibility mainstream but reject the stuff that makes other topics mainstream.
  103. zakim-robot
    18:59
    [george_zamfir] Along the same lines, I talk to people & organizations who put accessibility bugs above all other bugs. I don't see how that makes a11y mainstream.
  104. zakim-robot
    19:00
    [george_zamfir] We should start an #a11yphilosphy channel and duke it out there. In the meantime, I guess I'll follow up on my question in the native-mobile channel.
  105. powrsurg
    19:00
    I think it was Facebook (and I think LinkedIn) posting that they were looking for candidates that knew a11y stuff well that got a bigger focus on a11y
  106. zakim-robot
    19:02
    [ryoia] so i have a dropdown menu that has this structure:
    <span role="menuitem" aria-haspopup="true"> <ul role="menu"> <li role="menuitem" aria-controls="st1"><a.../></li></ul></span>
    this is the example that i followed http://www.oaa-accessibility.org/example/25/
    does this seem correct? it seems like they are changing aria-hidden to true or false based on whether which list the user is in. is there another example that you folks like to follow?
  107. jasonday
    19:04
    We "tag" users based on behaviors, demographics, etc. for internal marketing purposes and for analytics. We analyze user behavior, and make improvements to the experience based on that data. Because screenreaders are a black box, we can't address the usability in the same manner.
  108. jasonday
    19:07
    I think this is especially pertinent when it comes to ARIA, as WCAG is straightforward, but I would love to have data around how screenreader users are using the site. For example, if I have a vendor do an assessment, I get a few visually impaired engineers looking at the site making recommendations (all from the same org). Whereas if I could look at screenreader user behavior, my sample size would be significantly larger and varied = better data.
  109. zakim-robot
    19:10
    [karlgroves] I’d recommend doing usability testing then
  110. jasonday
    19:11
    @zakim-robot - at quick glance, I think i've used the same or very similar approach to your example, but for sighted/mouse users we add hover intent in, as the drop disappears too quuickly and users become frustrated
  111. zakim-robot
    19:19
    [george_zamfir] Yeah, usability testing is great idea regardless of how much (or no) data / analytics we have.
  112. jasonday
    19:24
    usability testing goes hand in hand with data, as it is still small group focused. On a site our size, we will test a feature and then run it through an A/B test to gather more data and iterate further on the feature. There are things we've found only by A/B testing or after launch, that we were unable to suss out in usability studies.
  113. zakim-robot
    19:33
    [george_zamfir] Yeah, I hear you Jason and that makes perfect sense. I'm at that point where I want to add data / analytics into my mix alongside A/B testing and usability studies.
  114. powrsurg
    19:49
    I'm surprised ChromeVox doesn't allow Google Analytics to track it somehow
  115. jasonday
    19:50
    and I get that tracking screenreaders could be used for evil (dismissing accessibility inclusion), but at it's core data itself is not bad and could be used to further accessibility needs
  116. jasonday
    19:56
    we use a tool to 'tag' users based on their site behavior, and I thought that I might be able to find a way to 'tag' potential screenreader/low vision users. For example a user that tabs a lot or uses the page zoomed in 'may' fall in to this group. In this way, I may be able to add this group to our list of segments. By doing that, I can then read the 'success' level of this group (just like we do with other segments). This would likely provide ammo for a11y, as you would be able to see where this group was getting hung up in the process (lower success rate, in general)
  117. MichielBijl
    20:09
    money”; you don't want AT detection to “avoid on-boarding expensive customers” at your insurance firm.
  118. MichielBijl
    20:09
    @George Zamfir: I'm sorry if my reaction is a bit strong, I generally dislike tracking and have not seen many good reasons to do so. Like mattmay said, detecting screen readers could discriminate people more than they could say which browser your use. There was a booking website that showed higher prices to Mac users “because they probably have more
  119. zakim-robot
    20:12
    [deborah_kaplan] @powrsurg, every time the qurestion of detection comes up on the webaim list there's a nigh-universal "aiyee please no". I'd say the concerns that get mentioned are:
    1. privacy
    2. irrelevance to actual utility in practice; developers will think "if I don't identify a screen reader there are no AT needs and I can give them the totally inaccessible site!" Proof in practice: the still huge number of sites which have skip links which don't become visible on focus, thus completely leaving out keyboard and screen magnfication users who also use them, simply because the developers assume "no detectable AT" == "no need for accessibility".
    3. because too many of us have been burned by the non-fully featured accessible version of the site. Proof in practice: Amazon's accessible site, Accessible version of web Outlook, neither of which are fully featured. (as of a couple of years ago, anyway.)
  120. zakim-robot
    20:13
    [deborah_kaplan] Think about how when a site autodetects mobile and redirects you to a version of the site that's only partially featured, and doesn't let you override and return to the full version. Which is ubiquitous.
  121. jasonday
    20:13
    @MichielBijl good point and I think there could be terrible things done with tracking, but I'm hopeful that ship is at least getting ready to set sail. For my org it would be to further a11y needs in a meaningful way....what does the data say in conjunction with the usability.
  122. zakim-robot
    20:13
    [deborah_kaplan] But @jasonday, that data would never identify tons of people
  123. jasonday
    20:14
    @deborahgu - yeah, there definitely has to be approached as full inclusion, avoiding the "separate, but equal' approach
  124. jasonday
    20:14
    but you'd still have more data than you have now
  125. zakim-robot
    20:14
    [deborah_kaplan] it would give you deceptively low numbers: anyone who control-plusses their screen to a large size, for example, or keyboard-only users.
  126. zakim-robot
    20:14
    [rodneyrehm] Are we interested in detecting AT to alter our website, or are we interested in collecting metrics?
  127. MichielBijl
    20:14
    What would the data tell us anyway?
  128. jasonday
    20:14
    For me, it's pure metrics/marketing
  129. zakim-robot
    20:14
    [rodneyrehm] If it’s the latter, maybe we should think about how that might be done without allowing the former?
  130. jasonday
    20:15
    where users fell off, what hurdles they face, why didn't they convert, etc
  131. zakim-robot
    20:15
    [deborah_kaplan] I'm not a huge fan of data that would deflate the numbers, bouncing off what @mattmay said.
  132. MichielBijl
    20:15
    Like my earlier series of annoying questions: are we doing the same for keyboard users? Same for mousers? Same for touchies?
  133. jasonday
    20:15
    @MichielBijl - yeah, we track your input when possible
  134. MichielBijl
    20:15
    Okay, but what for?
  135. jasonday
    20:15
    it allows us to build better web products when we know how users are using them
  136. zakim-robot
    20:15
    [deborah_kaplan] Like @karlgroves said, usability testing will get you more genuine data here. Test with real data.
  137. jasonday
    20:16
    It's different data - I wouldn't call one more genuine than the other. Usability testing is one tool we use, but it isn't the answer for all data
  138. zakim-robot
    20:16
    [deborah_kaplan] Detecting AT won't help you build better web products. Writing to WCAG and encouraging browser manufacturers to write to UAAG will help you build better web products.
  139. zakim-robot
    20:16
    [rodneyrehm] my apps track everything you do (minus the actual data you use/produce) so we can identify paths you took. That allows us to see where you struggled or even failed. It also allows us to see which path might be optimized. What features are used the most and need more attention…
  140. zakim-robot
    20:17
    [rodneyrehm] however, it doesn’t track if a button is clicked on or invoked via keyboard. so I’m not sure what I’d want to know from AT…
  141. zakim-robot
    20:18
    [deborah_kaplan] None of this AT tracking will track of this tracks my most common failures! When Dragon or my keyboard try to access an actionable link and fail because it has no role or tab index, that's not going to be tracked.
  142. zakim-robot
    20:19
    [rodneyrehm] true
  143. powrsurg
    20:20
    I understand what people are saying, but if you want true a11y concerns to become mainstream they need accurate data. It's like how Firefox and the open web had to eventually accept DRM in the browser in order to play certain media. It's a sucky reality, but that is the case with things.
  144. jasonday
    20:20
    detecting AT would absolutely help us build better web products. Wouldn't it be helpful to know where users (any users, including AT users)s were getting hung up in a process on your website. If I know where that is, I can build a better web product to address user's needs.
  145. powrsurg
    20:21
    In regards to mobile redirects, any site that does them and doesn't let you switch back and forth just plain sucks
  146. zakim-robot
    20:22
    [rodneyrehm] what exactly is AT?
  147. powrsurg
    20:22
    And I don't think any survey would ever result in a majority of users saying they didn't feel that tracking disrupts their privacy. Most will say they don't like it, regardless of the audience (not just AT related)
  148. zakim-robot
    20:24
    [rodneyrehm] or put another way, what exactly do you want to know? input method (mouse, keyboard, voice, …)? output method (screen, screen reader, magnifier, …)?
  149. zakim-robot
    20:26
    [deborah_kaplan] I argue that this won't be accurate data.
  150. zakim-robot
    20:26
    [deborah_kaplan] Eg., I can't use a mouse. Will your AT detection identify that my keyboard is AT?
  151. zakim-robot
    20:27
    [deborah_kaplan] Will it identify only add on magnification, or also people who have browser zoom?
  152. stevefaulkner
    20:27
    https://www.marcozehe.de/2014/02/27/why-screen-reader-detection-on-the-web-is-a-bad-thing/
  153. powrsurg
    20:27
    It's impossible to get 100% accurate data, true, but that doesn't mean it should be avoided. There are a lot of different ways to block the detection of whether or not an email was opened, but mailing list software still includes methods to do it so you get a low-bar number at the very least
  154. jasonday
    20:27
    with the current approach, no it wouldn't be accurate data and segmentation is fuzzy logic anyhow. But, I'm positing that having the data could be used for good (not evil, which seems to be the default view of tracking)
  155. zakim-robot
    20:29
    [deborah_kaplan] @powrsurg and @jasonday, until recently, Doodle was identifying the presence of Dragon NaturallySpeaking and refusing to let me run a poll because it didn't think it would work with Dragon. (It was wrong.)
  156. stevefaulkner
    20:29
    http://tink.uk/thoughts-on-screen-reader-detection/
  157. zakim-robot
    20:29
    [rodneyrehm] »look, I only have 0.1% AT users - unlikely they have an impact on my business, why optimize?«
  158. zakim-robot
    20:29
    [deborah_kaplan] You can say that software, like forced mobile sites, "just plain sucks", but you're talking about our reality.
  159. powrsurg
    20:30
    Oh, I am against the concept of taking action beyond running statistics. I do get why people would be concerned about it, but I do believe we can't be afraid of stuff like that. You need numbers to be able to justify improvements else you're just going with your gut
  160. jasonday
    20:30
    Again, i'm not saying to exclude users or give alternative content - but if I had AT data, I would be more efficient in delivering an accessible website that is truly usable.
  161. zakim-robot
    20:31
    [deborah_kaplan] If you can gather AT data to make a case to marketing, then some doofus at another site will gather that same AT data and say "it's easier to make a segregated experience than it is to learn how to use ARIA."
  162. jasonday
    20:32
    @stevefaulkner both articles are concerned about alternative content (i.e. the ghetto), and I understand that perspective. My point is that data in and of itself is not bad, it's how the data is used.
  163. StommePoes
    20:32
    Instead of numbers to "prove" to devs that actual disabled people can, derp, use computers... I'd much much much much rather let devs see actual people, especially developers, using computers and web sites. I think one reason developers don't even think of accessibility is because they never see disabled people, except occasionally in a film where that 1 disabled person represents everyone : (
  164. zakim-robot
    20:33
    [rodneyrehm] I’m with the cat on that…
  165. jasonday
    20:33
    @StommePoes - it's not about proving anything. I'm simply saying that having more data about how users use my website would allow me to improve the experience ni a more meaningful way
  166. StommePoes
    20:33
    Looking at the team I'm currently working with, they are almost entirely homogenous is many ways: they ALL have the latest equipment (mostly macs), the newest or near-newest mobile phones, fat pipes/fast cables, and both their homes, their work, and many of the places they hang out have excellent wi-fi.
  167. jasonday
    20:34
    spoiled developers ;)
  168. zakim-robot
    20:34
    [rodneyrehm] seeing a blind person demo how they use what I created is eye opening (no pun intended)
  169. StommePoes
    20:34
    So when I say "well a lot of the world, a large part you claim you want to reach, doesn't even have that" and they question whether it's worth it
  170. StommePoes
    20:34
    Because they figure "oh yeah some starving African maybe but that's not our target demographic"
  171. StommePoes
    20:34
    that's the view, because they don't see anyone different from them
  172. MichielBijl
    20:34
    @powrsurg “I understand what people are saying, but if you want true a11y concerns to become mainstream they need accurate data.” don't think the data is on our side unfortunately.
  173. StommePoes
    20:34
    especially not in their own roles, let alone the users on the other end (usually not developers though they could be)
  174. powrsurg
    20:34
    Running from the concept of obtaining data itself is wrong. It's not scientific. I think we all agree that taking actions like detecting that someone is not using a mouse and thus showing them different prices is bad. But obtaining data in and of itself is not correct
  175. zakim-robot
    20:35
    [deborah_kaplan] hard numbers: http://www.census.gov/people/disabilityemptab/data/
  176. StommePoes
    20:35
    You should collect their race and genders then too
  177. zakim-robot
    20:35
    [deborah_kaplan] StommePos++
  178. MichielBijl
    20:35
    Yeap
  179. zakim-robot
    20:35
    [rodneyrehm] my boss has a red/green deficiency… that’s about as close to “disabled” as it gets in my office… funny enough, he also doesn’t see the point of making accessible websites
  180. zakim-robot
    20:36
    [deborah_kaplan] powrsurg, we're saying these numbers you'd be gathering are not accurate, and would understate the issue, hurting the cause you want to use it for.
  181. stevefaulkner
    20:36
    Wilfully provided self identification is
  182. stevefaulkner
    20:36
    fine
  183. StommePoes
    20:37
    My former boss had shoulder surgery... instead of using his keyboard more effective, he switched to trying to use the mouse with his non-dominant hand. That is how a lot of people work though-- many very poorly sighted will fight to use the last of their vision, when honestly switching to something else would be way more productive. It's human behaviour I guess.
  184. MichielBijl
    20:37
    Yeap, if someone wants to tell you something about themselves, they should be enabled to. Don't force it upon them.
  185. stevefaulkner
    20:37
    In your case @StommePoes , species identification
  186. zakim-robot
    20:37
    [deborah_kaplan] more real hard data: http://www.cdc.gov/nchs/fastats/disability.htm
  187. powrsurg
    20:37
    @deborah_kaplan and again, going with the fact that newsletter software will always under report opened email and yet people are fine with it shows that this is not that bad of a thing
  188. StommePoes
    20:37
    I already have creepy ads tracking my underwear colour and where I scratch myself. Yeah, it's just data, but screw those people
  189. StommePoes
    20:38
    Not all people are fine with that! It's even a known problem!
  190. MichielBijl
    20:38
    Ghostry to the rescue…
  191. zakim-robot
    20:38
    [deborah_kaplan] @powrsurg: 1. the popularity of ghostery is immense
  192. StommePoes
    20:38
    Sec experts tell people don't open something that looks like spam-- it can confirm your email address is alive to spammers
  193. powrsurg
    20:38
    it's not non-existent
  194. StommePoes
    20:38
    but, I agree there are also a lot of people who don't care
  195. jasonday
    20:38
    @stevefaulkner - agreed. An opt-in would be great and the data would be useful (from someone that wouldn't use it for evil)
  196. StommePoes
    20:39
    but then if you have to draw the line of only getting data from those who don't care, your numbers still get skewed.
  197. zakim-robot
    20:39
    [deborah_kaplan] and 2. you're not using that underreported stat to prove to your bosses they should allow you to have email campaigns, or to convince your developers to let newsletters be a thing.
  198. MichielBijl
    20:39
    Nice example: https://edri.org/
  199. MichielBijl
    20:39
    they ask you which cookies are fine, disabled by default.
  200. powrsurg
    20:40
    I did used to do a lot of dev where people did marketing and needed software that did such. I'm aware that not everything can be tracked, but site owners do want that data. Not being able to detect that stuff means that it's ignored by site owners. If they at least had the data they could contemplate things
  201. jasonday
    20:40
    @StommePoes - your gender and age are also tracked by the sites you visit
  202. StommePoes
    20:40
    I know. I am not okay with that.
  203. StommePoes
    20:40
    Nor, as I said, the colour of my underwear and where I scratch myself.
  204. StommePoes
    20:41
    Look, I poop. Everyone poops. It's not secret.
  205. StommePoes
    20:41
    However
  206. StommePoes
    20:41
    that does not mean I want to poop in a glass toilet-room in the middle of a parking lot.
  207. StommePoes
    20:41
    That's privacy.
  208. StommePoes
    20:41
    It's not secrets.
  209. zakim-robot
    20:41
    [deborah_kaplan] And I come back again to the example of skip links that are only visible to screenreaders, or the "Doodle can't work with Dragon, so we've disabled it" example. This is a very common problem, and is totally based on developers assuming that identifying users with AT means they have identified how users use their sites.
  210. StommePoes
    20:41
    Deborah's example was one of the killing things of the opera browser
  211. StommePoes
    20:41
    it had to pretend it was other browsers for almost everything
  212. StommePoes
    20:42
    despite often having leading CSS support, websites blocked opera based on faulty knowledge.
  213. zakim-robot
    20:42
    [deborah_kaplan] @deborah_kaplan uses opera 12, has it set to always claim to be firefox.
  214. powrsurg
    20:42
    No one likes giving up any privacy. All I'm saying is that preventing people access to data simply because it's AT is in itself a form of discrimination. It's saying they need protection more than others so they're off limits
  215. StommePoes
    20:42
    Guess it's better to have the knowledge and then sit on it and do nothing : )
  216. StommePoes
    20:43
    Bias is a known thing. If I could get away with doing things like job applications without people knowing my age or gender or race, i totally would
  217. StommePoes
    20:43
    because again and again, people who say "well it shouldn't matter" are proven wrong
  218. zakim-robot
    20:43
    [deborah_kaplan] no, it's saying web developers can't be trusted and ruin everything.
  219. zakim-robot
    20:43
    [deborah_kaplan] @deborah_kaplan is a web developer
  220. StommePoes
    20:43
    because someone else, who is not outwardly biased or trying to be a douche, will still discrimminate against you.
  221. StommePoes
    20:43
    The devs I work with def discrimminate against IE users
  222. zakim-robot
    20:43
    [deborah_kaplan] @deborah_kaplan hopes that was taken as tongue in cheek because seriously, web dev here.
  223. StommePoes
    20:44
    I have to harp on and on about how many people MUST use IE as it's the only thing that works reasonably for them. And devs are like "yeah ok I get it" but they still 1) consistently forget to test in it 2) are less likely to worry they didn't test in it 3) are quick to say, before I glare at them, "the users should just switch to chrome"
  224. zakim-robot
    20:44
    [deborah_kaplan] The dev I worked with who'd say "why should we help users who insist on not using Chrome?"
  225. MichielBijl
    20:44
    @powrsurg: positive discrimination is a thing.
  226. MichielBijl
    20:45
    never mind, not sure where I'm going with that.
  227. StommePoes
    20:46
    lawlz
  228. powrsurg
    20:46
    heh
  229. StommePoes
    20:46
    Deborah isn't working with my group of devs, but they sure sound like mine :P
  230. jasonday
    20:46
    I didn't mean to start a war - From a UX point of view, the more data I have on my users, the better. (also former web dev)
  231. zakim-robot
    20:47
    [deborah_kaplan] Very few end users are aware that ecommerce sites have started extrpolating salaries (from brand of phone you're connecting from, from your axciom-shared data people don't know, from browser, etc) and giving you different pricing based on that.
  232. jasonday
    20:47
    (still a web dev...as it never goes away...I can't shake it)
  233. zakim-robot
    20:47
    [deborah_kaplan] @jasonday, ha! that's how I feel about being a librarian.
  234. StommePoes
    20:48
    jasonday I do totally understand the point of view-- I've also actually wished (still do, esp now that I know almost NOTHING of my new users) to know all the things.
  235. StommePoes
    20:48
    I don't think it's a good idea to give any devs that info. but I do want it myself
  236. StommePoes
    20:48
    Like crack I guess.
  237. StommePoes
    20:48
    People shouldn't have it. But if I were to try it myself, I'd want some :P
  238. jasonday
    20:48
    exactly. I want it all for myself
  239. zakim-robot
    20:48
    [deborah_kaplan] But the point is I think more data makes for a better business intelligence experience, not for a better UX experience. For a better UX experience, real user tests are far more informative than stats.
  240. StommePoes
    20:48
    nom
  241. powrsurg
    20:48
    I hear what you're saying. I just value equality in things and I feel like we're going overboard here. Maybe it is fair since truthfully, most sites get things wrong, even if they're trying to be good, but I think not allowing anything at all is placing roadblocks in the way of well-intended people
  242. jasonday
    20:49
    @deborahgu - and I think it's a mix of real user tests & data
  243. jasonday
    20:49
    in my experience thus far
  244. StommePoes
    20:49
    The well-intentioned are legion. However the number of those who don't do fuckery with users is very, very, very small.
  245. MichielBijl
    20:49
    @jasonday: the less data companies have on me, the better.
  246. zakim-robot
    20:50
    [deborah_kaplan] fair. and actually I totes agree with you and Mallory on that one. I want all of MY user's data. But I mostly want data on how they use the site, not on what tools they use. Eg what links did they click, what did they search for.
  247. jasonday
    20:50
    @MichielBijl - yeah, we all feel that way. But if I know where you're having an issue, then I can fix it.
  248. MichielBijl
    20:51
    If you give me a clear form to submit feedback, you will too.
  249. zakim-robot
    20:51
    [deborah_kaplan] Understood. It's just, detecting AT won't give you that information.
  250. MichielBijl
    20:51
    I can't count the number of times I came across a bug and had no place to communicate the bug…
  251. StommePoes
    20:52
    oh hell, I also want to know what AT my users use-- and how, and how long, and what did they click, and where did they go "ugg" and tear their hair out, etc etc
  252. jasonday
    20:52
    @deborahgu - it will, though. If I know that my implementation of an accordion isn't working from a screenreader perspective, then I need to fix it
  253. StommePoes
    20:52
    And I can't have that. I can't even have user testing. I'm making little pieces of things that other devs will plug into pages I'll never see myself
  254. jasonday
    20:52
    @MichielBijl - that's currently in development, so we will have that mechanism
  255. StommePoes
    20:52
    and will be thrown at users anywhere in the world.
  256. powrsurg
    20:52
    @MichielBijl you can always hit up a company on Twitter :p
  257. zakim-robot
    20:52
    [deborah_kaplan] @jasonday you won't know it's not working from AT detection.
  258. powrsurg
    20:53
    I have hit GoDaddy up about checkboxes that were missing labels
  259. jasonday
    20:53
    no, but I'll be able to see that screenreader users were having more problems than sighted...which means I need to fix it
  260. StommePoes
    20:53
    Deborah they'll need to install camera and mike, then they can hear/see all the users cursing at the page
  261. StommePoes
    20:53
    jason you'll have to decide what more problems means as well
  262. zakim-robot
    20:53
    [deborah_kaplan] you'll know it's not working if you have a section of your feedback form that says "could you tell us your browser, your OS, and if you have any assistive tech"
  263. zakim-robot
    20:53
    [deborah_kaplan] StommePoes ha!
  264. MichielBijl
    20:53
    @jasonday: cool! One thing I often miss about those things though is feedback on my feedback. I would like the know if it is actually being fixed.
  265. MichielBijl
    20:54
    That will influence my further reporting of bugs for that company.
  266. jasonday
    20:54
    good feedback ;)
  267. powrsurg
    20:54
    @deborah_kaplan but again, high level sites like StatCounter would provide better feedback on AT in use then the WebAIM survey
  268. MichielBijl @MichielBijl has stopped flagging bugs in Apple products…
  269. zakim-robot
    20:54
    [deborah_kaplan] right, and again, you'll never know that Dragon failed to identify your links as links on the page.
  270. MichielBijl
    20:54
    Except for WebKit, webkit is cool.
  271. zakim-robot
    20:54
    [deborah_kaplan] It won't look like a problem to you
  272. StommePoes
    20:54
    If it's an interface that is simply slower to keyboard through blindly, then that might be considered by the users to be totally fine as it's within their expectations. You have to know when a fail is a fail. Look at web AIM, the mailing list, people sometimes say "yeah JAWS does x" or "VO doesn't do Y" and someone else can answer "it never has and users of it like me are used to it, don't hack around and break everyone else trying to change what VO does here, which is also perfectly within the spec"
  273. MichielBijl
    20:55
    @powrsurg: sure, but those are mainly handled by teenagers that know shit about technical stuff.
  274. zakim-robot
    20:55
    [deborah_kaplan] (Here is my shout-out to the MBTA, who fixed an accessibilty bug a week after I reported it, and the Boston Museum of Science, who had fixed an accessibility bug that day when I reported one.)
  275. powrsurg
    20:55
    @MichielBijl they know how to forward things on to the technical department
  276. powrsurg
    20:55
    ... sometimes ...
  277. MichielBijl
    20:55
    Someone asked KLM (the Dutch flying thing) if subs would become available anytime soon. They said there wasn't enough room on their servers; yeah right…
  278. StommePoes
    20:56
    @deborah_gu wow, cool.
  279. jasonday
    20:56
    @StommePoes - good point. I guess I would know if there was an issue if I saw higher abandonment from the norm on a specific page. Then I know that's a friction point
  280. MichielBijl
    20:56
    Yay to people that fix bugs!
  281. StommePoes
    20:56
    yeah, if they are abandoning because the page sucked, or... I leave pages I accidentally click all the time
  282. jasonday
    20:56
    good news is that the feedback form on our site is likely to come directly to me
  283. jasonday
    20:56
    and I'm the business owner of accessibility, so I can likely get it fixed in a timely fashion
  284. zakim-robot
    20:56
    [deborah_kaplan] Or you won't know it's broken that you hide your megamenus with Z-index, and screenreader and keyboard users have to suffer through infinite tabbing.
  285. StommePoes
    20:57
    Like when I go to click something with a mouse and the page is still loading crap and everything shifts and I end up clicking on the wrong thing... did I leave that page because it was an issue, or was clicking that page not my intention in the first place?
  286. zakim-robot
    20:57
    [deborah_kaplan] jasonday++
  287. StommePoes
    20:57
    It can get hairy.
  288. powrsurg
    20:57
    @StommePoes heck, I get stuff like that with the Fandango app. And my (free) SMS client of choice
  289. StommePoes
    20:58
    what's fandango?
  290. MichielBijl
    20:58
    I like how Steve put it: “Screen reader sniffing, like browser and knicker sniffing, is a perversion”
  291. powrsurg
    20:58
    ... which I just remembered I got a Google Play gift card so I should get the paid version
  292. powrsurg
    20:58
    @StommePoes an app that lists movie times.
  293. powrsurg
    20:59
    @MichielBijl actually, browser sniffing is what every large-scale website does because it leads to better performing websites ...
  294. MichielBijl
    20:59
    How?
  295. MichielBijl
    20:59
    I don't use browser sniffing.
  296. StommePoes
    20:59
    Browser sniffing leads to the nightmare that is current user agent strings. Developers basically broke them.
  297. MichielBijl
    20:59
    And my website has large scaled fonts
  298. StommePoes
    21:00
    It's also why Opera, and now everyone, had to start listening to -webkit css crap.
  299. jasonday
    21:00
    modernizr - https://modernizr.com/
  300. MichielBijl
    21:00
    modernizr is feature detection.
  301. jasonday
    21:00
    feature detection, but your analytics engine does do browser sniffing
  302. jasonday
    21:00
    google analytics, Omniture, etc.
  303. StommePoes
    21:01
    It's the reason I had set my original Opera user agent string to Oprah. It made more websites work.
  304. jasonday
    21:01
    and to further the discussion, feature detection is detecting your input methods (touch, etc.)
  305. StommePoes
    21:01
    This is totally broken because it was moved from vBullitin to Discourse, but: https://www.sitepoint.com/community/t/extra-extra-web-developers-jump-on-1-preferred-rendering-engine-take-2/10972
  306. powrsurg
    21:01
    Using feature detection only leads to people downloading a TON of stuff they don't need. And there are times where you can't do feature detection. For instance, there are blackberry devices that have touch events but don't have a touch screen
  307. powrsurg
    21:01
    by detecting your IP/location they may serve you different content that is located geographically closer and will load faster
  308. jasonday
    21:02
    touch is a sore point - I worked on our tablet site, and I wanted to strip everyone of their fingers
  309. powrsurg
    21:02
    again, browser sniffing itself isn't bad. It's bad with what you do with it
  310. StommePoes
    21:02
    Input detection is also a hairy can of worms. In css they're adding this default-input setting, which I only know about because Patrick Lauke posted a list of reasons (from his own personal testing as well) how those break in all sorts of mixed devices.
  311. powrsurg
    21:02
    Facebook loads a separate mobile site
  312. StommePoes
    21:02
    "by detecting your IP/location they may serve you different content that is located geographically closer and will load faster"<-- this is why when I'm in a hotel in italy the websites display in a language I cannot read
  313. MichielBijl
    21:03
    @powrsurg: again, put less “TON of stuff” in your website.
  314. StommePoes
    21:03
    It's also why I get shitty search results in Google (one reason why I use duckduckgo), unless I specifically want local searches.
  315. StommePoes
    21:04
    If they let me choose, I could get those advantages-- sometimes they ARE advantages. Other times, they're stupid developers making assumptions about me that aren't true and that leads to frustration.
  316. MichielBijl
    21:04
    I never want local results.
  317. StommePoes
    21:04
    So the better sites do a detection, then ask a question.
  318. MichielBijl
    21:04
    I want local results as in “Earth”
  319. StommePoes
    21:05
    "You seem to be using a browser we personally find distasteful. Also, your religion is for losers. Would you like the Allah-Ackbar plugin to run so all the females on our website's faces are hidden?" <-- if it's asked instead of just done for me, I'll deal with it better.
  320. MichielBijl
    21:05
    We should be more a one people, and less a “not that one person”
  321. powrsurg
    21:05
    @MichielBijl look at all of the responsive sites that hide stuff that wont' work with display: none;. Or have two separate navigations that are toggled based on screen size. That's code that didn't need to be included
  322. MichielBijl
    21:05
    Agreed.
  323. StommePoes
    21:05
    Yeah I see that crap in Bootstrap
  324. MichielBijl
    21:05
    They should've build a better website.
  325. powrsurg
    21:05
    a browser sniff would avoid that
  326. StommePoes
    21:05
    it's called code for people who can't code. OR, yes, people who can code but don't have the time.
  327. StommePoes
    21:06
    But in the end, it's low-quality.
  328. MichielBijl
    21:06
    Most different styled navs can be made with one HTML structure.
  329. powrsurg
    21:06
    can but aren't always
  330. StommePoes
    21:06
    Michiel I did a bunch of work to turn a 3-nav Bootcrap menu into a single one, with Javascripts... eventually the visual designer who designed the page by adding bootstrap classes replaced it again with the bootstrap one, because it was what he could work with.
  331. MichielBijl
    21:07
    -.-
  332. StommePoes
    21:07
    Which, I guess I don't blame him-- it's lower-quality code and bloaty, but he couldn't JS or CSS himself. And that's kinda the point of Bootstrap.
  333. MichielBijl
    21:07
    @powrsurg, what that cat said, you can change that stuff with JS
  334. StommePoes
    21:07
    It was not simple or quick to do, though.
  335. StommePoes
    21:08
    but detecting the device wouldn't have solved it-- it needed to do the same thing even on desktops if the browser was minified. So it's pure media-query and JS detection there anyway.
  336. powrsurg
    21:08
    and including that JS means you're including code you didn't need
  337. powrsurg
    21:09
    Good stuff can be done with browser sniffing. Just like bad stuff can be done
  338. StommePoes
    21:09
    I don't write modular JS in a thousand little files that get put together by some node thingie-- removing a single function because I've determined the particular device was too small to ever show a desktoppy version wasn't practical.
  339. powrsurg
    21:11
    Yes ... but some people do. Google has a ton of stuff on how to improve PageSpeed and load time. Stripping out that stuff is part of that process
  340. StommePoes
    21:11
    Good things can be done with a lot of terrible things. I can't argue that that means it should be given to everyone when history consistently shows those things cause particular problems in large numbers because the majority use it badly.
  341. MichielBijl
    21:11
    Maybe work together with designers on how to make menus that can be build with just CSS?
  342. powrsurg
    21:11
    removing things from the critical path will greatly improve the experience for th euser
  343. MichielBijl
    21:11
    A lot can be done with just CSS.
  344. StommePoes
    21:11
    Michiel: not with Buttstrap
  345. MichielBijl
    21:11
    Also, a lot of designers don't know what…
  346. StommePoes
    21:12
    They had already engineered it so badly you really needed JS to make anything work.
  347. MichielBijl
    21:12
    I've seen designer's jaws drop because they didn't know you could do gradients and whatever.
  348. MichielBijl
    21:13
    Or all the cool stuff you can do with SVG.
  349. zakim-robot
    21:13
    [marcysutton] Got an axsChat question for you: any favorite bookmarklets or browser extensions to improve accessibility without AT? Like contrast fixers, markup fixing, skip link injection (is that even a thing?) https://twitter.com/cldbrand/status/694611652507885568
  350. StommePoes
    21:13
    Jim Thurber had some but my firefox won't run them anymore because something security something something
  351. StommePoes
    21:13
    sorry Thatcher
  352. StommePoes
    21:14
    Hm actually those might all be testy stuff, rather than help-you-nav stuff.
  353. powrsurg
    21:14
    The web is a big thing. It's hard to know everything. That is why a lot of sites have a11y problems. Just like a lot of people don't know about performance related things which does indeed recommend you strip out anything that is not used on that particular page to make the page itself load faster
  354. MichielBijl
    21:15
    @MarcySutton: @Karl Groves once sent me a great one, let me see if I can find a link.
  355. MichielBijl
    21:15
    Hmm, no luck, I have the code though…
  356. MichielBijl
    21:15
    Can put it up on Gist or whatever.
  357. powrsurg
    21:15
    I remember ... I think @stevefaulkner had posted something to get the serialized DOM of the page and how you can use that to check for WCAG 2.0 compliance
  358. StommePoes
    21:15
    I have a proposition: let developers do stuff based on sniffing, and every time they get it wrong and mess up my (and every user's) page, the users get to punch the developer in the face.
    It's something I'v wanted to do whenever a website makes an incorrect assumption for me, so I'd definitely feel better and it would feed my violent needs.
  359. StommePoes
    21:16
    Like when Google sends me useless Dutch links that are not what I'm looking for because the Dutch are useless at that kind of thing but Google makes the assumption that I want Dutch results without asking me first.
  360. StommePoes
    21:16
    I get to punch that guy.
  361. MichielBijl
    21:16
    @MarcySutton: this adds big red focus marker to your, well, focus: https://gist.github.com/MichielBijl/1767dc49856b31233aa0
  362. MichielBijl
    21:17
    Like when Google sends me useless Dutch links that are not what I'm looking for because the Dutch are useless at that kind of thing but Google makes the assumption that I want Dutch results without asking me first.
  363. MichielBijl
    21:17
    The Dutch are useless and untrustworthy in everything they do.
  364. powrsurg
    21:17
    speaking of wanting to punch things ... I've sound out of this room in slack as I prefer to use gitter for it. How the heck do I get it to Slack to stop emailing me every time someone here mentions my name?
  365. StommePoes
    21:17
    Hm...
  366. StommePoes
    21:18
    usually, like on Twitter, there's a user-preference-setting thing? That's usually where it can be turned off.
  367. powrsurg @powrsurg expects a couple of people here to tag me now ...
  368. StommePoes
    21:18
    However, I've not used Slack, it's possible that optoin doesn't exist.
  369. stevefaulkner
    21:18
    @powrsurg HTML checker bookmark lets http://validator.w3.org/nu/about.html
  370. StommePoes
    21:18
    lets wot?
  371. MichielBijl
    21:19
    @powrsurg: you van in THE Slack settings
  372. StommePoes
    21:19
    I found Thatcher's stuff but indeed, they are not to increase a site's accessibility but are for a11y testers http://jimthatcher.com/favelets/ sorry @marcysutton
  373. powrsurg
    21:19
    so ... in the emails I've been ignoring there was a link to unsubscribe that I couldn't find anywhere else
  374. powrsurg
    21:20
    yes, I signed out of the slack room and was still getting notifications ...
  375. powrsurg
    21:20
    hopefully I just turned off the notifications for this room since it'd be useful to still get them for the Open Badges room I'm in ...
  376. StommePoes
    21:20
    Honestly, something like Slack where people get tons of notifications... there's got to be a setting under your name somewhere.
  377. StommePoes
    21:20
    I mean, developers (the big users) wouldn't stand for a gazillion emails.
  378. zakim-robot
    21:20
    [marcysutton] So I think the question was more for users with disabilities, less about development
  379. StommePoes
    21:21
    Marcy yeah
  380. StommePoes
    21:21
    Only thing I can think of are more the readability-type plugins
  381. zakim-robot
    21:21
    [marcysutton] About the Slack notification thing: you can opt in to notify on “only highlight words and mentions” or not at all
  382. StommePoes
    21:21
    where article text is amplified and distractions are removed.
  383. zakim-robot
    21:21
    [deborah_kaplan] StommePoes will you punch my list for me? While I watch?
  384. powrsurg
    21:22
    of what was asked, I think only a contrast fixer would be the only thing that could reliably be done ...
  385. StommePoes
    21:22
    Deborah for your list, I'll prolly switch to a boot. My hand is delicate and can only punch so much before I'll need Dragon :P
  386. powrsurg
    21:23
    @marysutton: I had done that for this room AND signed out of the room and was still getting notified
  387. StommePoes
    21:23
    well the show-big-focus thing Michiel posted sounds exactly like a plugin an end-user would add for enhancing usability/accessibility
  388. StommePoes
    21:23
    esp, someone on the Twitters posted a website and I can't tab through it at all... no focus anywheres : ( sadpanda
  389. zakim-robot
    21:24
    [deborah_kaplan] marcysutton The developer of MouselessBrowsing has taken it down, but I've been meaning to email him and ask if he minds if I put it back up. I have some fixes I've made locally and I can't decide if I'm willing to maintain it myself. (it's not OSS licensed so I need to ask.)
  390. zakim-robot
    21:25
    [deborah_kaplan] StommePoes very smart. My list is long.
  391. zakim-robot
    21:26
    [deborah_kaplan] marcysutton which doesn't help you know but I think Hit-a-Hint is still up? https://addons.mozilla.org/en-US/firefox/addon/hit-a-hint/ Not as good as MLB but functional keyboard access to all links (assuming role/tabindex).
  392. zakim-robot
    21:26
    [deborah_kaplan] s/know/now
  393. zakim-robot
    21:27
    [deborah_kaplan] oh, wait, there's mouseless browsing back again, yay! https://addons.mozilla.org/EN-uS/firefox/addon/mouseless-browsing/?src=userprofile
  394. StommePoes
    21:27
    there's also vimperator for FF, if that's still maintained-- obs targetted to developers, but if you're a mouseless developer who knows vim...
  395. zakim-robot
    21:35
    [ryoia] i'm a little bit confused on what i need to do to change the focus for dropdown menu from this example (http://oaa-accessibility.org/example/25/), i have roles for each layer.
  396. zakim-robot
    22:59
    [estelle] on touch devices, how do screen reader / voice over users select radio buttons or other form controls when ‘touching’ the right area is not an option. Is there a good video or article people recommend on mobile/touch accessibility that doesn’t focus on the layout/design, but rather on user interaction for touch devices. Thanks for leads.
  397. zakim-robot
    23:08
    [mattmay] Try this one:
  398. zakim-robot
    23:08
    [mattmay] http://www.imore.com/how-use-voiceover-iphone-and-ipad
  399. zakim-robot
    23:08
    [estelle] thanks
  400. zakim-robot
    23:09
    [mattmay] tl;dr single-tap anywhere on the screen to repeat what has focus; double-tap to activate it.
  401. stacycarston
    23:45
    Does anyone know if there are any differences in practice between aria-live="assertive" and "polite"? I know how the definitions differ but have been unable to create an example that exhibits differing behavior between them in either NVDA or JAWS. I'm starting to wonder if screen readers actually care which is used.