Archive index

A11y Slackers Gitter Channel Archive 21st of December 2015

What fresh hell is THIS now? - Patrick Lauke
  1. zakim-robot
    04:55
    [ldavis] @stevef an @michiel in regards to audio playing and button readback occurring at the same time while using JAWS, this will be going before a "committee" tomorrow. I'll pose the question if this is OK or not, but was curious if anyone can "stamp" this as working as designed. I have also reached out to freedom scientific to see if they have an official statement as well. Its one of those items that we are not sure what the right answer is, but the "gut" feeling is these shouldn't play at the right time. Again appreciate the feedback!
  2. MichielBijl
    05:06
    Thank you for the update!
  3. stevefaulkner
    07:53
    @ldavis I asked @LjWatson she indicated it wasn't an issue
  4. MichielBijl
    07:56
    The mighty Léonie has spoken!
  5. MichielBijl
    07:57
    Good morning Slackers!
  6. stevefaulkner
    09:00
    @ldavis - an alternative solution (if it needs resolving) is to delay start of audio playback for a few seconds after button pressed.
  7. stevefaulkner
    09:00
    morning @MichielBijl
  8. MichielBijl @MichielBijl waves at @stevefaulkner
  9. MichielBijl
    09:17
    You're in London right? Do you have plans for January 22nd?
  10. stevefaulkner
    09:18
    I will be in Lille around that time need to check dates
  11. MichielBijl
    09:19
    That makes me a sad panda.
  12. MichielBijl
    09:21
    Would be nice to grab a drink if you're in London :)
  13. MichielBijl
    09:22
    If you're up for meeting a Dutchfucker =P
  14. stevefaulkner
    09:49
    Will get back to you after I work out availability
  15. MichielBijl
    09:49
    Cool
  16. pkra
    09:54
    @stevefaulkner thanks again! Will test it!
  17. stevefaulkner
    10:02
    @pkra ok hope it works out
  18. stevefaulkner
    10:05
    @jnurthen aria-errormessage requires new API relationship properties to be defined and implemented so won't be useful in short term...
  19. StommePoes
    17:03
    I can't see how JAWS talking over audio playing can count as "not an issue". How do you hear something being talked over? What about audio captcha? (detlev fischer @wcagtest mentioned it as a problem in the nocaptcha post by terril thompson http://terrillthompson.com/blog/682)
  20. StommePoes
    17:04
    And if it's not an issue for experienced users, does this not mean this is still a barrier to inexperienced users? I'm thinking of students using any of my products with buttons that play audio-- I can't assume they're all experienced SR/AT users.
  21. MichielBijl
    17:10
    If someone is sick of life and has a desperate need to explain aria-errormessage to some; go right ahead: w3c/aria#128
  22. MichielBijl @MichielBijl needs to cool down before posting here…
  23. StommePoes
    17:21
    What's the difference between dialog and alertdialog?
  24. StommePoes
    17:21
    one has alerty-mcAlert-type content, the other doesn't?
  25. StommePoes
    17:21
    and we assume the latter should rudely interrupt the user
  26. StommePoes
    17:21
    Is that it, though?
  27. StommePoes
    17:21
    Seems like a similar issue between describedby and errormessage
  28. StommePoes
    17:22
    too bad there's not an error role instead
  29. stevefaulkner
    17:32
    @MichielBijl Sailesh is a longtime acc person and knows his stuff, he also has strong views on some subjects ;-)
  30. StommePoes
    17:37
    It almost sounds more of a semantics argument anyway
  31. StommePoes
    17:38
    semantically, an error is an important thing. But Sailesh's argument is that we can reproduce what we need to convey to users (barring some AT bugs) today without it, so should we complicate things?
  32. MichielBijl
    17:39
    @stevefaulkner thanks for the info :) I'm trying to keep sort of neutral. I'm set not out to insult anyone. I'm just not seeing the real issue he is trying to raise. Might need to ask him about that…
  33. MichielBijl
    17:40
    @StommePoes more complicated for who?
  34. stevefaulkner
    17:42
  35. MichielBijl
    17:45
    @stevefaulkner Cool, I'll go read some! Thanks.
  36. jnurthen
    17:47
    The fact that describedby is not announced always (or in a timely fashion) is an AT feature which I think AT makers state is desireable. I don't think we are going to convince AT (and indeed ARIA is not allowed to dictate AT behaviour) so we can't use describedby to convey errors.
  37. MichielBijl
    17:48
    I'm still interested to know what Sailesh's issue with it is.
  38. MichielBijl
    17:48
    I've asked him to clarify it on GitHub.
  39. StommePoes
    17:55
    @MichielBijl more complicated spec for more complications for spec readers and code authors... that is, to paraphrase a friend of mine who was talking about code, the more spec rules there are, the more rules there are to (accidentally) break.
  40. StommePoes
    17:56
    @jnurthen if AT makers make it optional, but a form states submission failed and an input is invalid, does that mean a user gets the option (instead of the must) to explore (possible) error text?
  41. StommePoes
    17:57
    or is it, the user may never learn why the form wasn't submitted even if the input states it's invalid because possibly the AT never offers the describedby text even when the user is looking for it?
  42. StommePoes
    17:57
    As a stupid user, I wouldn't mind something to really make error messages easier to find on a page, and I mean from the browser. But then there'd have to be a standard where the browser could recognised an error message.
  43. StommePoes
    17:58
    Not necessarily an aria version. An HTML something.
  44. StommePoes
    17:58
    role, attribute, whatver.
  45. MichielBijl
    17:58
    @StommePoes I've been wondering whether there was ever a proposal for <error>. Seems like such a natural thing to include.
  46. MichielBijl
    17:59
    Like <blockquote> or <samp>
  47. StommePoes
    17:59
    That's certainly part of the argument in that github issue-- except it's limiting itself to aria
  48. StommePoes
    18:00
    or an attr: <p error>Your last name must not contain spaces, because we hateses the Dutch, hateses them</p>
  49. MichielBijl
    18:00
    So I'd totally agree if you mean that there should be an attribute or element for errors.
  50. MichielBijl
    18:00
    Yes
  51. StommePoes
    18:01
    Something that can be PD'd... not only by AT but by the AU
  52. StommePoes
    18:01
    UA
  53. MichielBijl
    18:01
    <p role="error"> maybe? The error is not with the p me thinks.
  54. StommePoes
    18:01
    I was thnking like checked=checked == checked
  55. StommePoes
    18:01
    error is a state of, there is one, or there is not one
  56. StommePoes
    18:01
    kinda Yoda
  57. MichielBijl
    18:02
    Nah, the state is not the p's, it's the inputseses
  58. StommePoes
    18:02
    so if error=error the shortcut would be like for checked or hidden. Simply having the attribute means it' represents an error
  59. StommePoes
    18:02
    the inputses haz invalid
  60. StommePoes
    18:02
    that means the value is in error, no?
  61. MichielBijl
    18:02
    Yes
  62. MichielBijl
    18:02
    But the error element describes what it ises, not what its state is
  63. StommePoes
    18:02
    the problem is that the specifics of the error, what exactly is wrong, is described in a message-- a message we cannot guarantee is reaching the peeps
  64. StommePoes
    18:03
    hm true
  65. StommePoes
    18:03
    role makes more sense there
  66. MichielBijl
    18:04
    So something like:
    <input type="date" invalid aria-describedbu="error" value="apple"> <p role="error">That is not a date you dimwit.</p>
    
  67. StommePoes
    18:04
    errormessage, I still don't see why that needs to be aria only. If someone can convince hixie that a time element or a mark element was useful (that last one hasn't convinced me yet), why not an errormessage. it states what it is.
  68. StommePoes
    18:04
    the aria-describedby wouldn't be that if we had a role of error
  69. StommePoes
    18:05
    it would make more sense to be like error="input's id"
  70. MichielBijl
    18:05
    But I would suggest <error>.
  71. MichielBijl
    18:05
    That could work too, yes
  72. StommePoes
    18:05
    <error for="input id">so this message, if it exists, is Programmatically Linked to the input with the error message </error>
  73. MichielBijl
    18:05
    But why would you want to know what the error is for?
  74. MichielBijl
    18:06
    Wait.
  75. StommePoes
    18:06
    <label for="input id"> same thing</label><input id="input id"/>
  76. MichielBijl
    18:06
    You could do <error for="id-thing"> like a label
  77. MichielBijl
    18:06
    Yeah!
  78. StommePoes
    18:06
    the label labels it, the error message labels the error-of-the-input-value
  79. MichielBijl
    18:06
    😱
  80. MichielBijl
    18:07
    So like I said, I wonder if someone has ever thought of this and if so, why it was rejected.
  81. MichielBijl
    18:07
    To the archives!
  82. StommePoes
    18:07
    Honestly, I'm not sure why this isn't in HTML, everyone's so ready to ensure the label can haz association with an input, why wouldn't an error message be just as important?
  83. StommePoes
    18:07
    I'm nearly certain someone else (several someones) have thought of this.
  84. StommePoes
    18:07
    My only surprise is why it wasn't pushed for in HTML when all that <mark> and crap were coming out of the woodwork
  85. StommePoes
    18:08
    or if it did, why <mark> and <time> made it (okay, I know time had a rocky start) but this didn't.
  86. MichielBijl
    18:08
    Maybe our HTML bunco artist @stevefaulkner knows?
  87. powrsurg
    18:12
    Not having ever worked with it, would something related to <output> be appropriate for this?
  88. MichielBijl
    18:12
    Hmm
  89. MichielBijl
    18:13
    The output element represents the result of a calculation or user action.
  90. MichielBijl
    18:13
    In essence an error is the result of a calculation…
  91. powrsurg
    18:14
    I do agree that <error> seems like it makes more sense, but this could at least give you a more semantic hook using current elements
  92. MichielBijl
    18:15
    <input id="date" type="date" invalid value="apple"> <output for="date">That is not a date you dimwit.</output>
    
  93. MichielBijl
    18:16
    Uhm
  94. MichielBijl
    18:17
    Would that be sufficient to indicate it's the error?
  95. MichielBijl
    18:17
    Yeah, a proper error element/role would be better me thinks.
  96. MichielBijl
    18:17
    But it is an interesting thought.
  97. jnurthen
    18:17
    I totally agree that something like this should be in HTML. As HTML is not part of web platform this now seems like an even more natural fit.
  98. jnurthen
    18:18
    fyi output maps to role=status so would be a live region
  99. MichielBijl
    18:18
    That is good to know.
  100. MichielBijl
    18:18
    aria-errormessage needs to point at a live region too right?
  101. jnurthen
    18:18
    not always
  102. jnurthen
    18:19
    i would say if you move focus to the item then it shouldn't be a live region as you should get it reading due to focus movement
  103. MichielBijl
    18:20
    Right.
  104. jnurthen
    18:20
    @stevefaulkner agree - isn't that the point of specs :)
  105. StommePoes
    18:27
    I suggest if <error for="input id"/> is ever proposed for HTML, then the fakeHTML spec needs to add the <buttlink/> element
  106. StommePoes
    18:27
    Someone did make a fakeTML spec right?
  107. StommePoes
    18:27
    Has stuff like the <sarcasm> tag etc in it?
  108. StommePoes
    18:28
    and <p>'s who can haz <ul>'s as children
  109. stevefaulkner
    18:49
    @StommePoes as I said 1) when listening to it at real world speeds the announcement of the button does not talk over it, 2) I suggested asking people it would effect I asked one she tried it and didn't think it was an issue, that is one data point.
  110. stevefaulkner
    18:53
    There is a problem with Firefox though as it announces progress bar values, that is a browser bug
  111. stevefaulkner
    18:55
    Re <output> there is not yet agreement by implementers how it should map so there is not interop, Apple for one does not agree it should be a default live region
  112. stevefaulkner
    18:57
    But I think <output> is an interesting idea as a container for errors
  113. MichielBijl
    19:01
    Have added that to the GitHub thread.
  114. zakim-robot
    20:42
    [cordelia] Are there best practices listed anywhere around click target size on web? I’ve seen a lot for touch target size on mobile but am wondering if there are similar guidelines for web.
  115. powrsurg
    20:44
    well in general the more area you give someone to click the more likely they'll do the right thing
  116. powrsurg
    20:44
    but no official practices I've ever seen
  117. powrsurg
    20:44
    nothing like 44x44 min for touch
  118. zakim-robot
    20:47
    [cordelia] Yeah, I guess I’m hoping for a concrete minimum value. I’m writing some documentation around accessible design practices, and using a 10x10 px button as an example of a bad practice. Would be nice to say, “That should be bumped up to at least NxN pixels."
  119. MichielBijl
    20:48
    font-size/line-height related maybe?
  120. zakim-robot
    20:53
    [cordelia] Oh true!
  121. zakim-robot
    21:07
    [gregtarnoff] Yeah, the font-size/line-height is what I was going to suggest. That should put you in the 20x20 range, although I prefer larger for buttons.
  122. powrsurg
    21:12
    My suggestion would be to look at the size that many WYSIWYG editors use for their buttons
  123. powrsurg
    21:12
    check out TinyMCE and CKeditor
  124. zakim-robot
    21:16
    [cordelia] CKeditor looks like it’s got a minimum of 26x26, which is pretty good.