iron-input accessibility report

[lpalmaro]

Here are the accessibility developer tools audit results:

[Severe] Controls and media elements should have labels (4)[Warning] Text elements should have a reasonable contrast ratio (1)Not applicable tests (12)Passing tests (3)

Issues found:

Contrast of the text entry field box (the border) is not very strong. It's difficult to see where the box is.

In the scenario when the text field is only for numbers, it certainly helps that there is that label to the left of the text field. That said, if that label isn't there when this is implemented on a page, for example, if the field is for "enter phone number" or something number oriented, we may want to have some sort of spoken signal if a user is attempting to enter letters and that is not allowed. Right now, with VoiceOver enabled, there is simply no verbal feedback when I type letters into this field. With ChromeVox enabled though, I do hear spoken feedback for the letters as I press them, but there is no real indication that they aren't actually being typed in the field. This could lead to a confusing user experience. We should brainstorm a better way to indicate the error.

[morethanreal]

Is there a guideline on how to find a reasonable border color? The current value is from the user agent stylesheet.

Maybe there's a way to use ARIA to announce to the user when they type an invalid input, since that is done programmatically?

[lpalmaro]

+Hwi for guidance

On Wed, May 13, 2015 at 12:50 PM, Yvonne Yip notifications@github.com wrote:

Is there a guideline on how to find a reasonable border color? The current value is from the user agent stylesheet.

— Reply to this email directly or view it on GitHub https://github.com/PolymerElements/iron-input/issues/9#issuecomment-101794835 .

[hwikyounglee]

re: border color - It's at a proper balance, imo. And it largely follow MD guideline.

The example alone might make look inputs less recognizable than intended because it's not placed in a context of use. If it's a contact info entry form with a page title "New contact" and input labels say "Name" "Address" "Phone number" etc. for example, then it's likely that it's not difficult to recognize each field as a tap/click target, and when it's tapped/clicked it shows feedback with visual motion. Labels play a key role to help recognize the area (i.e. label + bottom border line) as an input field.

With that, when necessary, customizability of Polymer allows the developer to add proper styles to fine tune and enhance their creation. e.g. if a UI using this pattern turns out to be not easy to comprehend for any reason, bgcolor, 4 borders, and anything that can be added.

[alice]

Re invalid input: I think the current mechanism of simply not allowing invalid input is confusing - note that <input type=number> does allow typing something other than numbers. aria-invalid is intended to provide some hint that the value is invalid - https://www.w3.org/WAI/GL/wiki/Using_Aria-Invalid_to_Indicate_An_Error_Field#Example_2 shows a simple example of it in action, including some hint text shown when the input is invalid. Note the use of aria-describedby to attach the hint text: this is a good technique as it will be exposed as a help attribute, which tends to be spoken following a short delay after the name and value of the element.

[edit] - I see that it may use the invalid attribute already - a demo of that behaviour would be really useful here to see what the gaps are.

[morethanreal]

Fixing the missing aria-invalid attribute in https://github.com/PolymerElements/iron-validatable-behavior/pull/4, and the rest of the issues in https://github.com/PolymerElements/paper-input/issues/5.