A11y Slacker archive 2015-10-12

zakim-robot

14:36

[Alice Boxhall, a11y] @jitendra: It seems like a good way to be conservative with space on small screens while avoiding most of the negatives of placeholder-as-label.
zakim-robot

14:45

[jitendra, a11y] but it is not showing any space
zakim-robot

14:45

[jitendra, a11y] label just goes above the input text
zakim-robot

14:46

[dylanb, a11y] @jitendra: if you do it right, it does save some space http://dylanb.github.io/todomvc/index.html
zakim-robot

14:48

[jitendra, a11y] it makes the label tiny
zakim-robot

14:49

[jitendra, a11y] forms are very important so small label text can be difficult to read for some people
zakim-robot

14:49

[jitendra, a11y] as mentioned in comment in webaxe article
zakim-robot

14:49

[Alice Boxhall, a11y] Yes, I think it makes a compromise trade-off between two competing restrictions. The larger text is available until the user begins to type.
zakim-robot

14:50

[dylanb, a11y] just don't disable pinch to zoom
zakim-robot

14:50

[jitendra, a11y] @dylanb ur page looks like this in my mobile
zakim-robot

14:50

[jitendra, a11y] Slack for Android Upload
zakim-robot

14:50

[dylanb, a11y] that page is not optimized for mobile
zakim-robot

14:50

[dylanb, a11y] but it shows the concept
zakim-robot

14:52

[jitendra, a11y] oh ok
zakim-robot

14:53

[jitendra, a11y] Concept i know that's what I commented here http://www.webaxe.org/floated-labels-still-suck/
zakim-robot

14:54

[jitendra, a11y] Dennis said

A bit better but I still don’t advocate. If the label remains shown when focused, then why stray from the traditional design? This pattern also breaks basic rules/needs: 1. the placeholder attribute is used incorrectly, and there’s no way to support a label and correctly implemented placeholder (see this post’s content above for details) 2. May be confusing or distracting to users with a cognitive disability; 3. By default, browsers render placeholder text with insufficient color contrast by default in browsers so this must always be patched (which is hardly ever done). 4. When label appears at bottom, the text is too small.
zakim-robot

14:54

[Alice Boxhall, a11y] " If the label remains shown when focused, then why stray from the traditional design?"
zakim-robot

14:54

[Alice Boxhall, a11y] You already answered that: the label shrinks dramatically when the user begins entering text
zakim-robot

14:55

[Alice Boxhall, a11y] "the placeholder attribute is used incorrectly" - this is an implementation detail which is not true in the Polymer implementation (and probably others), but
zakim-robot

14:55

[Alice Boxhall, a11y] " there’s no way to support a label and correctly implemented placeholder" - yes, that is definitely a downside
zakim-robot

14:55

[Alice Boxhall, a11y] "May be confusing or distracting to users with a cognitive disability" I would very much like to see user research on this
zakim-robot

14:56

[Alice Boxhall, a11y] "By default, browsers render placeholder text with insufficient color contrast by default in browsers so this must always be patched (which is hardly ever done)." Completely irrelevant in this case, because it's not a placeholder
zakim-robot

14:56

[Alice Boxhall, a11y] "When label appears at bottom [top], the text is too small." Again, yes, this is a downside, but the text is readable for everyone before the user starts typing.
zakim-robot

14:56

[Alice Boxhall, a11y] So no, it's definitely not perfect, but it trades off some other concerns
zakim-robot

14:57

[Alice Boxhall, a11y] e.g. fitting more form fields on a mobile screen and avoiding having to scroll as much
zakim-robot

14:57

[jitendra, a11y] His comments was given on this this example which I posted with my comment on article http://mozmonkey.com/wp-content/files/PlaceholderLabels/
zakim-robot

14:57

[jitendra, a11y] By do people have problem with scrolling on Mobile?
zakim-robot

14:59

[jitendra, a11y] And if form is long or user's mobile height is small he will anyway have to scroll
zakim-robot

15:02

[jitendra, a11y] And do we have any study on how floating labels benefited users?
zakim-robot

15:05

[jitendra, a11y] Many people use Form autofillers like 1password or Lastpass
zakim-robot

15:06

