/irc-logs / mozilla / #accessibility / 2013-12-04 / end

Options:

  1. # Session Start: Wed Dec 04 00:00:00 2013
  2. # Session Ident: #accessibility
  3. # [01:41] * Quits: erkan^ (Erkan@moz-3085934C.adsl.online.nl) (Quit: Textual IRC Client: www.textualapp.com)
  4. # [02:21] * Joins: erkan^ (Erkan@moz-3085934C.adsl.online.nl)
  5. # [03:24] * khuey is now known as khuey|away
  6. # [03:43] * Quits: erkan^ (Erkan@moz-3085934C.adsl.online.nl) (Quit: Textual IRC Client: www.textualapp.com)
  7. # [04:34] * Quits: maxli (maxli@moz-4D28BA20.student.cs.uwaterloo.ca) (Quit: Leaving.)
  8. # [04:34] * Joins: maxli (maxli@moz-4D28BA20.student.cs.uwaterloo.ca)
  9. # [04:34] * Quits: maxli (maxli@moz-4D28BA20.student.cs.uwaterloo.ca) (Input/output error)
  10. # [05:26] * Joins: yzen (yzen@moz-A36A7FD4.cpe.pppoe.ca)
  11. # [05:33] * Quits: yzen (yzen@moz-A36A7FD4.cpe.pppoe.ca) (Ping timeout)
  12. # [05:55] * Quits: icaaq|sleeps (Adium@moz-65BC9789.cust.bredbandsbolaget.se) (Quit: Leaving.)
  13. # [06:16] * Joins: yzen (yzen@moz-A36A7FD4.cpe.pppoe.ca)
  14. # [06:16] * Joins: icaaq (Adium@DB85B79C.7DCD925.CE255B90.IP)
  15. # [06:25] * Joins: arky (arky@EE024564.64F2AF40.7AB896E.IP)
  16. # [06:42] * Quits: icaaq (Adium@DB85B79C.7DCD925.CE255B90.IP) (Ping timeout)
  17. # [06:45] * Joins: icaaq (Adium@DB85B79C.7DCD925.CE255B90.IP)
  18. # [06:52] * Quits: peteb-away (ptbrunet@moz-B51E1692.austin.res.rr.com) (Client exited)
  19. # [07:16] * Quits: icaaq (Adium@DB85B79C.7DCD925.CE255B90.IP) (Ping timeout)
  20. # [07:22] * Joins: icaaq (Adium@DB85B79C.7DCD925.CE255B90.IP)
  21. # [07:25] * Quits: icaaq (Adium@DB85B79C.7DCD925.CE255B90.IP) (Ping timeout)
  22. # [07:27] * Joins: icaaq (Adium@DB85B79C.7DCD925.CE255B90.IP)
  23. # [07:51] * Quits: icaaq (Adium@DB85B79C.7DCD925.CE255B90.IP) (Ping timeout)
  24. # [07:57] * Joins: icaaq (Adium@A3FAA897.7DCD925.CE255B90.IP)
  25. # [08:08] * Quits: arky (arky@EE024564.64F2AF40.7AB896E.IP) (Ping timeout)
  26. # [08:21] * Quits: icaaq (Adium@A3FAA897.7DCD925.CE255B90.IP) (Ping timeout)
  27. # [08:21] * Quits: yzen (yzen@moz-A36A7FD4.cpe.pppoe.ca) (Quit: yzen)
  28. # [08:23] * Joins: icaaq (Adium@A3FAA897.7DCD925.CE255B90.IP)
  29. # [08:31] * Joins: SteveF (chatzilla@moz-6F24D0BD.cable.virginm.net)
  30. # [08:35] * Quits: icaaq (Adium@A3FAA897.7DCD925.CE255B90.IP) (Ping timeout)
  31. # [08:36] * Joins: icaaq (Adium@A3FAA897.7DCD925.CE255B90.IP)
  32. # [08:41] * Joins: arky (arky@EE024564.64F2AF40.7AB896E.IP)
  33. # [08:51] * Quits: icaaq (Adium@A3FAA897.7DCD925.CE255B90.IP) (Ping timeout)
  34. # [08:51] * Joins: icaaq (Adium@A3FAA897.7DCD925.CE255B90.IP)
  35. # [08:53] * Quits: icaaq (Adium@A3FAA897.7DCD925.CE255B90.IP) (Ping timeout)
  36. # [08:54] * Quits: arky (arky@EE024564.64F2AF40.7AB896E.IP) (Client exited)
  37. # [08:58] * Joins: icaaq (Adium@moz-1B2F2583.cust.telenor.se)
  38. # [09:24] * Quits: icaaq (Adium@moz-1B2F2583.cust.telenor.se) (Ping timeout)
  39. # [09:28] * Joins: icaaq (Adium@moz-1B2F2583.cust.telenor.se)
  40. # [09:50] * Joins: rednaks (rednaks@51AF5509.74C6FD40.360EF119.IP)
  41. # [10:05] * Quits: MrMazda (fmcz@moz-8F21088B.cable.mindspring.com) (Quit: ChatZilla 0.9.86 [SeaMonkey 1.1.18/2009082712])
  42. # [10:06] * Joins: MrMazda (fmcz@moz-8F21088B.cable.mindspring.com)
  43. # [10:23] * Quits: icaaq (Adium@moz-1B2F2583.cust.telenor.se) (Ping timeout)
  44. # [10:28] * Joins: marcoz (marco.zehe@moz-9BEB582B.dip0.t-ipconnect.de)
  45. # [10:28] * ChanServ sets mode: +o marcoz
  46. # [10:42] * Quits: rednaks (rednaks@51AF5509.74C6FD40.360EF119.IP) (Quit: Téléportation !)
  47. # [11:01] * Joins: Gijs (gijs@moz-C11B0461.dsl.alice.nl)
  48. # [11:11] * Joins: erkan^ (Erkan@moz-3085934C.adsl.online.nl)
  49. # [11:24] * Joins: icaaq (Adium@moz-4595FE6F.creuna.se)
  50. # [12:03] * Quits: erkan^ (Erkan@moz-3085934C.adsl.online.nl) (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)
  51. # [12:30] * Joins: erkan^ (Erkan@F6ECD9D5.12B21C4E.6BF415CA.IP)
  52. # [12:46] * Parts: eeejay (eeejay@moz-B3973587.xen.prgmr.com) (Ex-Chat)
  53. # [12:46] * Joins: eeejay (eeejay@moz-B3973587.xen.prgmr.com)
  54. # [12:46] * ChanServ sets mode: +o eeejay
  55. # [12:46] * @eeejay waves to marcoz
  56. # [12:47] <@eeejay> i'm in israel! so our time zone differences aren't huge
  57. # [13:06] * Joins: arky (arky@B9988FC3.C6021428.FA662B63.IP)
  58. # [13:09] <SteveF> marcoz: hey no regrets you can't let noise stop bug filing
  59. # [13:11] * Quits: erkan^ (Erkan@F6ECD9D5.12B21C4E.6BF415CA.IP) (Quit: Textual IRC Client: www.textualapp.com)
  60. # [13:14] * Joins: erkan^ (Erkan@F6ECD9D5.12B21C4E.6BF415CA.IP)
  61. # [13:20] <icaaq> marcoz: can i skip to the next landmark i VO
  62. # [13:22] <icaaq> that is without using the rotor
  63. # [13:34] * Quits: icaaq (Adium@moz-4595FE6F.creuna.se) (Quit: Leaving.)
  64. # [13:36] * Joins: icaaq (Adium@moz-4595FE6F.creuna.se)
  65. # [13:36] * Quits: icaaq (Adium@moz-4595FE6F.creuna.se) (Quit: icaaq)
  66. # [13:37] * khuey|away is now known as khuey
  67. # [13:40] * Joins: icaaq (Adium@moz-4595FE6F.creuna.se)
  68. # [13:52] * Quits: arky (arky@B9988FC3.C6021428.FA662B63.IP) (Quit: Leaving)
  69. # [13:57] * Quits: @marcoz (marco.zehe@moz-9BEB582B.dip0.t-ipconnect.de) (Quit: Leaving.)
  70. # [14:02] * Joins: maxli (maxli@moz-4D28BA20.student.cs.uwaterloo.ca)
  71. # [14:06] * Quits: icaaq (Adium@moz-4595FE6F.creuna.se) (Quit: Leaving.)
  72. # [14:06] * Quits: SteveF (chatzilla@moz-6F24D0BD.cable.virginm.net) (Connection reset by peer)
  73. # [14:08] * Joins: icaaq (Adium@moz-4595FE6F.creuna.se)
  74. # [14:11] * Joins: SteveF (chatzilla@moz-6F24D0BD.cable.virginm.net)
  75. # [14:16] * Joins: surkov (surkov@13F2CEC5.7672369.D8E68FF6.IP)
  76. # [14:16] * ChanServ sets mode: +o surkov
  77. # [14:22] * Joins: marcoz (marco.zehe@moz-9BEB582B.dip0.t-ipconnect.de)
  78. # [14:23] <marcoz> Hi eeejay! Sorry was having lunch. :)
  79. # [14:24] <marcoz> SteveF: Yeah it is sometimes just so predictable what will happen...
  80. # [14:24] <marcoz> icaaq: No you cannot. The rotor is the only way IIRC.
  81. # [14:25] <SteveF> marcoz: despite the predictable, we need to work it out so need to slog on regardless :-)
  82. # [14:32] <SteveF> surkov: if you have objections to change in spec or suggestions for clarifications please comment on HTML spec bug https://www.w3.org/Bugs/Public/show_bug.cgi?id=18574
  83. # [14:33] <@surkov> SteveF: honestly I would like to see aria-hidden removed from the spec or leaved it optional :)
  84. # [14:33] <@surkov> SteveF: are you sure that needs to be part of HTML though?
  85. # [14:33] <SteveF> surkov: which spec?
  86. # [14:33] <@surkov> I meant if ARIA should define aria-hidden
  87. # [14:33] <SteveF> surkov: ARIA does
  88. # [14:34] <@surkov> what aria-hidden="false" means, when it can be used etc
  89. # [14:34] <@surkov> not now probably
  90. # [14:34] <@surkov> at least the way HTML spec does
  91. # [14:34] <SteveF> html spec only says under what conditions it overrides native semantics
  92. # [14:34] <@surkov> ok
  93. # [14:35] <@surkov> what means "true" on hidden then? (iirc spec says "true" or "false")
  94. # [14:35] <@surkov> SteveF: btw, what weak vs strong table in the spec?
  95. # [14:35] <SteveF> surkov: that column in psec is for author conformance only, it means that authors can set either
  96. # [14:36] <@surkov> ok, but it's harder to read
  97. # [14:36] <SteveF> strong is semantics that cannot be overriden by aria, weak is semantics that can be, the 3rd column in the spec defines what authors can do
  98. # [14:37] * Joins: icaaq1 (Adium@D2069856.FE797095.222B27F0.IP)
  99. # [14:37] * Quits: icaaq (Adium@moz-4595FE6F.creuna.se) (Connection reset by peer)
  100. # [14:38] <SteveF> surkov: right i wanted to put into one table, but was not liked, thats why i wrote this http://rawgithub.com/w3c/aria-in-html/master/index.html#recommendations-table :-)
  101. # [14:38] <SteveF> which I think makes it clearer for authors
  102. # [14:39] <@surkov> I see
  103. # [14:41] <SteveF> surkov: am happy if you have any suggestions on how to make the html spec tables clearer for implementers
  104. # [14:41] * Joins: peteb-away (ptbrunet@moz-B51E1692.austin.res.rr.com)
  105. # [14:43] <@surkov> SteveF: I'd be happier if aria-hidden was left in strong column, really. But if I would write about aria-hidden="false" then I would probably just say that hidden can be overridden on the same node and add a link to ARIA spec for details. I don't really know the structure of HTML spec so it's sort of hard to have good ideas for me
  106. # [14:46] <SteveF> surkov: the bug is still open on the spec so please comment there, we need to get consensus from implementers on it, at the moment we have support from some implementers for a weak hidden and running code
  107. # [14:47] <@surkov> I see
  108. # [14:48] <@surkov> aria-hidden is tough one for implementers to be in agreement
  109. # [14:48] <SteveF> surkov: if you haven't looked before here is the current support data http://www.html5accessibility.com/tests/hidden2013.html , tests 5 & 6
  110. # [14:49] <@surkov> right
  111. # [14:50] <SteveF> surkov: support is supposed to be in webkit from a year ago as reported by james craig, but when i looked at it today, the an element with hidden/aria-hidden is exposed but text content of element is not, which is a bug
  112. # [14:51] <SteveF> surkov: what we don't want is some supporting and some not as it is bad for users, so we either get agreement on yes or no for it
  113. # [14:51] * Quits: icaaq1 (Adium@D2069856.FE797095.222B27F0.IP) (Quit: Leaving.)
  114. # [14:52] <@surkov> inconsistence if bad for web developers I agree
  115. # [14:53] <@surkov> but the same time I would want to keep it as an argument to do what Google and Apple thinks right
  116. # [14:54] * Joins: yzen (yzen@67828CC7.C1A51174.9D42CF23.IP)
  117. # [14:54] <SteveF> surkov: ? I think the method has more support than just from apple/google
  118. # [14:54] <@surkov> SteveF: who's else?
  119. # [14:55] <SteveF> rich supports it, it works in JAWS/IE
  120. # [14:57] <@surkov> Rich commented he's sort of flexible about aria-hidden https://bugzilla.mozilla.org/show_bug.cgi?id=945194#c18
  121. # [14:57] <@firebot> Bug 945194 nor, --, ---, nobody, NEW, Add accessibles that have aria-hidden="false" to the tree even if HTML5 hidden or CSS hidden or disp
  122. # [14:57] <@surkov> I think if alternative would existed then he wouldn't mind about aria-hidden
  123. # [14:58] <@surkov> I'm curious what drives aria-hidden so hard rather than invest into styling support
  124. # [14:58] <@surkov> like we had before aria-hidden
  125. # [14:59] <yzen> eeejay: marcoz: thanks for the feedback
  126. # [15:00] <SteveF> surkov: the styling support has always been troublesome, rich approved of the change in the spec https://www.w3.org/Bugs/Public/show_bug.cgi?id=18574#c5
  127. # [15:00] * Joins: icaaq (Adium@D2069856.FE797095.222B27F0.IP)
  128. # [15:01] <SteveF> surkov: anyway think you and james need to talk about it as he pushed for change
  129. # [15:01] <marcoz> yzen: You're welcome! Like eeejaypointed out, take my remarks re clickable divs and spans which should be buttons with a grain of salt. I would love to see all of these ugly things disappear and be replaced with real buttons, but if that adds a huge amount of extra work, we shouldn't do it now. What we should do is, as was also mentioned, not expose a div or span within a button as another button, but apply the aria-label stuff on
  130. # [15:02] <@surkov> right, iirc James was passionate about aria-hidden
  131. # [15:02] <SteveF> surkov: I really don't have a strong objection to either way, but want to get consensus
  132. # [15:02] <@surkov> anyway iirc aria-hidden was invented for IE since they have a bad support of styling stuff
  133. # [15:02] <@surkov> I see
  134. # [15:03] <@surkov> you have a hard job to get everybody in agreement :)
  135. # [15:03] <SteveF> surkov: i thought aria-hidden was invented for AT that use only the DOM such as chromevox
  136. # [15:03] <SteveF> surkov: it needs to be done regardless of how hard it is
  137. # [15:04] <@surkov> DOM AT is like JAWS in IE, so yes
  138. # [15:04] <@surkov> if it was invented for chromevox then I see how Google gets into aria-hidden now
  139. # [15:04] <@surkov> because I missed that
  140. # [15:05] <SteveF> so why would james be so hot on it when voiceover doesn't touch the DOM...
  141. # [15:05] * Quits: khuey (khuey@moz-DB4A9C19.scl3.mozilla.com) (Ping timeout)
  142. # [15:05] <marcoz> Yes, Google ChromeVox and JAWS + IE are very similar in that they are basically browsers within browsers, re-interpreting the DOM as they see fit.
  143. # [15:05] <@surkov> not sure, they mentioned some examples where aria-hidden (true) is very helpful
  144. # [15:06] <@surkov> but I was really surprised how fast aria-hidden="false" got into life
  145. # [15:06] <marcoz> Where JAWS uses some accessibility info where it suits them in both Firefox and IE, but not much IIRC. Except for textboxes in FF now, because we took away video support from them.
  146. # [15:06] <@surkov> without ARIA spec for example
  147. # [15:06] <SteveF> surkov: i didn't like aria-hidden for a long time, but have grown to see its usefulness and see it in hidden=false
  148. # [15:07] <@surkov> can aria-hidden is helpful, do you have an use case?
  149. # [15:07] <SteveF> surkov: now if we could come to agreement on a method as simple as aria-hidden=false then we would be onto something
  150. # [15:07] <marcoz> SteveF: surkov: Same, as I blogged a few months ago. In fact, our very own AccessFu now also takes advantage of it and uses its presence as an object attribute in some circumstances in the Firefox OS UI. Because everything else would just be too complicated or unperformant.
  151. # [15:08] <SteveF> surkov: there are lots of cases where designers add visual guff that is nonsensical to AT users, such as font based icons
  152. # [15:08] <@surkov> marcoz: I know, I wasn't part of the change so I don't have technical opinion on it
  153. # [15:08] * Joins: khuey (khuey@moz-DB4A9C19.scl3.mozilla.com)
  154. # [15:08] <marcoz> surkov: SteveF: eeejayhas examples of where aria-hidden="true" is really useful in Gaia (Firefox OS UI) now, and why we need it.
  155. # [15:08] <SteveF> marcoz: yeah i have been watching threads
  156. # [15:09] <@surkov> marcoz, SteveF, what I would I like is to consider each case and see if nothing can work but aria-hidden
  157. # [15:09] <SteveF> surkov: what is the basis of your dislike of aria-hidden?
  158. # [15:09] <@surkov> perhaps all use cases aria-hidden runs into improper support of styling by browser
  159. # [15:10] <@surkov> SteveF: aria-hidden="true" just destroys the tree, say if focus goes into aria-hidden=true tree then it's lost for AT user
  160. # [15:10] <@surkov> aria-hidden="false" makes us to create an accessible tree but it's not really "rendered" to AT since it doesn't have dimensiosn
  161. # [15:11] <@surkov> many things are layout based, like text, font, etc
  162. # [15:11] <@surkov> no layout no info
  163. # [15:11] <@surkov> it's just a simple text
  164. # [15:11] <@surkov> I'm curious if you can add all necessary stuff by aria-label instead aria-hidden="false"
  165. # [15:11] <@surkov> if aria-label is not enough then probably ARIA needs another text attribute
  166. # [15:12] <SteveF> surkov: and that's the main use case for providing hidden content to AT - simple text
  167. # [15:12] <@surkov> accessible tree for simple text sounds like overkill
  168. # [15:13] <SteveF> surkov: anyway as i said we need james' and other input to make progress i think
  169. # [15:13] <@surkov> sure
  170. # [15:13] <@surkov> but have a chat between you and me is also very helpful
  171. # [15:14] <SteveF> sure :-) but I am not an implementer and I know it :-)
  172. # [15:15] <@surkov> eeejay: when you get some time then could you please summarize the need of aria-hidden in Firefox OS and if we could have something in Gecko to avoid aria-hidden?
  173. # [15:15] <@eeejay> surkov, in what forum would you like that?
  174. # [15:16] <@surkov> eeejay: email or we can have a bug
  175. # [15:16] <@surkov> named like "prove the world doesn't need ara-hidden" :)
  176. # [15:16] <SteveF> eejay: please cc me if you have a bug
  177. # [15:16] <@surkov> sure
  178. # [15:17] <@eeejay> I will call it "The Need For ARIA-HIDDEN, And The Search for Alternatives"
  179. # [15:17] <@surkov> awesome
  180. # [15:17] <SteveF> surkov: i think you are in for a hard slog if you want to kill aria-hidden
  181. # [15:18] <@surkov> yep, I never liked aria-hidden
  182. # [15:19] * Joins: davidb (davidb@13F2CEC5.7672369.D8E68FF6.IP)
  183. # [15:19] * ChanServ sets mode: +qo davidb davidb
  184. # [15:19] <@surkov> eeejay: btw, isn't it super early for you? You have about minus 3 hours relative Toronto?
  185. # [15:20] <@eeejay> surkov, i'm in israel now
  186. # [15:20] <@surkov> ah
  187. # [15:20] <@surkov> is it warm there?
  188. # [15:20] <marcoz> surkov: I must admit despite my blog post, I am still very much in favor of killing aria-hidden.
  189. # [15:21] <@surkov> cool!
  190. # [15:21] <marcoz> So SteveFwhile I support that we need a way for authors to expose extra content for ATs, I think aria-hidden may indeed not be the right thing to do.
  191. # [15:22] <marcoz> Oops SteveF meant to put a space there. :)
  192. # [15:24] <SteveF> marcoz: I am unsure, I have seen argument from authority on it and technical argument on it, we also have implementations
  193. # [15:24] <yzen> marcoz: ya
  194. # [15:25] <SteveF> marcoz: I have not seen any alternative proposal for a simple declarative method to do it yet, which is what people want i believe
  195. # [15:29] <marcoz> SteveF: I am still not sure that aria-label/aria-labelledby and aria-describedby couldn't accomplish the same. I would even be fine with adding aria-description to the spec analogous to aria-label so authors wouldn't even have to create extra elements if they want something in an additional description. But aria-hidden, CSS hacks and all that just feels hacky through and through.
  196. # [15:29] <marcoz> I am still really curious to see our own examples and if there are no alternatives.
  197. # [15:32] <SteveF> marcoz: if we could get aria-label/labelledby/describedby working consistently that would be nice, but not holding breath
  198. # [15:34] <SteveF> marcoz: you described the issues with describedby recently in your post to the wcag list
  199. # [15:45] <@firebot> surkov.alexander@gmail.com requested review from trev.saunders@gmail .com for attachment 745601 on bug 868789.
  200. # [15:45] <@firebot> Bug https://bugzilla.mozilla.org/show_bug.cgi?id=868789 nor, --, ---, nobody, NEW, Name computation for SVG is wrong
  201. # [15:50] <marcoz> eeejay: yzen: Is there an easy way to grab the pull request for bug 923139 to build with it locally?
  202. # [15:50] <@firebot> Bug https://bugzilla.mozilla.org/show_bug.cgi?id=923139 nor, --, ---, yura.zenevich, NEW, Make the phone app accessible
  203. # [15:50] <@eeejay> marcoz, add yzen's repo as a remote to git hub, fetch it, and checkout the branch
  204. # [16:02] * Joins: fxa90id (fxa90id@moz-8CCB10C8.neoplus.adsl.tpnet.pl)
  205. # [16:02] <@firebot> New Core - Disability Access APIs bug 946226 filed by eitan@monotonous.org.
  206. # [16:02] <@firebot> Bug https://bugzilla.mozilla.org/show_bug.cgi?id=946226 nor, --, ---, nobody, NEW, The Need For aria-hidden, And The Search for Alternatives
  207. # [16:06] <@eeejay> tada!
  208. # [16:06] <@davidb> surkov, trevor I'm going to jump on the pizza train for lunch (office is ordering in $12 each). you guys interested?
  209. # [16:07] <@surkov> sounds good
  210. # [16:07] <@davidb> i'll put you in the list
  211. # [16:08] <@surkov> thanks
  212. # [16:09] <@davidb> np
  213. # [16:09] <yzen> marcoz: yes what eeejay said, i just do that in b2g/gaia dir if you are building for the phone
  214. # [16:09] <@davidb> tbsaunde: you around? want in on the office pizza? $12
  215. # [16:09] <@davidb> SteveF: i'll save you a slice
  216. # [16:10] * Quits: fxa90id (fxa90id@moz-8CCB10C8.neoplus.adsl.tpnet.pl) (Ping timeout)
  217. # [16:10] <@eeejay> toronto lunchtime in #accessibility
  218. # [16:10] <SteveF> davidB: extra anchovies
  219. # [16:10] <@davidb> SteveF: noted
  220. # [16:10] <@davidb> eeejay: yeah so egocentric of us
  221. # [16:11] <@davidb> but we can save you a slice too
  222. # [16:20] <@eeejay> thx!
  223. # [16:20] * Joins: rednaks (rednaks@51AF5509.74C6FD40.360EF119.IP)
  224. # [16:26] <tbsaunde> davidb: I guess I'd do that if you haven't ordered yet
  225. # [16:27] <@davidb> tbsaunde: i'll add you
  226. # [16:27] <tbsaunde> ack
  227. # [16:27] * Quits: rednaks (rednaks@51AF5509.74C6FD40.360EF119.IP) (Ping timeout)
  228. # [16:28] <@davidb> (done)
  229. # [16:33] * Quits: icaaq (Adium@D2069856.FE797095.222B27F0.IP) (Ping timeout)
  230. # [16:36] * Quits: erkan^ (Erkan@F6ECD9D5.12B21C4E.6BF415CA.IP) (Quit: Textual IRC Client: www.textualapp.com)
  231. # [16:40] <marcoz> eeejay: yzen: That worked thanks!
  232. # [16:40] <marcoz> eeejay: yzen: Is the panel to add a contact part of that, too? Or is this a separate module? If I want to add a contact, I get as far as that panel to fill in name, last name etc., but cannot activate *any* of the text fields. The keyboard just doesn
  233. # [16:41] <marcoz> doesn't come up.
  234. # [16:41] <yzen> marcoz: afaik it loads the contacts app so i assumed it;s not part of the dialer
  235. # [16:41] <marcoz> eeejay: I've also seen problems activating text fields in Marketplace, when going Settings -> Sign up/Sign in, and trying to activate the e-mail address field there. The only thing I can activate is the Close button.
  236. # [16:42] <marcoz> But maybe those are related somehow, and maybe AccessFu problems? Other text fields such as in the WiFi settings or such work fine.
  237. # [16:42] <marcoz> yzen: Thought so, just wanted to make sure.
  238. # [16:42] <marcoz> But the problem of some text fields not activating remains.
  239. # [16:42] <@eeejay> marcoz, by activate you mean bring up the keyboard?
  240. # [16:43] <@eeejay> marcoz, i'll look into that, thanks
  241. # [16:43] * Joins: icaaq (Adium@D2069856.FE797095.222B27F0.IP)
  242. # [16:49] * khuey is now known as khuey|away
  243. # [16:59] * khuey|away is now known as khuey
  244. # [17:00] * Joins: icaaq1 (Adium@D2069856.FE797095.222B27F0.IP)
  245. # [17:00] * Quits: icaaq (Adium@D2069856.FE797095.222B27F0.IP) (Ping timeout)
  246. # [17:01] <marcoz> eeejay: Yes, that's what I meant. I hear the activation earcon, but the keyboard doesn't come up. Or in the case of the Add Contact panel, I only hear that activation earcon once, but not after that.
  247. # [17:01] * Joins: icaaq (Adium@D2069856.FE797095.222B27F0.IP)
  248. # [17:01] <marcoz> yzen: The dialer works really nicely!
  249. # [17:02] <yzen> marcoz: thanks, ill try my best to get rid of non-button buttons
  250. # [17:02] * Quits: icaaq1 (Adium@D2069856.FE797095.222B27F0.IP) (Ping timeout)
  251. # [17:07] * Quits: ivan (ivan@moz-531C3EC9.members.linode.com) (Ping timeout)
  252. # [17:08] * Joins: ivan (ivan@moz-531C3EC9.members.linode.com)
  253. # [17:19] * khuey is now known as khuey|away
  254. # [17:24] <marcoz> surkov: eeejay: I found roc's comment in bug 922751 very disheartening where he said that one can never be 100% accurate in determining obscurity. At least that's how I read it.
  255. # [17:24] <@firebot> Bug https://bugzilla.mozilla.org/show_bug.cgi?id=922751 nor, --, ---, eitan, NEW, Provide a state or method to distinguish obscured elements
  256. # [17:25] <@surkov> marcoz: for those inert subtrees might be helpful
  257. # [17:26] * Joins: rednaks (rednaks@2E4AA2D2.5FB00768.55FFA9B4.IP)
  258. # [17:29] <marcoz> surkov: But again: how do you determine with full accuracy that something is inert or obscured, or off-screen or whatever? The fact that we still might have visibility problems somewhere suggests that this is no easy task.
  259. # [17:30] <@surkov> marcoz: inert is HTML5 attribute, so if it's present then we detect it
  260. # [17:31] <marcoz> surkov: So you suggest to replace aria-hidden with inert?
  261. # [17:31] <@surkov> yes if that works
  262. # [17:31] <@davidb> Aside: I think even using my eyes there are some things I wouldn't know to call obscured or not.
  263. # [17:31] <@surkov> good point too
  264. # [17:32] <@surkov> all depends on whether you can interact with it or not
  265. # [17:32] <marcoz> surkov: Right, and programmatically, we always know what can be interacted with.
  266. # [17:32] <marcoz> Or at least I think we do.
  267. # [17:32] <@davidb> do we?
  268. # [17:32] <@surkov> or should
  269. # [17:36] <SteveF> surkov: inert does not currently hide non interactive stuff
  270. # [17:36] <@surkov> SteveF: by means of spec or?
  271. # [17:37] <@surkov> what do you mean by hide?
  272. # [17:37] * khuey|away is now known as khuey
  273. # [17:37] <@surkov> my point was inert thing is unreachable for the user so if we exposed that somehow to AT then it seems that's what we need
  274. # [17:38] <SteveF> inert content can still be visible and it may not be selectable
  275. # [17:39] <marcoz> SteveF: I am just now thinking of the AlertView in iOS apps. For example if an iPhone tells you that its battery is low. For VoiceOver, the rest of the screen goes blank. There is only the alert and the OK button. Don't know how that's done visually, though, but I would expect the Alert View to be a layer on top of the other stuff, with the other stuff showing behind or out from the sides of the alert view.
  276. # [17:40] <marcoz> But for a blind user, it is always best to not have stuff on a touch screen that cannot be somehow interacted with. So what VoiceOver does, and Android, too, btw, is completely blank out everything except the alert view.
  277. # [17:40] * @eeejay never heard of inert
  278. # [17:41] * @eeejay goes to read
  279. # [17:42] <marcoz> SteveF: surkov: So even if inert content is still somehow visible to sighted users, it should not be accessible, even for review, for blind users, because these would think they could interact with it somehow.
  280. # [17:42] * Joins: erkan^ (Erkan@moz-3085934C.adsl.online.nl)
  281. # [17:42] <SteveF> eejay: http://www.w3.org/html/wg/drafts/html/master/editing.html#inert-subtrees
  282. # [17:43] <SteveF> marcoz: yes thats why i suggest that inert should map to aria-hidden...
  283. # [17:43] <@surkov> marcoz: why wouldn't let AT to decide?
  284. # [17:43] <SteveF> suggested
  285. # [17:45] <@eeejay> inert is interesting and useful
  286. # [17:46] <marcoz> surkov: I cannot imagine any reason why AT would make inert content accessible. In fact if I encounter an app or a web site that has stuff that is obscuring other stuff, but is still accessible to me, but then not working as expected if I try to activate such items, it's a point of major frustration.
  287. # [17:46] <@eeejay> but like SteveF says, it does not signify visibility, so you can't just hide them from AT
  288. # [17:47] <@eeejay> marcoz, inert could be used in other ways too, that would have a different intention. like having visual or textual items that the user cannot interact with
  289. # [17:48] <SteveF> marcoz: note that custom modal dialog scripts are migrating to using aria-hidden=true for background content
  290. # [17:48] <@eeejay> lets say a html5 chess game, if you play black you can drag and drop the black pieces, but the white ones are the opponent, so they are marked in your browser as inert
  291. # [17:48] <marcoz> eeejay: Thought textual items that cannot be interacted with are already in existence. Paragraphs, simple text nodes, for example. They can be read, and are sort of inert by definition.
  292. # [17:49] <@eeejay> marcoz, no, they could be selected. the equivalent of inert is CSS pointer-events: none
  293. # [17:49] <marcoz> eeejay: Your example is a classic one of simple disabled states.
  294. # [17:50] <@eeejay> true
  295. # [17:50] <marcoz> eeejay: I would simply mark my opponents chess figures as disabled. They would still be there, but AT would indicate that they cannot be activated or manipulated.
  296. # [17:50] <@eeejay> maybe that was a bad case, my point was that things that are inert are not automatically of no interest to the AT
  297. # [17:52] <marcoz> eeejay: My point then, I guess, is, what the difference is between inert and disabled. From an end user perspective, they seem pretty much identical.
  298. # [17:52] <@eeejay> true
  299. # [17:53] * Quits: victorporof (victorporo@FB8E2A00.483E5FE1.9B1E38F4.IP) (Ping timeout)
  300. # [17:56] * khuey is now known as khuey|in-the-sky
  301. # [18:06] * Quits: marcoz (marco.zehe@moz-9BEB582B.dip0.t-ipconnect.de) (Quit: Leaving.)
  302. # [18:10] <@firebot> surkov.alexander@gmail.com changed the Assignee on bug 942650 from nobody@mozilla.org to surkov.alexander@gmail.com.
  303. # [18:10] <@firebot> surkov.alexander@gmail.com changed the Status on bug 942650 from NEW to ASSIGNED.
  304. # [18:10] <@firebot> Bug https://bugzilla.mozilla.org/show_bug.cgi?id=942650 nor, --, ---, surkov.alexander, ASSI, Some toolbars have unknown accessible role or worse
  305. # [18:10] <@eeejay> ok, good night!
  306. # [18:10] <@surkov> see ya
  307. # [18:11] * Joins: jongunderson (chatzilla@moz-512E350F.near.uiuc.edu)
  308. # [18:24] * Joins: victorporof (victorporo@FB8E2A00.483E5FE1.9B1E38F4.IP)
  309. # [18:36] * khuey|in-the-sky is now known as khuey|away
  310. # [18:50] <SteveF> "This is a pretty deep misunderstanding of how HTML, CSS, and ARIA work. But that's out of scope for this bug." it ain't a good bug unless i get dissed by hixie
  311. # [19:02] <@surkov> you are in permanent war
  312. # [19:05] <SteveF> if you regularly challenge a persons authority its bound to be ongoing
  313. # [19:07] * Quits: rednaks (rednaks@2E4AA2D2.5FB00768.55FFA9B4.IP) (Ping timeout)
  314. # [19:13] <SteveF> "Some analysts, such as Noam Chomsky, posit that a state of perpetual war is an aid to (and is promoted by) the powerful members of dominant political and economic classes, helping maintain their positions of economic and political superiority."
  315. # [19:13] <SteveF> http://en.wikipedia.org/wiki/Perpetual_war#In_socioeconomics_and_politics
  316. # [19:22] * khuey|away is now known as khuey|in-the-sky
  317. # [19:23] * khuey|in-the-sky is now known as khuey|on-the-ground
  318. # [19:34] * Joins: rednaks (rednaks@2E4AA2D2.5FB00768.55FFA9B4.IP)
  319. # [19:38] * Gijs is now known as Gijs_away
  320. # [19:42] * Quits: icaaq (Adium@D2069856.FE797095.222B27F0.IP) (Quit: Leaving.)
  321. # [19:45] * Joins: icaaq (Adium@D2069856.FE797095.222B27F0.IP)
  322. # [19:49] * Quits: icaaq (Adium@D2069856.FE797095.222B27F0.IP) (Quit: Leaving.)
  323. # [20:03] * Joins: icaaq (Adium@moz-200DC1CF.customers.ownit.se)
  324. # [20:08] <Hixie> SteveF: this would be a good forum to discuss it, if you'd like
  325. # [20:09] <Hixie> (bugs aren't an appropriate place for such discussions. i don't know what you want me to say instead in the bug when you say things like that -- it's not a perpetual war, i couldn't care less about dissing you, i just want to make sure others aren't making decisions based on misinformation)
  326. # [20:13] * khuey|on-the-ground is now known as khuey|away
  327. # [20:16] * Quits: yzen (yzen@67828CC7.C1A51174.9D42CF23.IP) (Quit: yzen)
  328. # [20:19] * Gijs_away is now known as Gijs
  329. # [20:26] <SteveF> hixie: go ahead you made the statement
  330. # [20:27] <Hixie> css is optional
  331. # [20:28] <Hixie> html provides the semantic layer
  332. # [20:29] <Hixie> aria strong semantics provide some defaults for certain elements that have defined semantics that aria supports
  333. # [20:29] <Hixie> other than that, aria is basically just so you can give the UA more detailed accessibility instructions for when HTML doesn't have the features you need
  334. # [20:30] <Hixie> there's therefore no relationship between CSS and ARIA when they are used correctly
  335. # [20:35] <SteveF> ok
  336. # [20:40] * Quits: jongunderson (chatzilla@moz-512E350F.near.uiuc.edu) (Client exited)
  337. # [20:46] <tbsaunde> surkov: have you tried to reproduce that crash at all?
  338. # [20:46] <@surkov> tbsaunde: not really
  339. # [20:46] <tbsaunde> any reason?
  340. # [20:46] <@surkov> until I have certain steps I don't usually try to reproduce the crash because it never works
  341. # [20:47] <@surkov> fix/assert/wait - that's the approach I do
  342. # [20:47] <tbsaunde> why not play with it a little and see if you can find something?
  343. # [20:48] <tbsaunde> reviewing patches with a gun to your head isn't really fun ;)
  344. # [20:49] <@surkov> it makes sense but I think some bugs gets depersonalized for me, I started to consider them as distracting thing from the planned work, dunno really
  345. # [20:53] <@surkov> so agree ideally an assignee should try to reproduce the crash but my expierence doesn't suggest me it makes a huge sense because I don't remember I was able to reproduce the crash with no certain steps, even more it's often you can't reproduce the crash that has certain str. So if stack doesn't suggest you anything reasonable then fix/assert/wait
  346. # [20:55] * Quits: Hixie (ianh@C6D27F7B.5EFFBB68.81BC061B.IP) (Ping timeout)
  347. # [21:03] * Joins: Hixie (ianh@C6D27F7B.5EFFBB68.81BC061B.IP)
  348. # [21:05] <SteveF> hixie:so i don't get what that has to do with what i said
  349. # [21:13] <SteveF> hixie: the expression of the meaning of hidden is reliant upon CSS
  350. # [21:15] <SteveF> hixie: so if it only works when CSS works (which as you say is optional) it is not s strong semantic
  351. # [21:16] <SteveF> hixie: no user agent honours hidden when (optional) CSS is not not enabled
  352. # [21:18] * Joins: fxa90id (fxa90id@moz-CF54A9EF.neoplus.adsl.tpnet.pl)
  353. # [21:21] <SteveF> hxie: where as they do honour aria-hidden regardless of CSS
  354. # [21:22] <SteveF> hixie: which suggests that aria-hidden is a strong semantic for AT and hidden is weak
  355. # [21:28] * Quits: SteveF (chatzilla@moz-6F24D0BD.cable.virginm.net) (Ping timeout)
  356. # [21:30] * Quits: Gijs (gijs@moz-C11B0461.dsl.alice.nl) (Quit: off for the evening)
  357. # [21:31] * Joins: yzen (yzen@moz-A36A7FD4.cpe.pppoe.ca)
  358. # [21:33] * khuey|away is now known as khuey|on-the-ground
  359. # [21:34] * khuey|on-the-ground is now known as khuey|in-the-sky
  360. # [21:47] * Quits: rednaks (rednaks@2E4AA2D2.5FB00768.55FFA9B4.IP) (Quit: Téléportation !)
  361. # [22:07] * Quits: @davidb (davidb@13F2CEC5.7672369.D8E68FF6.IP) (Quit: davidb)
  362. # [22:10] * Quits: Hixie (ianh@C6D27F7B.5EFFBB68.81BC061B.IP) (Ping timeout)
  363. # [22:13] * Joins: SteveF (chatzilla@moz-6F24D0BD.cable.virginm.net)
  364. # [22:14] * Joins: Hixie (ianh@C6D27F7B.5EFFBB68.81BC061B.IP)
  365. # [22:18] * Quits: SteveF (chatzilla@moz-6F24D0BD.cable.virginm.net) (Ping timeout)
  366. # [22:20] * Joins: rednaks (rednaks@2E4AA2D2.5FB00768.55FFA9B4.IP)
  367. # [22:25] * Quits: Hixie (ianh@C6D27F7B.5EFFBB68.81BC061B.IP) (Ping timeout)
  368. # [22:27] * Joins: SteveF (chatzilla@moz-6F24D0BD.cable.virginm.net)
  369. # [22:28] * Quits: maxli (maxli@moz-4D28BA20.student.cs.uwaterloo.ca) (Quit: Leaving.)
  370. # [22:28] * Joins: maxli (maxli@moz-4D28BA20.student.cs.uwaterloo.ca)
  371. # [22:30] * Quits: victorporof (victorporo@FB8E2A00.483E5FE1.9B1E38F4.IP) (Quit: victorporof)
  372. # [22:31] * Quits: maxli (maxli@moz-4D28BA20.student.cs.uwaterloo.ca) (Quit: Leaving.)
  373. # [22:31] * Joins: maxli (maxli@moz-4D28BA20.student.cs.uwaterloo.ca)
  374. # [22:31] * Joins: Hixie (ianh@C6D27F7B.5EFFBB68.81BC061B.IP)
  375. # [22:53] * Quits: @surkov (surkov@13F2CEC5.7672369.D8E68FF6.IP) (Quit: surkov)
  376. # [23:08] * Quits: Hixie (ianh@C6D27F7B.5EFFBB68.81BC061B.IP) (Ping timeout)
  377. # [23:14] * Joins: Hixie (ianh@C6D27F7B.5EFFBB68.81BC061B.IP)
  378. # [23:43] * khuey|in-the-sky is now known as khuey|away
  379. # [23:46] * Quits: icaaq (Adium@moz-200DC1CF.customers.ownit.se) (Quit: Leaving.)
  380. # [23:54] * Quits: rednaks (rednaks@2E4AA2D2.5FB00768.55FFA9B4.IP) (Quit: Téléportation !)
  381. # Session Close: Thu Dec 05 00:00:00 2013

The end :)