Archive index

A11y Slackers Gitter Channel Archive 22nd of December 2015

What fresh hell is THIS now? - Patrick Lauke
  1. zakim-robot
    04:38
    [jitendra] Very good tutorial series on HTML
    https://webdesign.tutsplus.com/series/strange-and-unusual-html--cms-616
  2. garcialo
    04:39
    oh wow, that is nice
  3. garcialo
    04:39
    i've already learned something =p
  4. zakim-robot
    06:03
    [jitendra] Article series - Accessibility: Inclusion Is Not An Illusion
  5. zakim-robot
    06:04
    [jitendra] http://arc.applause.com/series/accessibility-inclusion-is-not-an-illusion/
  6. MichielBijl
    09:16
    Interesting stuff Jitendra
  7. zakim-robot
    09:39
    [jitendra] What do you people think about machine generated Alt text for photos by facebook
  8. zakim-robot
    09:39
    [jitendra] In Mark Zuckerbergs’s words
  9. zakim-robot
    09:39
    [jitendra] > We take accessibility features at Facebook very seriously. For people who are blind or can’t see the service, we want to make sure that they can experience the moments that their friends are sharing with them. So one of the things that we are doing now is that if you are blind and you can’t see a photo, we can have our AI look at the photo and read an explanation of that photo to you. It is not 100%, but it will improve and get better in the future … and I think that that is a really cool thing when you have computers that can see the world in the way that people do.
  10. MichielBijl
    09:42
    Can you manually add alt text for photos on Facebook?
  11. MichielBijl
    09:44
    For those interested in the error discussion, I'm starting another research project: https://github.com/MichielBijl/error
  12. zakim-robot
    09:49
    [jitendra] no we cant add manually
  13. MichielBijl
    09:55
    Then I think they should start there :) But it's a very interesting development non the less.
  14. stevefaulkner
    09:56
    @ldavis Bug 1234505 - HTML5 audio element scrubbers exposed as role=progressbar https://bugzilla.mozilla.org/show_bug.cgi?id=1234505
  15. MichielBijl
    10:08
    @stevefaulkner you posted the wrong URL on Twitter
  16. stevefaulkner
    10:11
    yeah fixed now
  17. MichielBijl
    10:11
    =)
  18. MichielBijl
    13:13
    Does anyone know what the link is for unofficial drafts?
  19. MichielBijl
    13:13
    Ah: http://www.w3.org/StyleSheets/TR/w3c-unofficial.css
  20. MichielBijl
    13:33
    It's still shit, but started on a proposal for an error element: https://rawgit.com/MichielBijl/error/master/proposal/index.html
  21. StommePoes
    13:57
    Does this mean we're going to be moslty wrapping blocks around our errors?
  22. StommePoes
    13:57
    Wonder if it should change to, it can be wherever flow content is expected
  23. MichielBijl
    13:58
    I just copied label changed the name and added an example =P
  24. StommePoes
    14:00
    It otherwise looks okay (I figured a lot came from label), I only wonder if it should be more like ins and del and be one of those "either-or" types of elements
  25. MichielBijl
    14:00
    Would there be cases where you'd want more than phrasing content?
  26. MichielBijl
    14:01
    To continue from twitter: yeah, like the boolean attributes on the inputs =)
  27. StommePoes
    14:01
    Thinking broadly about errors, I can see them ranging from what we're thinking of, strings of text, to being all-out "cards" with lists etc inside them (instructions are not uncommon in errors).
  28. StommePoes
    14:02
    yeah hidden makes sense, although we expect the developer to not have text in those things until/unless the value if the input is truly an error... but yeah. We don't want <error for =foo></error> sitting empty being weird.
  29. MichielBijl
    14:03
    Hmm, there is something to that.
  30. StommePoes
    14:03
    We have to think broader than HTML form error messages, since everyone and his brother has decided the web needs to imitate desktop.
  31. StommePoes
    14:03
    So think of all errors: windows errors, program errors, bank errors...
  32. StommePoes
    14:04
    It's primarily a message, but I don't necessarily see that message content as being limited to inliney phrasing thingies.
  33. StommePoes
    14:04
    I can see someone thinking, for whatever reason, of wrapping the input+invalid value inside an error. Not sure why yet, but it's occurred to me.
  34. MichielBijl
    14:05
    That could be discouraged.
  35. StommePoes
    14:05
    What happens if Retardo200 (that's the name of this cat image btw) decides for the lawlz to wrap a whole form inside error tags.
  36. MichielBijl
    14:05
    In fact, it is as it stands now =P
  37. StommePoes
    14:06
    <error><label>Fill in your first name: <input type="text"></label> First names must not include spaces</error>
  38. StommePoes
    14:06
    I don't like that either, but the question is, should it be allowed.
  39. StommePoes
    14:06
    Can we always second-guess future use-cases?
  40. MichielBijl
    14:07
    Then the browser should render Retardo200's form outside of that error element, because it only allows phrasing content (like p>
  41. StommePoes
    14:07
    How many ways should a UA be able to map all these things as matching each other
  42. StommePoes
    14:07
    <p> itself is a block...
  43. StommePoes
    14:07
    Didn't think you could put <p> in error, would have to put <p> outside <error>
  44. MichielBijl
    14:07
    I meant like what happens if you put an ul in a p
  45. StommePoes
    14:08
    Like, I can't <span><p>foo!</p></span>
  46. StommePoes
    14:08
    Yeah.
  47. StommePoes
    14:08
    But so if I need more structure in my error, how can I add that?
  48. MichielBijl
    14:08
    To me error is like label; can't have block elements.
  49. MichielBijl
    14:08
    But
  50. StommePoes
    14:08
    Now I think I'd be playing around with aria-junk
  51. MichielBijl
    14:09
    I like your idea of wrapping stuff, like you can with a blockquote
  52. MichielBijl
    14:09
    We need a bunch of examples of errors
  53. StommePoes
    14:10
    <error for="firstname"><p>First names cannot contain spaces, because we hate you, Mary Lou.</p><ul><li>Check that your name doesn't contain spaces</li><li>If your name does contain spaces, consider getting your name legally changed</li><li>Consider altering your name to camelCase</li><li>Re-fill in the input, this time without spaces</li></ul></errror>
  54. StommePoes
    14:11
    The actual error text is honestly the first line. However remediation is common. Do we want to programmatically point to that, or leave it as plain text the developer places somewhere near the error?
  55. MichielBijl
    14:12
    I think, like labels, errors should be concise, no?
  56. MichielBijl
    14:12
    But other than that, I still think that example is interesting.
  57. StommePoes
    14:14
    <label for="foo">We often have label text <span>and then we stuff a bunch of other crap in there to ensure this popup/hover-over with extra text shows to users and is heard by SR's because sometimes it's an evil gov't form and those can just be wordy no matter what you do</span></label> and while most of us would consider aria-describedby attached to a concise label, this is what many do because they see the aria stuff as a hack when "this totally works bro"
  58. StommePoes
    14:14
    Tax forms, ug.
  59. StommePoes
    14:15
    Anyway it's currently legal to add a paragraph worth of text to a label because the gov't is explaining what the current income exemption is and how it's different if you're under 18 or over 55 and blind or have a blind spouse etc etc.
  60. StommePoes
    14:15
    It's gross, but legal.
  61. MichielBijl
    14:16
    Added both examples: https://github.com/MichielBijl/error
  62. StommePoes
    14:17
    Ha, I like the resources: empty array
  63. MichielBijl
    14:17
    Needs to add I needz
  64. StommePoes
    14:17
    yeses
  65. StommePoes
    14:18
    I currently wrestling with a whole bootstrappy dropdown thingie that is covered with menus and menuitems and stuff
  66. StommePoes
    14:18
    I can't decide if I should leave it or turn it into navigation. It's mostly navigation, but not entirely. Also <li>Heading 1</li> ug
  67. MichielBijl
    14:19
    I don't know enough about menus, especially not after that recent GitHub issue.
  68. StommePoes
    14:25
    I'm wondering if I should propose we make two dropdowns, and tell devs who want to use them that one is for "context menus" where the majority of options are buttony in nature (the Do Stuff on the current page) or form controlly by nature, and the other is a navigation menu, where the submenus are primarily links. But then someone may ask what if the subs are mixed? Then I'm like well but with all the menu/menuitem roles we're putting AT into an applicationy kind of state, what if you have these headings interspersed? Will they consistently, on all combos of AT/UA/OS, be available to the user?
  69. zakim-robot
    15:33
    [gregtarnoff] Anyone need any assistance with accessibility assessment and remediation, I am available after the holidays.
  70. zakim-robot
    18:17
    [jessebeach] Does anyone know why the disabled attribute removes an input from the tab ordering?
  71. zakim-robot
    18:19
    [jessebeach] That seems like bad behavior, because this makes inputs functionally invisible to screen reader users
  72. zakim-robot
    18:20
    [jessebeach] Perhaps we really want 'readonly' instead of disabled?
  73. MichielBijl
    18:23
    @jessebeach I recall a conversation where @Heydon and I were wondering the same. I believe it is default UI behaviour (and has been for a long time).
  74. zakim-robot
    18:23
    [jessebeach] well, that doesn't really work because a disabled element doesn't get submitted by a form
  75. MichielBijl
    18:23
    I can look up said conversation.
  76. MichielBijl
    18:26
    Unfortunately Twitters search sucks…
  77. MichielBijl
    18:29
    In any case, I believe it was in a debate about aria-current, and whether removing the current page anchor from a site navigation would be confusing.
  78. garcialo
    18:52
    @jeseebeach I'm not really seeing what the problem is with removing disabled elements from the tab order
  79. garcialo
    18:53
    The whole point is that it's irrelevant; I think it would actually be confusing to have it be in the tab order
  80. zakim-robot
    18:55
    [cordelia] it’s still in the page’s list of input fields
  81. garcialo
    18:59
    So, it should be removed from the page altogether? Or be displayed, but inform the user that it's disabled, like "required?"
  82. zakim-robot
    19:56
    [ldavis] @stevef: just saw the bug you filed on the progress bar. Not seeing this in chrome, but was requested to try firefox from freedom scientific on the other issue of audio playback and JAWS reading and noticed this too. Thanks for getting that one on the books
  83. zakim-robot
    20:48
    [devonpersing] in general if you need users to be able to access a field to read it, readonly is the way to go, but avoiding needing to make fields disabled or readonly in general is recommended.
  84. zakim-robot
    21:25
    [cordelia] I think I’d be confused if my focus landed on an input field that I couldn’t actually fill in.
  85. garcialo
    21:26
    Agreed
  86. zakim-robot
    21:36
    [jessebeach] If we can't tab into a field that is disabled, that field is then functionally and actually hidden from non-visual users
  87. garcialo
    21:36
    What functionality does a disabled have?
  88. zakim-robot
    21:36
    [jessebeach] to indicate that a field exists, but is not interacable
  89. zakim-robot
    21:37
    [jessebeach] maybe because there's another control that needs to be toggled first
  90. zakim-robot
    21:37
    [jessebeach] When you see a checkbox and below it a disabled textfield, it indicates that the checkbox controls the textbox
  91. zakim-robot
    21:37
    [jessebeach] This is apparent visually, but aurally, it is not, if the existence of the textbox is hidden entirely
  92. garcialo
    21:38
    But if you check it, then it will be enabled and will be discoverable. If you don't check it, it doesn't matter.
  93. zakim-robot
    21:38
    [jessebeach] Would it be ok to simply visually hide all disabled fields?
  94. garcialo
    21:38
    I think so, yes.
  95. zakim-robot
    21:38
    [jessebeach] then [disabled] {display: none;} should be the default user agent styling, no?
  96. zakim-robot
    21:39
    [jessebeach] because it functionally is the equivalent right now for screen reader users
  97. garcialo
    21:40
    I think that would be nice, but I could see just introducing that behavior causing issues...since you would be effectively be changing a lot of current UIs that are built with the assumption that they aren't hidden by default.
  98. zakim-robot
    21:40
    [cordelia] I disagree. Disabled input fields aren’t in the tab order, but they’re still readable to screenreader users if they’re navigating element by element on the page, or navigating via a list of input fields.
  99. zakim-robot
    21:41
    [cordelia] vs. [disabled] {display: none; } which is not even readable
  100. zakim-robot
    21:41
    [cordelia] If you have a checkbox that toggles a textbox’s disabled state, could you use aria-controls on the checkbox to indicate that relationship?
  101. zakim-robot
    21:42
    [jessebeach] I don't have an intuition here about whether screen reader users will use the virtual cursor to move through a form and expect to find disabled elements that aren't in the tab order
  102. zakim-robot
    21:42
    [cordelia] I think of disabled fields as similar to help text in a form — they aren’t focusable or actionable, but they give you additional information about the state of that form.
  103. zakim-robot
    21:43
    [jessebeach] all I'm saying is, in practice, the visibility, but lack of interactivity with disabled fields is used to convey information in the visual medium
  104. zakim-robot
    21:43
    [jessebeach] We don't really have the equivalent in the aural medium.
  105. zakim-robot
    21:44
    [jessebeach] @cordelia: I'm not sure the implementation of aria-controls in this circumstance
  106. zakim-robot
    21:44
    [jessebeach] I don't think any ATs would announce this relationship
  107. zakim-robot
    21:45
    [jessebeach] "I think of disabled fields as similar to help text in a form"
  108. zakim-robot
    21:45
    [cordelia] ^ And my quote there is assuming it’s always disabled.
  109. zakim-robot
    21:46
    [cordelia] Like “Here’s the information we already know about you, now fill in the rest."
  110. zakim-robot
    21:46
    [jessebeach] I have heard of users who describe the virtual cursor as their "eyes" when moving about the page, so in that sense, being able to perceive a disabled field with it is analogous
  111. zakim-robot
    21:46
    [jessebeach] @cordelia: I think that would be read-only
  112. zakim-robot
    21:46
    [jessebeach] read-only gets submitted with the form; disabled field values do not
  113. zakim-robot
    21:46
    [cordelia] Oh true! Guh, getting my properties confused sorry.
  114. zakim-robot
    21:47
    [jessebeach] I guess what I'm looking for is a confirmation from a screen reader user that they understand that disabled fields are not in the tab order, but can be accessed via the virtual cursor and hot key combos
  115. zakim-robot
    21:58
    [devonpersing] also good to thing about users with cognitive issues who might be able to see the fields, but can’t understand why they can’t give them focus or click on them; AT users are actually at an advantage since they’ll hear that a field is disabled, whereas other users need to guess.
  116. zakim-robot
    22:00
    [devonpersing] not to make it more complicated. :smile:
  117. StommePoes
    22:07
    I would assume if disabled inputs were a problem, we'd have heard of them by now, seeing's how they're around in this state since 1999 or so
  118. StommePoes
    22:07
    maybe earlier really
  119. zakim-robot
    22:52
    [jessebeach] @StommePoes, that occurred to me as well. But just because something has always been, doesn't mean it always should be
  120. zakim-robot
    22:58
    [duckinator] I suspect it could be a problem if you customize the styling of a form element. E.g. if you do some of the horrible hacky things to customize how radio buttons and checkboxes look.
  121. jareds
    23:08
    As a screen reader user I just tab through a form to fill it out. If there is an error or I need more explination of what is required for a field I will enable my virtual cursor and use arrow keys to read the entire form.
  122. jareds
    23:09
    Granted I've been using the internet for almost 20 years and am a software developer so am probably on the upper end of screen reader proficiency.