[jitendra, a11y] and sometime these tools autofill the input
zakim-robot

15:18

[jitendra, a11y] By the way Google's Material Design Website also have problem with color contrast
zakim-robot

15:18

[jitendra, a11y] I just tested with their float input example from website
zakim-robot

15:18

[jitendra, a11y] http://take.ms/vw4yN
deborahgu

15:26

I have found some real problems when my autofiller fills on placeholder/non-label fields, and guesses wrong, and I can't tell.
zakim-robot

15:35

[Alice Boxhall, a11y] Screenshot of paper-input demo on Chrome for iOS
zakim-robot

15:35

[Alice Boxhall, a11y] Sorry for disappearing, had to go get a bus. Here's a screenshot from my phone of the polymer implementation of floated label
zakim-robot

15:35

[Alice Boxhall, a11y] @jitendra What text are you testing there, sorry?
zakim-robot

15:36

[Alice Boxhall, a11y] @jitendra: Re user studies (https://web-a11y.slack.com/archives/general/p1444662169000314) - that's a really good question, and I'll see if there's anything public on that
zakim-robot

15:37

[Alice Boxhall, a11y] Though I do note that it's "paving a cow path" where people are already (mis-)using the placeholder for this purpose
zakim-robot

15:38

[Alice Boxhall, a11y] And re https://web-a11y.slack.com/archives/general/p1444662368000316 - yes, I agree that is a problem, but I think it's strictly an improvement over the case @deborahgu describes where the placeholder is used as the label, and then there is no label when the field has been autofilled
zakim-robot

15:47

[jitendra, a11y] @alice: I'm checking from here http://www.getmdl.io/components/index.html#textfields-section
zakim-robot

15:48

[Alice Boxhall, a11y] @jitendra: Ah yeah, looks like that site has a lot of contrast issues. Will pass that on, thanks.
zakim-robot

15:49

[jitendra, a11y] I personally think the old design approach of having an always visible label above the input is still the best solution for better Accessibility and Usability.
zakim-robot

15:49

[jitendra, a11y] And I as a user never had any problem with that
zakim-robot

17:01

[Alice Boxhall, a11y] @jitendra Bug for the contrast issues on http://getmdl.io: google/material-design-lite#1731
zakim-robot

17:02

[Alice Boxhall, a11y] Feel free to file any other a11y bugs there, and ping me if they don't get any traction and I'll bug someone about it
deborahgu

17:07

jtendra: the many ways in which modern minimalist design trends break all usability best practice boggle the mind. I would really like to see if any sites that switched to minimalist (e.g. placeholder form labels, icons without text labels) on desktop have done any A/B testing on revenue. I feel like you could get some really good results if there were any e-commerce sites who had done that testing.
zakim-robot

17:31

[Claire Ryberg, a11y] Shouldn't an element with role="alert" be read by a screen reader as soon as it is updated or shown? I'm not getting any feedback from NVDA or JAWS in these examples:
http://www.w3.org/WAI/WCAG20/Techniques/working-examples/ARIA19/aria-alert-validation.html
http://www.oaa-accessibility.org/example/1/
zakim-robot

17:31

[Claire Ryberg, a11y] Am I misunderstanding for role="alert" is supposed to behave?
zakim-robot

17:51

[dylanb, a11y] @cryberg: works just fine for me
zakim-robot

18:07

[Claire Ryberg, a11y] @dylanb: It's announcing whatever is in the alert element when it updates? What are you using? I should have mentioned I'm on IE11
zakim-robot

18:19

[dylanb, a11y] @cryberg: The first example has aria-atomic="true", therefore all the content gets announced when small changes are made
zakim-robot

18:20

[dylanb, a11y] There is much confusion (at least in my mind) as to what should happen when an item with role=
alert" is changed from display:none to some other display property. @stevef might actually know a resource that tells us what should happen
zakim-robot

18:24

[Claire Ryberg, a11y] @dylanb: It seems that what you are hearing is what I would expect it to do. But when using JAWS in IE11, I do not hear anything at all after hitting the submit button in that first example.
Shouldn't it read "Please enter you last name" etc after hitting submit? Is that what you are hearing?
zakim-robot

18:25

[dylanb, a11y] I am using OS X, VO and Safari
zakim-robot

18:25

[dylanb, a11y] and yes, it is working
zakim-robot

18:25

[dylanb, a11y] what version of JAWS are you using
zakim-robot

18:25

[dylanb, a11y] ?
zakim-robot

18:26

[Claire Ryberg, a11y] 16.0
I guess I'm wondering if I have found a bug or something.
Also, I came across this that has a small part about how it is supposed to act when the display property is changed https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/ARIA_Techniques/Using_the_alert_role
zakim-robot

18:27

[Claire Ryberg, a11y] Example 4
zakim-robot

18:28

[dylanb, a11y] yes, but note the "Note" in that document
zakim-robot

18:28

[dylanb, a11y] " Opinons may differ on how assistive technology should handle this technique. The information provided above is one of those opinions and therefore not normative."
zakim-robot

18:31

[Claire Ryberg, a11y] That's valid, thanks for pointing it out. I'm having the same issue in the second example I posted, though, which isn't relying on changing the display
zakim-robot

18:31

[Claire Ryberg, a11y] http://www.oaa-accessibility.org/example/1/ has a static region with role="alert" that also isn't being read
zakim-robot

18:34

[dylanb, a11y] sounds to me like a bug with IE11 and/or JAWS 16
zakim-robot

18:34

[dylanb, a11y] did you try NVDA with IE11?
zakim-robot

18:38

[Claire Ryberg, a11y] Yeah. Just checked again with NVDA with IE11 and I'm also getting no feedback for both examples
zakim-robot

18:39

[Claire Ryberg, a11y] Maybe a bug with IE11?
zakim-robot

20:09

[bruth, a11y] @gregtarnoff: is there a "good practice" as far as handling JAWS 'modes' (navigation/form) when working within an SPA?
zakim-robot

20:10

[bruth, a11y] we're having a hard time with a login form and trying to get JAWS to focus on the area that displays the error message when a login error happens - it doesn't want to get back to navigation mode once it's in form mode
zakim-robot

20:10

[bruth, a11y] just wondering if you seen any good examples on that kind of stuff that you could link me
zakim-robot

20:10

[dylanb, a11y] @bruth why not focus on the first field with an error?
zakim-robot

20:11

[bruth, a11y] the fields don't have errors, per se - it's just username/password/submit
zakim-robot

20:11

[dylanb, a11y] http://dylanb.github.io/bower_components/a11yfy/examples/form-validation.html
zakim-robot

20:11

[bruth, a11y] so, the errors are things like "couldn't log you in"
zakim-robot

20:11

[Greg Tarnoff, a11y] I’m not versed enough with JAWS modes.
zakim-robot

20:11

[bruth, a11y] @gregtarnoff: kk, np - thx
zakim-robot

20:12

[bruth, a11y] it's more a flash message type thing, I guess @dylanb
zakim-robot

20:12

[dylanb, a11y] The error's are still associated with both form fields, so you could make the association with both fields and focus on the first one
zakim-robot

20:12

[dylanb, a11y] or simply associate with the first one
zakim-robot

20:12

[bruth, a11y] conceivably - or the system may not be able to connect with the backend :wink:
zakim-robot

20:12

[bruth, a11y] but, that's an approach to doing it, at least
zakim-robot

20:13

[dylanb, a11y] in which case the error is associated with the submit button, so you just leave the focus where it is
zakim-robot

20:13

[Greg Tarnoff, a11y] I agree with @dylanb as far as a method. Seems to make sense.
zakim-robot

20:13

[bruth, a11y] hey, plan is better than no plan - we'll give it a shot!
zakim-robot

20:14

[dylanb, a11y] @bruth: IMO it is a little better because a user can simply start typing and does not need to tab first to get to the appropriate field
zakim-robot

20:14

[bruth, a11y] sure, makes sense
zakim-robot

20:14

[dylanb, a11y] you might want to combine the association with an aria live update because not all screen readers announce accessible name changes immediately
zakim-robot

20:18

[bruth, a11y] you bet, we’re leaning on aria live pretty heavily already
zakim-robot

20:22

[bruth, a11y] welcome @astevens

Gitter Channel Archive 12th of October 2015