Archive index

A11y Slackers Gitter Channel Archive 20th of November 2015

What fresh hell is THIS now? - Patrick Lauke
  1. MichielBijl
    Nov 20 00:02
    @StommePoes thinks, does Will Test For Beer work?
  2. MichielBijl
    Nov 20 00:03
    Doesn't work, you end up with loads of beers and friends, but no money to travel.
  3. MichielBijl
    Nov 20 00:11

    aye one one why

    I would have surely thought you'd be the a11y cat.

  4. MichielBijl
    Nov 20 00:12
    I'm with @gregtarnoff anyway
  5. zakim-robot
    05:36
    [jamesn] @garcialo: are you talking at the meetup in SF on dec 2?
  6. garcialo
    05:37
    yup
  7. garcialo
    05:37
    Are you going to be there?
  8. MichielBijl
    05:46
    @jamesn is aria-primaryaction still on the table?
  9. StommePoes
    07:44
    @MichielBijl "the a11y cat." okay, I might have to make use of that one somewhere
  10. MichielBijl
    08:07
    :D
  11. MichielBijl
    08:07
    If you won't, I will ;)
  12. stevefaulkner
    10:23
    slickers :smile:
  13. StommePoes
    13:01
    Got a big box of goodies from Freedom Scientific. Reminded me of back in the days when software was delivered in boxes with discs inside. (and paper manuals!)
  14. MichielBijl
    13:13
    That sounds ridiculous. That never happened.
  15. MichielBijl @MichielBijl thinks back to when he got SimCity for Mac OS
  16. MichielBijl
    13:39
    It was so pretty!
  17. garcialo
    13:39
    I always liked the idea of SimCity; was just never good at it.
  18. MichielBijl
    13:54
    You don't get good, you just get to the point where you optimised everything and want to start over because there is no challenge.
  19. MichielBijl
    13:56
    But that is a pretty cliche saying :p
  20. garcialo
    13:57
    You say that as if you've never heard of Magnasanti.
  21. zakim-robot
    15:15
    [rodneyrehm] https://twitter.com/allyjs_io/status/667707173066117120
  22. zakim-robot
    15:16
    [rodneyrehm] … I’ve finally released the library I wrote for focus management :simple_smile:
  23. garcialo
    15:16
    Neat! Congrats =)
  24. zakim-robot
    15:16
    [rodneyrehm] thx!
  25. craigfrancis
    16:06

    Hi Everyone, I've just been reading up on the new aria-errormessage, and was wondering if it could/should be used on a static (non-JS) form?

    As in, the page is loaded, the user fills in the form, submits it to the server, and if there is an error, should those inputs get aria-invalid="true", and aria-errormessage="id" to link them to the errors?

    Also assuming there is no JS to change aria-invalid and/or remove aria-errormessage when the user edits the values.

  26. MichielBijl
    16:51
    Good question.
  27. craigfrancis
    16:59
    I'm not sure how to take it, as ARIA seems to be going towards the idea of a JavaScript based website (web-app?), but there are times when the extra JavaScript isn't really necessary.
  28. zakim-robot
    17:01
    [bdruth] isn’t that what ARIA is geared towards to begin with? web-based JS applications?
  29. StommePoes
    17:03
    and anything else that doesn't have good html semantics
  30. craigfrancis
    17:04
    Yep, I believe so, but there are times when you can use ARIA for a non-JS websites, for example <th aria-sort="ascending"><a href="...">Heading</a><th>, where the link does a round trip to the server to update the records (imagine a table with 1,000+ records).
  31. zakim-robot
    17:04
    [gregtarnoff] ARIA was first geared toward fixing Flash stuff, but it is meant for “accessible rich internet applications” so using it with JS to make things easier for those with AT is the point.
  32. zakim-robot
    17:06
    [gregtarnoff] ARIA won’t hinder an application if used on static or state based development. It will still enhance the application with providing additional context. It’s just a super good way to make sure your dynamic/stateless applications do what is needed at a minimum. Many frameworks don’t put that first.
  33. StommePoes
    17:10
    @rodneyRehm oh cool!
  34. craigfrancis
    17:10
    So do you think that setting a aria-invalid="true" and aria-errormessage="id" when a form is submitted will cause a problem for AT if it isn't changed until the form is submitted again?
  35. StommePoes
    17:12
    hm, would you want to be told your value is invalid after you've changed it but before you've sent the form?
  36. StommePoes
    17:13
    Guess it depends actually, that's how forms used to be for everyone
  37. craigfrancis
    17:14
    I suppose it depends on how AT implements it... if the page is loaded, and it can pick up and focus the fields which are invalid (and with error messages), then that is useful... likewise when you focus on the field... but if the AT continues to state the error as you edit/leave the field, or submit the form, then that would be a problem.
  38. stevefaulkner
    17:24
    note: aria-errormessage not implemented yet
  39. craigfrancis
    17:26
    True, just excited to try implementing it on my website, but I don't want to make things worse if the AT's implement it in a way that would not work with this setup.
  40. craigfrancis
    17:27
    (side note, linking errors to input fields has been a bit of a bugbear of mine for a while)
  41. zakim-robot
    17:33
    [dylanb] @stevef: before I file a bug on the HTML 5.1 spec, have you ever noticed the mismatch between ARIA group role as it relates to the radio role and the HTML 5 spec's fieldset element? Specifically, ARIA specifies that aria-required cannot be placed on a radio role but must be placed on its group parent. HTML 5 does not support a required attribute on the fieldset element.
  42. jnurthen
    17:48
    @MichielBijl yes - still on the table. Need to complete the spec proposal this week. We have general consensus that this is something that is missing from ARIA that native implementations support
  43. jnurthen
    17:48
    @garcialo I should be presuming I get family approval to be out for another night!
  44. MichielBijl
    17:50
    @jnurthen awesome! If you want I could give feedback.
  45. jnurthen
    17:55
    @MichielBijl there will be a mail to the list when it is done. You are welcome to give feedback either on the call or on list.
  46. MichielBijl
    17:55
    Will do.
  47. jnurthen
    17:56
    @MichielBijl I hate Friday mornings when I know it is already friday night in europe
  48. MichielBijl
    17:56
    Haha, well, I hate Monday nights, when I know it's Monday morning in the US
  49. StommePoes
    17:57
    bwahahaa
  50. StommePoes
    17:57
    Well, last friday wasn't fun
  51. jnurthen
    17:57
    but everyone hates monday mornings
  52. jnurthen
    17:57
    especially knowing there is the ARIA APG call ;)
  53. MichielBijl
    17:57
    It's better to have a deep think and discussion before noon that it is after 9 hours of work.
  54. MichielBijl
    17:58
    Haha
  55. jnurthen
    18:00
    Has anyone looked at that ally.js library I saw posted? There looks to be some handy features
  56. MichielBijl
    18:01
    It's on my todo list.
  57. MichielBijl
    18:01
    So much to review this week
  58. jnurthen
    18:02
    yeah. We have devs asking all the time for a way to only do focus rings on key events not on touch/mouse
  59. StommePoes
    18:02
    Don't burn out dude
  60. StommePoes
    18:02
    Oh I have a solution I like
  61. StommePoes
    18:02
    tho not tested on touch
  62. jnurthen
    18:02
    looks to have a simple way of doing this. Only concern is potential performance implication of how they are doing it
  63. StommePoes
    18:02
    I used it extensively for our e-commerce pages
  64. StommePoes
    18:03
    They aren't just listening for keydown/mousedowns and adding/removing a class?
  65. jnurthen
    18:03
    maybe - hopefully. That is how our devs are doing it currently. I haven't reviewed the code yet - just the API docs :)
  66. StommePoes
    18:04
    I used a modified bit from Paciello group, ended up with 2 lines of jQuery and a .mouseDetected class to "unstyle" the focusses (since certain browsers leave focus behind on clicks)
  67. StommePoes
    18:05
    Because I didn't have a touch device at the time, I never implemented listening for touchstart/end. Plus I asked Patrick Lauke if that was a surefire thing and he said there are some cases where there's touch and that's not fired.
  68. StommePoes
    18:05
    or is within something else first
  69. MichielBijl
    18:07
    @StommePoes it'll be alright. I'll just take sunday and work through the whole list. It's been building up =)
  70. jnurthen
    18:08
    https://github.com/medialize/ally.js/blob/master/src/style/focus-source.js
  71. StommePoes
    18:08
    working on sundays? you monster. Sundays are for recouperating from saterdays
  72. StommePoes
    18:08
    oh that API
  73. jnurthen
    18:08
    looks to be a bit more to it than that. The gamepad comment is interesting - wonder what events those fire
  74. StommePoes
    18:08
    That does a whole lot more than simple "only show fugly focus styles w/keyboard"
  75. jnurthen
    18:09
    yeah - but there is always more to do than that!
  76. StommePoes
    18:09
    I have often wanted to be able to ask, without lots of JS cost, who all my current page focusables are
  77. jnurthen
    18:09
    yeah
  78. StommePoes
    18:09
    I looked at jQuery's :tabbables and those were expensive on large e-commerce pages
  79. dylanb
    18:09
    ok, reposting for everyone to comment on
  80. dylanb
    18:09
    before I file a bug on the HTML 5.1 spec, have you ever noticed the mismatch between ARIA group role as it relates to the radio role and the HTML 5 spec's fieldset element? Specifically, ARIA specifies that aria-required cannot be placed on a radio role but must be placed on its group parent. HTML 5 does not support a required attribute on the fieldset element.
  81. jnurthen
    18:09
    i figure i might use that in my testing tools for something - not sure what yet though!
  82. StommePoes
    18:10
    Have you found the reasoning for that (the aria demand) anywhere? It does seem weird.
  83. jnurthen
    18:11
    The aria requirement seems reasonable to me - it is required to select one of the elements in the radio group, but the radio buttons themselves of course cant be required as that is nonsensical
  84. jnurthen
    18:11
    (much like a required checkbox is nonsense too - but I lost that fight)
  85. StommePoes
    18:13
    I would rather, instead, that developers are required to set the state of one of the radios at the get-go... esp since it's not set anywhere that a user agent has to set one for you
  86. StommePoes
    18:13
    which defeats the purpose of setting it to required, if you have a UA that automatically selects the first one for you
  87. jnurthen
    18:13
    @StommePoes then you run the risk of getting incorrect data submitted. I prefer to make a user do it.
  88. StommePoes
    18:13
    You run that risk already.
  89. jnurthen
    18:14
    but if the dev sets one then you increase that risk
  90. StommePoes
    18:14
    Unless all the UAs have gone to allowing a set to be unchecked, that could be the case nowadays.
  91. jnurthen
    18:14
    i think they do
  92. StommePoes
    18:14
    I looked into this hard about 5 years ago
  93. jnurthen
    18:14
    which ones at the time didn't?
  94. StommePoes
    18:15
    I'm not sure, the ones I was testing at the time were Firefox 2, Opera 9 or 10, IE 7 and 8, Safari for Windows 3 and KHTML
  95. StommePoes
    18:15
    wow, that must have been more than 5 years ago
  96. StommePoes
    18:15
    it was about half and half, so at the time I always set someone
  97. StommePoes
    18:16
    so they'd at least be consistent.
  98. StommePoes
    18:16
    s/KHTML/Konq.
  99. dylanb
    18:16
    @jnurthen seems like it should be a bug/issue for the ARIA group or the HTML group or both - WDYT?
  100. jnurthen
    18:17
    Personally I am happy to just leave it. IMO it is a corner case and I'm not opposed to needing to use aria to solve corner cases
  101. StommePoes
    18:17
    And possibly allowing HTML5 required on fieldsets might cause its own group of bugs, since fieldsets can of course have any controls
  102. StommePoes
    18:18
    when the point would be, to hit specifically a group of radios.
  103. jnurthen
    18:18
    yeah. Perhaps they need a radiogroup element ;)
  104. StommePoes
    18:18
    <radiogroup> would get rid of a bunch of divs or nastily-verbose nested-nested fieldsets for me : )
  105. jnurthen
    18:19
    if only getting new html elements was so easy.... ah wait web components :)
  106. StommePoes
    18:19
    lawlz, true.
  107. StommePoes
    18:19
    esp since we have the roles already
  108. jnurthen
    18:19
    yep
  109. StommePoes
    18:20
    back to the DHTML days!
  110. jnurthen
    18:20
    i guess the other solution from the HTML5 perspective would be to redefine what required means on type='radio' to mean that one of the buttons with the same name is required
  111. jnurthen
    18:20
    can't do this on the aria side though
  112. StommePoes
    18:21
    yeah I wouldn't, either. Would rather aria could reflect it if already in HTML, like required etc already do.
  113. StommePoes
    18:22
    maybe using the name, browsers (or OSes?) already have it built in that only one can be selected, so... wonder if that could be a hook (one must be selected)
  114. dylanb
    18:22
    a very simple solution would be to make aria-required and required exactly the same and allow aria-required on radios
  115. jnurthen
    18:22
    @dylanb but that makes no sense
  116. StommePoes
    18:22
    Sure, as a kid, I could make all the radio buttons go "off", tho actually a station was still selected... but that was not intended behaviour
  117. dylanb
    18:22
    well it is what HTML currently defines/allows
  118. StommePoes
    18:23
    dylanb you'd put the required on which radio?
  119. jnurthen
    18:23
    @dylanb but is it useful?
  120. dylanb
    18:23
    all of the radios in the group of course
  121. dylanb
    18:23
    it is very redundant
  122. jnurthen
    18:23
    how can they all be required?
  123. dylanb
    18:23
    I am mostly worried about the inconsistency between HTML and ARIA
  124. jnurthen
    18:24
    I'm mostly worried about something useful for devs :)
  125. StommePoes
    18:24
    it would again still have to reach back to whatever part of UA or OS knows that "they share a name so there can only be One True..." part
  126. dylanb
    18:24
    @jnurthen the name attribute defines the required-ness
  127. dylanb
    18:24
    one of them is required
  128. jnurthen
    18:24
    @dylanb but we don't have that in aria
  129. StommePoes
    18:24
    whereas I see if required were set on all of them, all of them would be required.
  130. dylanb
    18:24
    @jnurthen precisely
  131. jnurthen
    18:24
    @dylanb so we can't make them the same
  132. dylanb
    18:25
    change ARIA
  133. StommePoes
    18:25
    On a related note what if you have checkbox group and want to require at least one is chosen? That goes even further into input-sanitizing
  134. jnurthen
    18:25
    no - html sucks for radio buttons
  135. jnurthen
    18:25
    also have to think of svg too
  136. dylanb
    18:25
    ok, then change HTML
  137. StommePoes
    18:25
    should HTML5/aria even go there? I'm thinking maybe not.
  138. jnurthen
    18:25
    @dylanb change html is not realistic
  139. dylanb
    18:25
    so do nothing?
  140. jnurthen
    18:25
    @dylanb why not do nothing?
  141. dylanb
    18:26
    confusing for devs?
  142. dylanb
    18:26
    I was confused
  143. jnurthen
    18:26
    not sure it really is - again, I think required radio groups is a corner case. I am happy with incosistency sometimes in corner cases if the 99% is solved in an easy way
  144. dylanb @dylanb waits for the jokes
  145. StommePoes
    18:27
    How about remove it then? I have never seen a group of radios where anyone truly intended that answering was optional. Radios imply "at least one is selected"
  146. StommePoes
    18:27
    devs could get around that with selects by having a null-value option, which is gross but popular. Grates me tho
  147. jnurthen
    18:27
    but if that is conveyed visually (with an * for example) we must convey it programatically per WCAG
  148. StommePoes
    18:27
    @dylanb can't be any jokes about confusion around here, anyways I'd beat you hands down each time so you can only ever be 2nd place
  149. dylanb
    18:28
    @StommePoes lol
  150. jnurthen
    18:28
    I need more coffee
  151. StommePoes
    18:28
    I maintain a * on a radio question is redundant, and that the trick of getting all the radios to be "off" is a trick and was never the intention. The car still played a station
  152. jnurthen
    18:29
    but if you were to use a radio group on a voting app for example it would be unfair to default a value
  153. dylanb
    18:29
    @StommePoes you have a point
  154. StommePoes
    18:29
    Hm, tho I did just have to re-do my W3C form thingie, where I had a set of radios and none of those options were true. But still, they did set it up that way on purpose.
  155. dylanb
    18:30
    but that would also require a change to HTML and ARIA
  156. StommePoes
    18:30
    jnurthen they default on gender all the time, and other things. Whether the question ought to have a "n/a" option is up to the developers, and yeah they mess it up sometimes, but still goes along with radiogroups have one selection. In my mind.
  157. jnurthen
    18:31
    i disagree and so do UX designers. They are going to design this so we must support it
  158. dylanb
    18:31
    @jnurthen three states is a select
  159. dylanb
    18:31
    semantically at least
  160. dylanb
    18:32
    does not matter what it looks like
  161. jnurthen
    18:32
    I don't have time to fight with UX designers on everything. You know how many products we have?
  162. StommePoes
    18:33
    If non-checked radio groups are okay, then shouldn't a single radio be okay?
  163. StommePoes
    18:34
    (I know it says it's not okay but I'm going with the supposition that it could be okay to have a whole unselected group)
  164. StommePoes
    18:36
    @dylanb did you say HTML does not allow radios to be checked?
  165. StommePoes
    18:36
    I found a note mentioning about if they are
  166. StommePoes
    18:37
    "Constraint validation: If an element in the radio button group is required, and all of the input elements in the radio button group have a checkedness that is false, then the element is suffering from being missing."
  167. dylanb
    18:37
    @StommePoes how do you uncheck a checked singe radio?
  168. StommePoes
    18:37
    How do you uncheck a whole group (go back to the state of nobody being checked)?
  169. dylanb
    18:37
    @StommePoes yep
  170. StommePoes
    18:37
    Also underneath the contraint I see a note "Note: If none of the radio buttons in a radio button group are checked when they are inserted into the document, then they will all be initially unchecked in the interface, until such time as one of them is checked (either by the user or by script)."
  171. StommePoes
    18:38
    So this was not the case back when I was looking, but it says it's ok now.
  172. StommePoes
    18:38
    @dylanb is this helpful? http://www.w3.org/html/wg/drafts/html/master/single-page.html#radio-button-state-(type=radio)
  173. dylanb
    18:38
    ok, so I take this discussion as a resounding "YES" to creating a bug :-)
  174. StommePoes
    18:39
    The problem is that HTML allows a radio input to have required but the aria one says it must be a fieldset?
  175. StommePoes
    18:39
    or whatever radiogroup made of
  176. dylanb
    18:39
    ARIA says it must be on the group
  177. dylanb
    18:39
    which could of course be a fieldset
  178. StommePoes
    18:39
    I can see that being a discrepancy of weirdness, yeah.
  179. dylanb
    18:40
    btw - has anyone checked what AT does when you put aria-required="true" on the fieldset?
  180. StommePoes
    18:40
    at the very least, someone may reply with some Excellent Reason why it was done that way.
  181. StommePoes
    18:40
    I could.
  182. dylanb
    18:47
    uh-oh....issue 13
  183. dylanb
    18:47
    w3c/html-aria#13
  184. dylanb
    18:47
    :-)
  185. StommePoes
    18:47
    lucky
  186. StommePoes
    18:58
    NVDA/IE when I tab into a fieldset aria-required=true,"required forms document [announced first radio]; but if I go there with "f" I only get the field, no indication (same with other quick keys, where NVDA is not in forms mode). If I have a set of radios and put required on one of them and none are checked (like in the note above), I do hear that it is required (just that one) regardless if I quicknav over to it or tab to it.
  187. jnurthen
    19:00
    if required is not on the one that you go to do you hear it as being required?
  188. dylanb
    19:00
    @StommePoes so exactly the same as the result of the group label - nice!
  189. StommePoes
    19:00
    NVDA/FF never says boo about required except when it's on the input itself.
  190. dylanb
    19:00
    :-((
  191. StommePoes
    19:01
    Ah no, tabbing into a required fieldset with radios I do get told the form is required
  192. StommePoes
    19:01
    but on a fieldset with checkboxes, nothing
  193. StommePoes
    19:02
    hm lemme try that one again
  194. StommePoes
    19:05
    Hm nope. I should go through all of these and write them down
  195. StommePoes
    19:05
    Might be NVDA being smart about the types of controls because it does that anyway
  196. StommePoes
    19:06
    @jnurthen when required is on the fieldset I only hear it announced when entering the fieldset, just once, doesn't get repeated as I go through the various inputs.
  197. StommePoes
    19:06
    kinda like legend
  198. StommePoes
    19:06
    JAWS is famously verbose in default settings, let's see what it does
  199. StommePoes
    19:12
    I'm not hearing required anywhere with JAWS unless it's on the radio itself. This is 16.
  200. StommePoes
    19:13
    In IE
  201. dylanb
    19:17
    :-(
  202. StommePoes
    19:17
    JAWS is being a bit weird in FF. I need to investigate more, I can't tell if this is my problem
  203. StommePoes
    19:18
    When I'm backing up into a form from underneath using quick-nav-by-type ("a" for radios), I'll hear the legend + required.
  204. StommePoes
    19:19
    But if I start at a heading I have above and use a to move to the first radio, I don't hear required
  205. StommePoes
    19:19
    required on the input works the same as IE and NVDA
  206. StommePoes
    19:20
    tabbing into the forms also seems iffy. So, I'm going to do this right and document it.
  207. dylanb
    19:20
    wow, that is weird
  208. StommePoes
    19:20
    it's weird but it could be me, I've only recently started using JAWS again (now I can haz copy)
  209. StommePoes
    19:21
    Will try to do this weekend.
  210. stevefaulkner
    22:40
    @dylanb thanks for filing w3c/html-aria#13
  211. zakim-robot
    23:11
    [dylanb] @stevef: my pleasure!