/irc-logs / mozilla / #accessibility / 2014-06-23 / end

Options:

  1. # Session Start: Mon Jun 23 00:00:00 2014
  2. # Session Ident: #accessibility
  3. # [00:09] * Quits: maxli (maxli@moz-F47DD19B.student.cs.uwaterloo.ca) (Input/output error)
  4. # [00:10] * Joins: maxli (maxli@moz-EE42E0E.student.cs.uwaterloo.ca)
  5. # [02:40] * Joins: rednaks (rednaks@DA4ABEAF.1DE10CA8.D8E68FF6.IP)
  6. # [02:56] * Quits: rednaks (rednaks@DA4ABEAF.1DE10CA8.D8E68FF6.IP) (Ping timeout)
  7. # [02:59] * Quits: maxli (maxli@moz-EE42E0E.student.cs.uwaterloo.ca) (Quit: Leaving.)
  8. # [02:59] * Joins: maxli (maxli@moz-EE42E0E.student.cs.uwaterloo.ca)
  9. # [03:03] * Quits: maxli (maxli@moz-EE42E0E.student.cs.uwaterloo.ca) (Quit: Leaving.)
  10. # [03:03] * Joins: maxli (maxli@moz-EE42E0E.student.cs.uwaterloo.ca)
  11. # [03:38] <@firebot> Tobias.Besemer@Googlemail.com changed the Target Milestone on bug 13168 from mozilla1.0.1 to ---.
  12. # [03:38] <@firebot> https://bugzil.la/13168 — ASSIGNED, timeless — Implement more platform-specific keybindings (sparc help key, mac help key, windows menu key, etc.)
  13. # [04:06] * Joins: rednaks (rednaks@DA4ABEAF.1DE10CA8.D8E68FF6.IP)
  14. # [04:08] * Quits: rednaks (rednaks@DA4ABEAF.1DE10CA8.D8E68FF6.IP) (Quit: Téléportation !)
  15. # [04:14] <@firebot> dmajor@mozilla.com changed the Status on bug 1016545 from UNCONFIRMED to NEW.
  16. # [04:14] <@firebot> https://bugzil.la/1016545 — NEW — memory leak that kills Firefox in few seconds
  17. # [04:49] * Joins: yzen (yzen@moz-F62769B5.cpe.pppoe.ca)
  18. # [04:49] * ChanServ sets mode: +o yzen
  19. # [04:50] * Quits: maxli (maxli@moz-EE42E0E.student.cs.uwaterloo.ca) (Quit: Leaving.)
  20. # [04:50] * Joins: maxli (maxli@moz-EE42E0E.student.cs.uwaterloo.ca)
  21. # [05:21] * Quits: maxli (maxli@moz-EE42E0E.student.cs.uwaterloo.ca) (Quit: Leaving.)
  22. # [05:32] <@firebot> eitan@monotonous.org changed the Assignee on bug 1028329 from nobody@mozilla.org to eitan@monotonous.org.
  23. # [05:32] <@firebot> https://bugzil.la/1028329 — NEW, eitan — [AccessFu] Cancel delayed vc automove if before explicit move
  24. # [05:36] * Quits: @yzen (yzen@moz-F62769B5.cpe.pppoe.ca) (Ping timeout)
  25. # [07:38] * Quits: isaacd (quassel@moz-3ACED3EA.hsd1.ma.comcast.net) (Ping timeout)
  26. # [09:32] * Joins: slee (chatzilla@moz-477F6BD7.static.cyta.gr)
  27. # [09:34] * Quits: slee (chatzilla@moz-477F6BD7.static.cyta.gr) (Quit: ChatZilla 0.9.90.1 [Firefox 31.0/20140616143923])
  28. # [09:38] * Joins: tsp_ (tsp@moz-1BE921CC.bchsia.telus.net)
  29. # [09:51] * Joins: ioanachiorean_ (ioanachior@6DC7A5F5.AA1FA0D2.6A4F8DA2.IP)
  30. # [10:18] * Joins: agibson (agibson@moz-2C643250.gate.cable.virginm.net)
  31. # [10:18] * Quits: agibson (agibson@moz-2C643250.gate.cable.virginm.net) (Client exited)
  32. # [10:19] * Joins: agibson (agibson@moz-2C643250.gate.cable.virginm.net)
  33. # [10:20] * Joins: SteveF (chatzilla@moz-6F24D0BD.cable.virginm.net)
  34. # [10:39] * Joins: slee (chatzilla@moz-477F6BD7.static.cyta.gr)
  35. # [10:46] * Quits: slee (chatzilla@moz-477F6BD7.static.cyta.gr) (Quit: ChatZilla 0.9.90.1 [Firefox 31.0/20140616143923])
  36. # [11:25] <@firebot> gijskruitbosch+bugs@gmail.com changed the Resolution on bug 873045 from --- to DUPLICATE.
  37. # [11:25] <@firebot> gijskruitbosch+bugs@gmail.com changed the Status on bug 873045 from UNCONFIRMED to RESOLVED.
  38. # [11:25] <@firebot> https://bugzil.la/873045 — DUPLICATE — Holding down F5 shouldn't flood the web server
  39. # [11:25] <@firebot> gijskruitbosch+bugs@gmail.com changed the Status on bug 873045 from RESOLVED to VERIFIED.
  40. # [11:57] * Joins: slee (chatzilla@moz-477F6BD7.static.cyta.gr)
  41. # [12:07] * Joins: icaaq (icaaq@moz-1F1166A8.cust.bredbandsbolaget.se)
  42. # [12:27] <slee> Anyone know about or have pointers to a11y when using Cordova (PhoneGap)?
  43. # [12:27] <slee> obviously WAI ARIA in source and keyboard a11y not a massive issue - but how get best platform a11y?
  44. # [12:27] <slee> I think there is a a11y plugin too.
  45. # [12:35] * Joins: MarcoZ (marco.zehe@moz-D94BA082.dip0.t-ipconnect.de)
  46. # [12:35] * ChanServ sets mode: +ao MarcoZ MarcoZ
  47. # [13:04] <slee> SteveF: is there a good application guide for ARIA use in mobile apps? W3C or 3rd party?
  48. # [13:05] <SteveF> slee: not off hand i can think of willhave a look
  49. # [13:06] <slee> tah. Someone asked for a11y help for a cordova app. Best general guide looks like Henny's awesome work for Beeb
  50. # [13:07] <slee> SteveF: ^
  51. # [13:07] <SteveF> slee: i was thinking that may be good, btw whats a cordova app?
  52. # [13:08] <slee> SteveF: you know PhoneGap? Samething - the OS project behind the Adobe build service.
  53. # [13:08] <SteveF> slee ok thanks
  54. # [13:09] <slee> I assume it adds little to a11y as all about polyfilling APIs and wrapping
  55. # [13:11] * Joins: maxli (maxli@moz-B19F68ED.student.cs.uwaterloo.ca)
  56. # [13:13] <tsp_> I'm trying out firefox for android with accessibility, but I can't figure out how to move to the top of the page efficiently. Is this not implemented yet?
  57. # [13:18] * agibson is now known as agibson|afk
  58. # [13:48] * Joins: Gijs_away (gijs@moz-6FA91913.range86-173.btcentralplus.com)
  59. # [14:07] * Quits: slee (chatzilla@moz-477F6BD7.static.cyta.gr) (Ping timeout)
  60. # [14:07] * Gijs_away is now known as Gijs
  61. # [14:09] * Joins: slee (chatzilla@moz-477F6BD7.static.cyta.gr)
  62. # [14:14] <@MarcoZ> tsp_: Hi! What would you expect the "move to the top of the page" method to be?
  63. # [14:15] <tsp_> MarcoZ: I'm not sure. iOS has the double tap the top of the satus bar gesture, but I want to be able to scroll my page and move to the first element on it
  64. # [14:16] * Joins: surkov (surkov@moz-DF24A6EA.cpe.pppoe.ca)
  65. # [14:16] * ChanServ sets mode: +o surkov
  66. # [14:17] <@MarcoZ> tsp_: We're bound by the limitations Android puts on us. As far as I know, TalkBack does not have such a gesture. They only have one for "top of current screen", which would translate to the currently top left visible item on the screen, not the page. One of the more useless features in my opinion, since you can just touch the top left corner of your touch screen anyway.
  67. # [14:17] * Joins: scott_gonzalez (scott_gonz@moz-91C81A39.hrbgpa.fios.verizon.net)
  68. # [14:17] <tsp_> Could we bind it to something like home on a keyboard?
  69. # [14:18] <tsp_> I don't currently have a compatible keyboard, but maybe getting one would make browsing easier.
  70. # [14:18] <@MarcoZ> tsp_: Home and End on a keyboard are already taken by standard implementations afaik, and we don't want to change too much of the standard Android user experience.
  71. # [14:18] <@MarcoZ> tsp_: Besides, that would only solve the problem for those with a keyboard, but not the ones with a touch screen only.
  72. # [14:19] * Quits: agibson|afk (agibson@moz-2C643250.gate.cable.virginm.net) (Client exited)
  73. # [14:19] <@MarcoZ> tsp_: So I suggest to just use the two finger slide down to make the whole page scroll to the top as you do in other Android screens with TalkBack.
  74. # [14:19] <tsp_> Good point. I also notice I can't use a two finger scroll to scroll on the touch screen, I was expecting that to let me move a screen or so at a time if I did it enough
  75. # [14:20] <tsp_> Maybe I just did it wrong, because I expected that to let me see more of a page. I'll try again
  76. # [14:20] <@MarcoZ> tsp_: *That* should definitely work. And it does for me, Slide two fingers up to scroll the page down, and slide them down to move the page up. I even get ascending and descending TalkBack tones. The only thing you need to make sure is that an element on the page is currently focused, not one in the top bar like the menu button.
  77. # [14:21] <@MarcoZ> tsp_: In any case, just continuously swiping to the right, or using the Read To The Bottom command from that TalkBack context menu thingie, will also scroll the page.
  78. # [14:23] * Quits: slee (chatzilla@moz-477F6BD7.static.cyta.gr) (Ping timeout)
  79. # [14:31] <SteveF> surkov: bemused by your post on role=presentation
  80. # [14:31] <tsp_> I hope google i/o brings better accessibility. This is working, just a bit odd to get used to. Thanks
  81. # [14:31] <SteveF> surkov: would appreciate input on bug
  82. # [14:31] <@surkov> SteveF: why? sure
  83. # [14:32] <SteveF> because the requirement has been in spec for years :-)
  84. # [14:33] <tsp_> I find it a bit odd that tapping somewhere on the screen at first plays the empty space sound, but then moving my finger reads the item I just moved over even when that was empty space previously, but I assume that's just talkback/explore by touch limitations
  85. # [14:33] <@surkov> SteveF: it’s not super new post but those were just thoughts :)
  86. # [14:33] <@surkov> when I get some ideas that doesn’t really into mail list or real suggestion format then I blog them
  87. # [14:34] <SteveF> surkov: i agree that framing acc requirements in terms of ARIA does not work all the time
  88. # [14:35] <@surkov> yeah, there’s something worrying me in that appoach
  89. # [14:35] * Joins: slee (chatzilla@moz-477F6BD7.static.cyta.gr)
  90. # [14:35] <SteveF> mainly because aria only includes a subset of roles/states/properties and doesn't cover other stuff at all
  91. # [14:36] <@MarcoZ> tsp_: Firefox 31 will bring some improvements in this area. It is currently in beta, so you should hopefully see some better responsiveness when touching the screen when this gets released in July.
  92. # [14:37] <tsp_> Great
  93. # [14:39] * Joins: Justin_o (uid14648@moz-E77DEB21.irccloud.com)
  94. # [14:43] <@surkov> SteveF: right, but probably ARIA shouldn’t include all of this
  95. # [14:53] * Joins: agibson (agibson@moz-2C643250.gate.cable.virginm.net)
  96. # [14:56] * Joins: anvk (anovak@C141829F.3923648E.6468E038.IP)
  97. # [15:03] * Joins: yzen (yzen@moz-F62769B5.cpe.pppoe.ca)
  98. # [15:03] * ChanServ sets mode: +o yzen
  99. # [15:17] * Quits: slee (chatzilla@moz-477F6BD7.static.cyta.gr) (Quit: ChatZilla 0.9.90.1 [Firefox 31.0/20140616143923])
  100. # [15:32] * Joins: davidb (davidb@13F2CEC5.7672369.D8E68FF6.IP)
  101. # [15:32] * ChanServ sets mode: +qo davidb davidb
  102. # [15:33] * @davidb -> coffee
  103. # [15:44] <@firebot> dbolter@mozilla.com requested needinfo from bent.mozilla@gmai l.com on bug 982842.
  104. # [15:44] <@firebot> https://bugzil.la/982842 — NEW, trev.saunders — implement very basic support of OOp accessible documents
  105. # [15:44] <@MarcoZ> Heyo davidb!
  106. # [15:44] <@davidb> heyo!
  107. # [15:44] <@davidb> hi hi hi
  108. # [15:49] <SteveF> davidb: http://www.slipperstore.co.uk/images/LS415D.jpg
  109. # [15:49] <@davidb> SteveF, :P
  110. # [15:50] <SteveF> davidb: i am taking on role of principal shoe evangelist
  111. # [15:50] <@davidb> how fitting
  112. # [15:51] <@davidb> you heel
  113. # [15:53] <SteveF> ugh bad joker you
  114. # [15:54] <@MarcoZ> *cracks up*
  115. # [15:55] <@MarcoZ> davidb: 1:1 in 5?
  116. # [15:55] <@davidb> MarcoZ, yep
  117. # [15:55] <SteveF> my comrade patrick giving firefox another well deserved acc kicking "caught out by this weird @firefox behavior https://bugzilla.mozilla.org/show_bug.cgi?id=265389 … which actually gets in the way of an otherwise accessible implementation" https://twitter.com/patrick_h_lauke/status/481071641859227648
  118. # [15:55] <@firebot> Bug 265389 — DUPLICATE, bugs — Onchange event not triggered in a <select> tag when using the keyboard arrow keys
  119. # [15:56] <@davidb> how on earth is that bug still open (126379)
  120. # [15:56] * @MarcoZ isn't even sure this is a bug.
  121. # [15:56] <@davidb> is this a spec bug?
  122. # [15:56] <@davidb> ohhhh
  123. # [15:56] <@davidb> hmm
  124. # [15:57] <@MarcoZ> This used to be one of the big big headache points for screen reader users under IE with those "dynamic" weg pages, where pages would reload on change and would pull context out from under those screen reader users.
  125. # [15:58] <@MarcoZ> When I came on board with Firefox a11y, this was one of the big advantages that I could finally use those stupid pages properly. :)
  126. # [15:59] <@MarcoZ> So I am actually thankful whichever mechanism it is that caused (or may in some circumstances still cause) those headaches isn't present in Firefox. :)
  127. # [15:59] <@MarcoZ> But that's again my user-centric view that may get in the way of cool stuff for web devs. ;)
  128. # [15:59] <@MarcoZ> davidb: SteveF: ^
  129. # [16:01] <SteveF> MarcoZ: i have no understanding of the issue, its your germanic bretheren kicking off about it, told him to enter the irc and go a few rounds
  130. # [16:02] * davidb is now known as davidb|mtg
  131. # [16:08] * Joins: patrick_h_lauke (redux@moz-D879BBA2.pres.cable.virginm.net)
  132. # [16:09] <patrick_h_lauke> right, since SteveF is forcing me to use irc...
  133. # [16:10] <SteveF> hey patsicle
  134. # [16:10] <patrick_h_lauke> the issue i'm having: dynamic form, based on what you choose in the <select> it shows/hides more fields immediately after the <select>
  135. # [16:10] <patrick_h_lauke> behavior hangs off of onchange event on <select>
  136. # [16:11] <patrick_h_lauke> every other browser, keyboard user can focus on the <select>, use UP/DOWN (which shows/hides fields while they're still focused on the <select>) and then on TAB, they move to whatever new field was shown
  137. # [16:11] <SteveF> patiscle: i think marcoZ and davidb are having a private mano a mano right now
  138. # [16:11] <patrick_h_lauke> ...except in Firefox, where it jumps to whatever field was there before the new fields were shown
  139. # [16:11] <SteveF> or rather hombre a hombre
  140. # [16:12] <patrick_h_lauke> so in effect, i'll now have to code some extra magic JS mainly for FX to handle TAB key i guess, and then programmatically set focus to whatever form field has been shown after the <select>
  141. # [16:13] <patrick_h_lauke> may even add some old-school UA sniffing, just to complete the "we're forking our code like it's 1999" feel
  142. # [16:34] * Joins: clown (clown@67828CC7.C1A51174.9D42CF23.IP)
  143. # [16:36] <patrick_h_lauke> FWIW, going to add something along these lines to the code that dynamically shows those new form controls onchange: if (navigator.userAgent.indexOf('Firefox') > 0) { /* explicitly set focus() to the first newly-shown input */ } ...
  144. # [16:36] <patrick_h_lauke> not proud of it, but least impact on existing code. don't tell karl dubost... ;)
  145. # [16:40] * davidb|mtg is now known as davidb
  146. # [16:41] <@MarcoZ> Sorry, was in a mtg until now.
  147. # [16:50] <@davidb> tbsaunde, ready when you are
  148. # [16:51] <@tbsaunde> davidb: comming
  149. # [16:52] <@firebot> ryanvm@gmail.com changed the Resolution on bug 1028329 from --- to FIXED.
  150. # [16:53] <@firebot> ryanvm@gmail.com changed the Status on bug 1028329 from NEW to RESOLVED.
  151. # [16:53] <@firebot> ryanvm@gmail.com changed the Target Milestone on bug 1028329 from --- to mozilla33.
  152. # [16:53] <@firebot> https://bugzil.la/1028329 — FIXED, eitan — [AccessFu] Cancel delayed vc automove if before explicit move
  153. # [16:59] <@firebot> ryanvm@gmail.com granted in-testsuite on bug 1027315.
  154. # [16:59] <@firebot> ryanvm@gmail.com changed the Resolution on bug 1027315 from --- to FIXED.
  155. # [16:59] <@firebot> ryanvm@gmail.com changed the Status on bug 1027315 from NEW to RESOLVED.
  156. # [16:59] <@firebot> ryanvm@gmail.com changed the Target Milestone on bug 1027315 from --- to mozilla33.
  157. # [16:59] <@firebot> https://bugzil.la/1027315 — FIXED, eitan — ChildAtPoint() Does not work within web component shadow dom
  158. # [17:04] * Quits: @yzen (yzen@moz-F62769B5.cpe.pppoe.ca) (Ping timeout)
  159. # [17:05] * Joins: yzen (yzen@moz-F62769B5.cpe.pppoe.ca)
  160. # [17:05] * ChanServ sets mode: +o yzen
  161. # [17:11] * Quits: @yzen (yzen@moz-F62769B5.cpe.pppoe.ca) (Ping timeout)
  162. # [17:14] <@MarcoZ> patrick_h_lauke: As I wrote here before you came in, I believe this dates back to times when web developers biggest hobby was to completely reload pages onchange events.
  163. # [17:14] <@MarcoZ> So the user would select a new option in a select, and a whole new page would be loaded. A mouse user would never notice, because they'd first pull down the list and yada yada.
  164. # [17:15] <@MarcoZ> But keyboard users would try to navigate the select, and on first option, would get a completely new page.
  165. # [17:15] <@MarcoZ> Especially for screen reader users this meant a complete loss of context. It was, when I was still at FS, THE most asked support question when it came to web browsing for YEARS.
  166. # [17:16] <@MarcoZ> I don't know the history of why Firefox devs decided to do things the way it is now, I just know that I am thankful for the way this is working right now. Because it guarantees I'll never be trapped by such a "dynamic" page load when I change the option in a combobox/select without even having a chance to hear what the new option is.
  167. # [17:17] <@MarcoZ> Granted, today, if it is only some other controls on a page changing in the onchange, that doesn't harm screen readers. But if it is anything like a page reload, which is still very possible, we would impose a pain in the neck on our screen reader user base.
  168. # [17:18] * Quits: maxli (maxli@moz-B19F68ED.student.cs.uwaterloo.ca) (Quit: Leaving.)
  169. # [17:19] <patrick_h_lauke> ALT+DOWN is still a good option for keyboard/SR users, no?
  170. # [17:19] <patrick_h_lauke> as in that case, change isn't fired until the user made a selection
  171. # [17:20] <patrick_h_lauke> so there already is a good way (which also works in all other browsers) to allow keyboard users to change things in a select without triggering change event
  172. # [17:20] <@MarcoZ> Alt+DownArrow is something the average user simply doesn't know about.
  173. # [17:21] <patrick_h_lauke> the fact that firefox does NOT fire change event compared to every other browser in this situation is something the average developer (me included, until today) simply doesn't know about either
  174. # [17:21] <@MarcoZ> Trust me, I don't know how many times I had to explain alt+downarrow to users.
  175. # [17:21] <@MarcoZ> Over the years, it must have been hundreds of times.
  176. # [17:22] <patrick_h_lauke> well, considering that this behavior, which is exclusive to firefox, effectively requires extra JS to make something that's perfectly accessible work in FX, i'm still thinking of calling this a bug rather than a feature
  177. # [17:23] <@MarcoZ> And that does not even only include end users, but some of those web devs who coded such shitty onchange events that loaded new pages, too.
  178. # [17:23] <patrick_h_lauke> maybe worth doing a survey/quantitative analysis of how prevalent those onchange page loaders still are
  179. # [17:23] <@MarcoZ> again: I don't know the history of why onchange was implemented the way it has been. When I came on board with Firefox testing mid 2007, it was already this way. And I was grateful for it. :)
  180. # [17:24] <patrick_h_lauke> and/or putting the current behavior (NOT firing onchange) as an option in the settings, off by default, and harmonising with every other browser's implementation instead?
  181. # [17:24] <@MarcoZ> Valid points.
  182. # [17:25] <@MarcoZ> Now we'll just have to find someone who has the time and willingness to work on bug 126379.
  183. # [17:25] <@firebot> https://bugzil.la/126379 — NEW, mats — Select (size=1) onChange not called using down arrow key
  184. # [17:26] <@MarcoZ> SteveF: Do you have the tools to crawl through some major web sites to see if this onchange loading new pages is still being utilized anywhere?
  185. # [17:26] <patrick_h_lauke> probably also need some kind of agreement on 126379 that it's indeed ok to adopt the behavior of every other browser
  186. # [17:27] <SteveF> MarcoZ: i have access to 100,000 pages from top sites
  187. # [17:27] <patrick_h_lauke> right SteveF, get to work then...
  188. # [17:27] <SteveF> MarcoZ: what pattern am i looking for?
  189. # [17:27] <patrick_h_lauke> just doing HTML analysis, you'd only catch <select> elements with an onchange attribute
  190. # [17:27] <patrick_h_lauke> (rather than situations where it's added programmatically via addEvent etc)
  191. # [17:28] <@MarcoZ> patrick_h_lauke: What do you say specifically about bug 126379 comment #24?
  192. # [17:29] <patrick_h_lauke> Steve not sure you can unequivocally find all variations of this, as it involves JS, but for starters any pages with a select that has onchange, and possibly within that set those that within that attribute have "window.location"
  193. # [17:29] * icaaq is now known as icaaq|afk
  194. # [17:30] <patrick_h_lauke> MarcoZ comment 24? to me points to a mismatch between the spec and reality (in all other browsers)
  195. # [17:30] * Joins: maxli (maxli@moz-F47DD19B.student.cs.uwaterloo.ca)
  196. # [17:30] <patrick_h_lauke> consistency of implementation trumps the wording of the spec
  197. # [17:31] <@MarcoZ> patrick_h_lauke: Does the W3C spec still say the same about onchange today? After all that comment itself is years old by now.
  198. # [17:31] <patrick_h_lauke> ask SteveF ;)
  199. # [17:31] <@MarcoZ> If the W3C changed its recommendation, there would be a no-brainer to justify changing it. If, owever, the W3C still says the same, it gets harder, since strictly speaking, we're behaving according to spec, the others are not.
  200. # [17:34] <patrick_h_lauke> "we're behaving according to spec, the others are not" ah, takes me back to my Opera days...
  201. # [17:37] <@MarcoZ> And like I said, in my opinion it's better for the user, since 99.9% of users don't know about Alt+DownArrow.
  202. # [17:40] <@MarcoZ> Also, the fact that nobody really took on this bug even though it's been open for so long shows that there doesn't seem to be an easy answer despite other browsers having implemented it the other way.
  203. # [17:41] * davidb is now known as davidb|afk
  204. # [17:43] <patrick_h_lauke> it's only better for the user in the scenario of selects that trigger a page navigation onchange. in all other scenarios, it requires additional developer work to make sure things work/remain accessible
  205. # [17:46] * Quits: SteveF (chatzilla@moz-6F24D0BD.cable.virginm.net) (Ping timeout)
  206. # [17:48] <@MarcoZ> patrick_h_lauke: I can be convinced that this is actually a good change if these page loads triggered by an onchange are actually a thing of the past and that there are not really major sites still using that shit.
  207. # [17:49] <patrick_h_lauke> ...or if there's web compat reports about things breaking for keyboard users (with/without SR) on dynamic forms i guess ;)
  208. # [17:50] <patrick_h_lauke> any idea which spec comment 24 may have been referring to? HTML spec?
  209. # [17:59] * Quits: ioanachiorean_ (ioanachior@6DC7A5F5.AA1FA0D2.6A4F8DA2.IP) (Ping timeout)
  210. # [18:00] <@MarcoZ> patrick_h_lauke: No.
  211. # [18:04] <@MarcoZ> patrick_h_lauke: Just got a reply that the BBC iPlayer contact form might still be using that technique: https://iplayerhelp.external.bbc.co.uk/tv/forms/
  212. # [18:09] <@MarcoZ> OK, threw the question out on Twitter and already got a few replies, among others the one about BBC. Will retweet them as they come in and prove useful.
  213. # [18:09] <@MarcoZ> But will go offline now, dinner time.
  214. # [18:09] * Quits: @MarcoZ (marco.zehe@moz-D94BA082.dip0.t-ipconnect.de) (Quit: See you tomorrow!)
  215. # [18:11] * Joins: SteveF (chatzilla@moz-6F24D0BD.cable.virginm.net)
  216. # [18:30] * khuey|away is now known as khuey
  217. # [18:39] * Quits: clown (clown@67828CC7.C1A51174.9D42CF23.IP) (Quit: Leaving.)
  218. # [18:41] * davidb|afk is now known as davidb
  219. # [18:48] * Quits: maxli (maxli@moz-F47DD19B.student.cs.uwaterloo.ca) (Quit: Leaving.)
  220. # [18:50] <@davidb> surkov, tbsaunde, are the dependant bugs on bug 646596 all still relevant?
  221. # [18:50] <@firebot> https://bugzil.la/646596 — NEW, surkov.alexander — [meta] Implement accessibility for e10s desktop
  222. # [18:51] * Joins: isaacd (quassel@moz-3ACED3EA.hsd1.ma.comcast.net)
  223. # [18:51] * Quits: SteveF (chatzilla@moz-6F24D0BD.cable.virginm.net) (Ping timeout)
  224. # [18:57] * Joins: clown (clown@67828CC7.C1A51174.9D42CF23.IP)
  225. # [18:58] <@surkov> davidb: I don’t really follow e10s, but perhaps not since you’ve taken differnt approach
  226. # [18:58] * Quits: clown (clown@67828CC7.C1A51174.9D42CF23.IP) (Ping timeout)
  227. # [18:58] * Quits: @davidb (davidb@13F2CEC5.7672369.D8E68FF6.IP) (Ping timeout)
  228. # [18:59] * Joins: clown (clown@67828CC7.C1A51174.9D42CF23.IP)
  229. # [18:59] * clown is now known as clown_mtg
  230. # [19:05] * Quits: Gijs (gijs@moz-6FA91913.range86-173.btcentralplus.com) (Quit: out for the evening)
  231. # [19:05] * Joins: davidb (davidb@13F2CEC5.7672369.D8E68FF6.IP)
  232. # [19:05] * ChanServ sets mode: +qo davidb davidb
  233. # [19:06] * Joins: SteveF (chatzilla@moz-6F24D0BD.cable.virginm.net)
  234. # [19:11] * Joins: jamesn (jnurthen@moz-7DAF1A3B.oracle.com)
  235. # [19:17] * Joins: eeejay1 (ia2@85E41B99.CD72D3B2.5670445F.IP)
  236. # [19:22] * Quits: eeejay1 (ia2@85E41B99.CD72D3B2.5670445F.IP) (Client exited)
  237. # [19:22] * Joins: eeejay1 (ia2@85E41B99.CD72D3B2.5670445F.IP)
  238. # [19:24] <@tbsaunde> davidb: I'd be fine with those being resolved:DONTCARE
  239. # [19:25] <@davidb> tbsaunde, would obsolete be more accurate?
  240. # [19:26] * Quits: isaacd (quassel@moz-3ACED3EA.hsd1.ma.comcast.net) (Ping timeout)
  241. # [19:27] <@tbsaunde> davidb: I guess
  242. # [19:27] <@davidb> tbsaunde, ok i'd like to hear from surkov too, i think they are obsolete but i don't want to be rude :)
  243. # [19:27] <@tbsaunde> davidb: I don't really care if you keep using that bug or file a new one
  244. # [19:28] <@davidb> ack
  245. # [19:28] <@tbsaunde> but I guess if you file a new onethen we can ignore the deps for the old one without resolving them
  246. # [19:28] <@davidb> yeah but i don't really want to leave dead bugs around
  247. # [19:29] <@tbsaunde> davidb: you must really like rolling rocks up hills
  248. # [19:29] <@davidb> great exercise
  249. # [19:30] * Quits: eeejay1 (ia2@85E41B99.CD72D3B2.5670445F.IP) (Client exited)
  250. # [19:30] * Joins: eeejay1 (ia2@85E41B99.CD72D3B2.5670445F.IP)
  251. # [19:31] <@tbsaunde> davidb: heh
  252. # [19:41] * Quits: eeejay1 (ia2@85E41B99.CD72D3B2.5670445F.IP) (Client exited)
  253. # [19:43] * Joins: eeejay1 (ia2@85E41B99.CD72D3B2.5670445F.IP)
  254. # [19:44] <MattN> davidb: ping
  255. # [19:47] <@davidb> MattN, pong (was on a call)
  256. # [19:47] <MattN> hey, I was wondering about an ETA on the a11y-review on bug 1021618.
  257. # [19:47] <@firebot> https://bugzil.la/1021618 — ASSIGNED, MattN+bmo — Create the foundation for converting preference dialogs to be in-content
  258. # [19:48] <MattN> Do you need anything more from me on that?
  259. # [19:48] <@davidb> oh wow how did that fall off my radar
  260. # [19:48] <@davidb> MattN, this ping is all i need i think
  261. # [19:49] <@davidb> i will use 11 minutes now
  262. # [19:49] <MattN> ok, cool
  263. # [19:49] <MattN> thanks
  264. # [19:49] <@davidb> np
  265. # [19:50] <@davidb> MattN, can you give me a quick summary to what i'm looking at/for?
  266. # [19:51] <MattN> did you see comment 13?
  267. # [19:51] <MattN> basically I want to make sure that the in-content dialogs in about:preferences can be focused and usable by a11y tech.
  268. # [19:52] <@davidb> ok thanks
  269. # [19:53] <MattN> I just realized I probably need @label on the close button
  270. # [19:53] <@davidb> MattN, I also want MarcoZ to look at this, he won't look until tomorrow I suspect, is that ok?
  271. # [19:53] <MattN> yes, that's fine
  272. # [19:54] <@davidb> ok thanks.
  273. # [19:55] <@davidb> MattN, ok i've made him the reviewer and have demoted myself to feedback to keep this on my radar
  274. # [19:55] <@davidb> there is likely some non-invasive aria tweaking we can do
  275. # [19:55] * @davidb almost wrote aria-twerking
  276. # [19:55] <MattN> heh
  277. # [19:56] <MattN> I figured there might be some tweaking
  278. # [19:57] <@davidb> MattN, patch looks good
  279. # [19:57] <MattN> I will add a label on the close button. Do you know the best way to do that off-hand so it isn't visible? Do I use @label and hide it with CSS?
  280. # [19:58] <MattN> I'm not seeing a tooltip-like attribute on <button> https://developer.mozilla.org/en-US/docs/Mozilla/Tech/XUL/button
  281. # [19:58] <@davidb> aria-label is one way but will need to be localized
  282. # [19:59] <MattN> right, I think it will have to be localized regardless
  283. # [19:59] <@davidb> SteveF, what is the current right way to do hidden labels? (this topic comes up freq, with varied answers)
  284. # [19:59] * @davidb has to move rooms
  285. # [20:00] <MattN> for context this is a close button that is represented visually as an "X"
  286. # [20:01] * Quits: @davidb (davidb@13F2CEC5.7672369.D8E68FF6.IP) (Ping timeout)
  287. # [20:01] * Joins: davidb (davidb@13F2CEC5.7672369.D8E68FF6.IP)
  288. # [20:01] * ChanServ sets mode: +qo davidb davidb
  289. # [20:03] <@davidb> ok - back in 100 minutes
  290. # [20:03] * Quits: @davidb (davidb@13F2CEC5.7672369.D8E68FF6.IP) (Quit: Blah blah blah)
  291. # [20:05] <SteveF> MattN: is a <button> ?
  292. # [20:05] <MattN> yes, <xul:button>
  293. # [20:07] <MattN> actually, in this same file, I see "aria-label" is used on <xul:button> for a help button visually represented with a "?"
  294. # [20:20] * agibson is now known as agibson|afk
  295. # [20:24] * Joins: maxli (maxli@moz-F47DD19B.student.cs.uwaterloo.ca)
  296. # [20:26] * Quits: maxli (maxli@moz-F47DD19B.student.cs.uwaterloo.ca) (Quit: Leaving.)
  297. # [20:31] * icaaq|afk is now known as icaaq
  298. # [20:34] * Quits: jamesn (jnurthen@moz-7DAF1A3B.oracle.com) (Quit: Leaving)
  299. # [20:35] <SteveF> MattN: that should work "actually, in this same file, I see "aria-label" is used on <xul:button> for a help button visually represented with a "?""
  300. # [20:35] <MattN> ok, thanks
  301. # [20:44] * Quits: agibson|afk (agibson@moz-2C643250.gate.cable.virginm.net) (Quit: )
  302. # [20:49] * Joins: davidb (davidb@moz-F07003AF.dsl.bell.ca)
  303. # [20:49] * ChanServ sets mode: +qo davidb davidb
  304. # [20:50] * Joins: maxli (maxli@moz-F47DD19B.student.cs.uwaterloo.ca)
  305. # [20:58] * davidb is now known as davidb|afk
  306. # [20:58] * Quits: clown_mtg (clown@67828CC7.C1A51174.9D42CF23.IP) (Quit: Leaving.)
  307. # [21:07] * Joins: agibson (agibson@moz-2C643250.gate.cable.virginm.net)
  308. # [21:15] * Joins: clown (clown@67828CC7.C1A51174.9D42CF23.IP)
  309. # [21:47] * Quits: SteveF (chatzilla@moz-6F24D0BD.cable.virginm.net) (Ping timeout)
  310. # [21:50] * davidb|afk is now known as davidb
  311. # [21:53] * Joins: SteveF (chatzilla@moz-6F24D0BD.cable.virginm.net)
  312. # [21:59] * davidb is now known as davidb|afk
  313. # [22:01] * Quits: SteveF (chatzilla@moz-6F24D0BD.cable.virginm.net) (Ping timeout)
  314. # [22:01] * davidb|afk is now known as davidb
  315. # [22:07] * Quits: agibson (agibson@moz-2C643250.gate.cable.virginm.net) (Quit: )
  316. # [22:31] <@firebot> New Firefox - Keyboard Navigation bug 1029129 filed by dbolter@mozilla.com.
  317. # [22:31] <@firebot> https://bugzil.la/1029129 — NEW — Weird focus indicator to right of search box.
  318. # [22:33] * Quits: logbot (logbot@moz-58CB32ED.glob.com.au) (Ping timeout)
  319. # [22:36] <@firebot> New Core - Disability Access APIs bug 1029133 filed by dbolter@mozilla.com.
  320. # [22:36] <@firebot> https://bugzil.la/1029133 — NEW — about:app-manager (web ide) accessibility review
  321. # [22:40] * Joins: logbot (logbot@moz-58CB32ED.glob.com.au)
  322. # [22:45] * Parts: clown (clown@67828CC7.C1A51174.9D42CF23.IP)
  323. # [22:48] * Quits: anvk (anovak@C141829F.3923648E.6468E038.IP) (Quit: Leaving.)
  324. # [22:50] <@firebot> New Core - Disability Access APIs bug 1029143 filed by dbolter@mozilla.com.
  325. # [22:50] <@firebot> https://bugzil.la/1029143 — NEW, trev.saunders — Implement accessibility for sandboxed e10s.
  326. # [22:50] <@firebot> dbolter@mozilla.com changed the Resolution on bug 646596 from --- to WONTFIX.
  327. # [22:50] <@firebot> dbolter@mozilla.com changed the Status on bug 646596 from NEW to RESOLVED.
  328. # [22:50] <@firebot> https://bugzil.la/646596 — WONTFIX, surkov.alexander — [meta] Implement accessibility for e10s desktop
  329. # [22:52] <@firebot> dbolter@mozilla.com changed the Resolution on bug 649720 from --- to WONTFIX.
  330. # [22:52] <@firebot> dbolter@mozilla.com changed the Status on bug 649720 from NEW to RESOLVED.
  331. # [22:52] <@firebot> https://bugzil.la/649720 — WONTFIX — Connect toplevel document accessibles with chrome accessible parents
  332. # [22:52] <@firebot> dbolter@mozilla.com changed the Resolution on bug 669625 from --- to WONTFIX.
  333. # [22:52] <@firebot> dbolter@mozilla.com changed the Status on bug 669625 from NEW to RESOLVED.
  334. # [22:52] <@firebot> https://bugzil.la/669625 — WONTFIX — Linux/atk support for for e10s
  335. # [22:52] <@firebot> dbolter@mozilla.com changed the Resolution on bug 675155 from --- to WONTFIX.
  336. # [22:53] <@firebot> dbolter@mozilla.com changed the Status on bug 675155 from NEW to RESOLVED.
  337. # [22:53] <@firebot> https://bugzil.la/675155 — WONTFIX — [e10s] no traversal from embedded frame to child document accessible on anything but the first tab,
  338. # [22:55] * davidb is now known as davidb|afk
  339. # [22:59] * Quits: funnel (hegel@DEB31F3E.28CFCE3E.FC69BED9.IP) (Client exited)
  340. # [23:00] * Joins: funnel (hegel@DEB31F3E.28CFCE3E.FC69BED9.IP)
  341. # [23:10] * Joins: SteveF (chatzilla@moz-6F24D0BD.cable.virginm.net)
  342. # [23:27] * Quits: SteveF (chatzilla@moz-6F24D0BD.cable.virginm.net) (Ping timeout)
  343. # [23:35] * Quits: Justin_o (uid14648@moz-E77DEB21.irccloud.com) (Quit: Connection closed for inactivity)
  344. # [23:39] * Parts: patrick_h_lauke (redux@moz-D879BBA2.pres.cable.virginm.net)
  345. # [23:57] * icaaq is now known as icaaq|afk
  346. # Session Close: Tue Jun 24 00:00:00 2014

The end :)