New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Some input boundaries lack sufficient contrast #7053

Closed
anevins12 opened this Issue May 31, 2018 · 30 comments

Comments

Projects
None yet
5 participants
@anevins12
Contributor

anevins12 commented May 31, 2018

Describe the bug
The border styles of some input fields are at contrast levels below 3:1 (between border and surrounding background) and these input fields may not be obvious to people with visual impairments.
Referring to 'Non-text Contrast' WCAG: https://www.w3.org/WAI/WCAG21/Understanding/non-text-contrast.html

For instance, the input underneath the "Page Attributes" title contains a border colour of '#ccd0d4', which has a 1.55:1 contrast ratio against white.

example-of-input-with-low-contrast-border

The CSS bound to this input is shared across many other inputs:
.edit-post-sidebar .input-control, .edit-post-sidebar input[type=text], .edit-post-sidebar input[type=search], .edit-post-sidebar input[type=radio], .edit-post-sidebar input[type=tel], .edit-post-sidebar input[type=time], .edit-post-sidebar input[type=url], .edit-post-sidebar input[type=week], .edit-post-sidebar input[type=password], .edit-post-sidebar input[type=checkbox], .edit-post-sidebar input[type=color], .edit-post-sidebar input[type=date], .edit-post-sidebar input[type=datetime], .edit-post-sidebar input[type=datetime-local], .edit-post-sidebar input[type=email], .edit-post-sidebar input[type=month], .edit-post-sidebar input[type=number], .edit-post-sidebar select, .edit-post-sidebar textarea, .editor-post-publish-panel .input-control, .editor-post-publish-panel input[type=text], .editor-post-publish-panel input[type=search], .editor-post-publish-panel input[type=radio], .editor-post-publish-panel input[type=tel], .editor-post-publish-panel input[type=time], .editor-post-publish-panel input[type=url], .editor-post-publish-panel input[type=week], .editor-post-publish-panel input[type=password], .editor-post-publish-panel input[type=checkbox], .editor-post-publish-panel input[type=color], .editor-post-publish-panel input[type=date], .editor-post-publish-panel input[type=datetime], .editor-post-publish-panel input[type=datetime-local], .editor-post-publish-panel input[type=email], .editor-post-publish-panel input[type=month], .editor-post-publish-panel input[type=number], .editor-post-publish-panel select, .editor-post-publish-panel textarea, .editor-block-list__block .input-control, .editor-block-list__block input[type=text], .editor-block-list__block input[type=search], .editor-block-list__block input[type=radio], .editor-block-list__block input[type=tel], .editor-block-list__block input[type=time], .editor-block-list__block input[type=url], .editor-block-list__block input[type=week], .editor-block-list__block input[type=password], .editor-block-list__block input[type=checkbox], .editor-block-list__block input[type=color], .editor-block-list__block input[type=date], .editor-block-list__block input[type=datetime], .editor-block-list__block input[type=datetime-local], .editor-block-list__block input[type=email], .editor-block-list__block input[type=month], .editor-block-list__block input[type=number], .editor-block-list__block select, .editor-block-list__block textarea, .components-popover .input-control, .components-popover input[type=text], .components-popover input[type=search], .components-popover input[type=radio], .components-popover input[type=tel], .components-popover input[type=time], .components-popover input[type=url], .components-popover input[type=week], .components-popover input[type=password], .components-popover input[type=checkbox], .components-popover input[type=color], .components-popover input[type=date], .components-popover input[type=datetime], .components-popover input[type=datetime-local], .components-popover input[type=email], .components-popover input[type=month], .components-popover input[type=number], .components-popover select, .components-popover textarea

To Reproduce
Steps to reproduce the behavior:

  1. Edit a post;
  2. Press on the settings icon at the top right
  3. Open up the "Page Attributes" section
  4. See the input field with the border colour of '#ccd0d4'

Expected behavior
The colour should be darkened to meet a (minimum) ratio of 3:1. Example of a shade of grey that meets this ratio is '#8D96A0'

Desktop (please complete the following information):

  • Ubuntu
  • Chrome (latest)
    Some devices may use their own styling for input fields and this does not concern those cases.
@danielbachhuber

This comment has been minimized.

Member

danielbachhuber commented May 31, 2018

Thanks for the report, @anevins12. Flagging Needs Design Feedback to determine which color grey we want to use.

@jasmussen

This comment has been minimized.

Contributor

jasmussen commented Jun 13, 2018

#8D96A0 is the lightest gray (as based off these grays) that passes 3:1 contrast ratio. It looks like this:

screen shot 2018-06-13 at 15 06 43

This feels very heavy handed to me. It also feels way overboard compared to what's in WordPress now:

screen shot 2018-06-13 at 15 13 00

What are our options for ensuring accessibility here, without making everything scream at the sky? Does WordPress upstream do something with textfields that makes it pass the guidelines, but Gutenberg doesn't? Thanks for your advice.

@anevins12

This comment has been minimized.

Contributor

anevins12 commented Jun 13, 2018

@jasmussen Can you provide more detail as how to replicate the input field that passes this accessibility guideline in WordPress and why it passes?

@jasmussen

This comment has been minimized.

Contributor

jasmussen commented Jun 13, 2018

Can you provide more detail as how to replicate the input field that passes this accessibility guideline in WordPress and why it passes?

What I'm suggesting is that text fields in WordPress right now do not seem to pass the 3:1 contrast ratio guideline, if I'm reading the contrast ratio right. Is that correct?

@anevins12

This comment has been minimized.

Contributor

anevins12 commented Jun 13, 2018

Oh, I'd like to know that too. I can't quite pick the colour from the screenshot so I would like to see this input in the wild and inspect it using a browser developer tool. It could be that the border of the input has a poorer contrast against the grey background.

@jasmussen

This comment has been minimized.

Contributor

jasmussen commented Jun 13, 2018

I can't quite pick the colour from the screenshot so I would like to see this input in the wild and inspect it using a browser developer tool.

Just go to Settings in WordPress. That's my Site Description input field:

screen shot 2018-06-13 at 15 40 56

@anevins12

This comment has been minimized.

Contributor

anevins12 commented Jun 13, 2018

Maybe there's more than 1 check for this:

  1. Check if the outer background and border have a 3:1 contrast ratio
  2. Check if the field background and border have a 3:1 contrast ratio
  3. Check if the field background and outer background have a 3:1 contrast ratio
@anevins12

This comment has been minimized.

Contributor

anevins12 commented Jun 13, 2018

To answer those questions for the input fields that appear in the WordPress settings:

  1. Check if the outer background and border have a 3:1 contrast ratio
    = 1.20:1 ratio
  2. Check if the field background and border have a 3:1 contrast ratio
    = 1.36:1 ratio
  3. Check if the field background and outer background have a 3:1 contrast ratio
    = 1.13:1 ratio

This doesn't surprise me because WCAG 2.1 was only recently released and we may not have known to implement this contrast ratio.

@jasmussen

This comment has been minimized.

Contributor

jasmussen commented Jun 13, 2018

I'm concerned about striking a balance here, where we don't end up with a bunch of very dark bordered boxes all over the place.

What are your thoughts on Material Design input boxes, which emphasize the bottom border as opposed to all sides of the input field?

@anevins12

This comment has been minimized.

Contributor

anevins12 commented Jun 13, 2018

I've had a look at that article and it appears to have the same problem that WordPress has. I'm sorry that I've not been involved in the design decisions of WordPress or Gutenberg and didn't know you were following Material Design input boxes.

I have no criticism of the design principles and I also don't want to see an ugly solution. I think it's a difficult problem but with the help of the design team, we can implement the best of both design and a11y.

@jasmussen

This comment has been minimized.

Contributor

jasmussen commented Jun 13, 2018

We're not following Material Design. I pasted that link as one potential solution for improving the contrast of input fields, while maintaining potentially maintaining the design. Not necessarily sure that it's what we should do, but in looking at various design options on the table, increasing the contrast of the bottom border could be one way of doing it, no? https://www.w3.org/2017/03/23-ag-minutes.html links to http://www.glendathegood.com/a11y/lvtf/textinputborder.html which suggests a bottom black border as one option.

I'd love for us to raise the bar for accessibility in WordPress input fields to the new guidelines here, just brainstorming approaches.

@anevins12

This comment has been minimized.

Contributor

anevins12 commented Jun 13, 2018

I think that's a good idea and good find, though it appears to have been an aid to illustrate that discussion when 2.1 and its ideas were not yet fully fledged - So I wouldn't rely on it for truth. But to iterate, yes it is a cool idea to have the border on the bottom.

WCAG doesn't say that you must have a border all around the input field and if you don't have borders then the 'Non-text contrast' criterion doesn't apply:

If only the text (or icon) is visible and there is no visual indication of the hit area, then there is no contrast requirement beyond the text contrast (1.4.3 Contrast (Minimum)) or icon contrast covered by the Graphical Objects portion of this Success Criteria.

So we don't have to have the full border around the input field. When we do have just the bottom border, it does however need to meet that 3:1 ratio.

It is also important to note that adding a border is considered best practice:

Note that for people with cognitive disabilities it is recommended to delineate the boundary of controls to aid in the recognition of controls and therefore the completion of activities.

@anevins12

This comment has been minimized.

Contributor

anevins12 commented Jun 13, 2018

Going back to Material Design, it looks like they have indeed achieved the best of both worlds. They have a bottom border to indicate the field, and they have a different shade on the input field background to indicate the boundaries.

The Material Design approach IMO is a good idea.

@jasmussen

This comment has been minimized.

Contributor

jasmussen commented Jun 13, 2018

Cool, I'll mock up some ideas around that concept and see if we can find something cool 👍👍

@anevins12

This comment has been minimized.

Contributor

anevins12 commented Jun 13, 2018

A little bird told me the Understanding article of this guideline is going to be updated soon and in the meantime you can use this page for more up to date information: https://alastairc.ac/tests/wcag21-examples/non-text-contrast.html

@jasmussen

This comment has been minimized.

Contributor

jasmussen commented Jun 13, 2018

Interesting, thanks for sharing that link. I'm curious why the default view passes the bar:

screen shot 2018-06-13 at 18 10 55

Do you have background on that?

@anevins12

This comment has been minimized.

Contributor

anevins12 commented Jun 13, 2018

It looks like the grey border (#818181) has a 3.9:1 contrast ratio: https://alastairc.ac/tests/wcag21-examples/ntc-examples/02-default.png

@jasmussen

This comment has been minimized.

Contributor

jasmussen commented Jun 14, 2018

Here's a codepen:

https://codepen.io/joen/pen/yEoYMj?editors=1100

Option 1 is unstyled, and I'm seeing only a 1.84:1 contrast on that in Mac browsers, which will obviously vary from browser to browser. Still, if I'm reading the guidelines right, there's an exception for that, which is confusing to me.

What do you think of option 3?

@anevins12

This comment has been minimized.

Contributor

anevins12 commented Jun 14, 2018

Yes that's an exception when the user agent styles the input field. That bit of the Understanding isn't going to be updated:

Visual information required to identify user interface components and states, except for inactive components or where the appearance of the component is determined by the user agent and not modified by the author;

@anevins12

This comment has been minimized.

Contributor

anevins12 commented Jun 14, 2018

I suspect this is because user agents are not the responsibility of the application authors (wp.org) and those issues can be addressed at the user agent level.

@afercia

This comment has been minimized.

Contributor

afercia commented Jun 21, 2018

compared to what's in WordPress now

Yep it's true the border color used for inputs in WordPress doesn't pass the requirement. However, the comparison with Gutenberg is not entirely correct because in most of the cases (not always to be honest) the page background in WordPress is gray. Though not conforming, that helps users in identifying input fields:

screen shot 2018-06-21 at 12 14 53

There are cases where the background is white (like in Gutenberg) and the problem is more evident. It's definitely an area we should try to improve in core too.

P.S.
it seems there's no #8D96A0 gray any longer? The first one that passes a 3:1 contrast against a white background is $dark-gray-200 #7e8993. Or, maybe, slightly darkening the $dark-gray-100 #8f98a1 which currently has a contrast ratio of 2.93:1 could help.

@karmatosed

This comment has been minimized.

Member

karmatosed commented Jul 15, 2018

I would like to see us explore https://codepen.io/joen/pen/yEoYMj?editors=1100 option 3. Is that acceptable?

@afercia

This comment has been minimized.

Contributor

afercia commented Jul 15, 2018

I think we can explore that, as an attempt to balance a11y and design needs. I'd like to hear other thoughts too, will discuss during next accessibility meeting on Slack.

For reference: see below the proposed option 3, with a darker gray used only on the bottom border, while the other borders use a lighter gray:

screen shot 2018-07-15 at 16 27 56

@afercia

This comment has been minimized.

Contributor

afercia commented Jul 16, 2018

Discussed during today's accessibility meeting, no objections to explore option 3 :)

@karmatosed

This comment has been minimized.

Member

karmatosed commented Jul 17, 2018

@afercia awesome, let's get that worked on then. Thanks.

@afercia

This comment has been minimized.

Contributor

afercia commented Jul 18, 2018

Looking at the implementation, there's just one CSS rule that targets all the form dields including radio buttons, checkboxes, selects, and textareas. I guess we should exclude radio buttons, checkboxes, and selects but code-wise it won't be great. I'm going to push an experimental PR so everyone can test.

Worth noting there's a core Trac ticket for radio buttons and checkboxes, see https://core.trac.wordpress.org/ticket/35596 that should be addressed in the whole admin, including Gutenberg. Will open a new Trac ticket for all the other form fields.

@afercia

This comment has been minimized.

Contributor

afercia commented Jul 18, 2018

P.S. the change will apply also to input fields within the blocks, for example the ones in the embeds blocks or the shortcode block, see screenshot below:

screen shot 2018-07-18 at 23 27 01

@afercia

This comment has been minimized.

Contributor

afercia commented Jul 18, 2018

What should be done about checkboxes and selects? (as far as I know, Gutenberg doesn't use radio buttons)

@karmatosed

This comment has been minimized.

Member

karmatosed commented Jul 24, 2018

Looking at this applies within placeholders I am not sure this is the right move. Against a button they look really disjointed and the wrong height. There's a weird in-balance going on.

@afercia

This comment has been minimized.

Contributor

afercia commented Jul 24, 2018

No objections to a better solution. Still, input borders need a contrast ratio of 3:1 with the adjacent background. What is your proposal @karmatosed ?

jasmussen added a commit that referenced this issue Aug 2, 2018

jasmussen added a commit that referenced this issue Aug 3, 2018

jasmussen added a commit that referenced this issue Aug 6, 2018

jasmussen added a commit that referenced this issue Aug 6, 2018

Polish focus and active styles, and do cleanups (#8385)
* Fix regression with button active style.

* Move from 1px to using $border-width

This is sort of some cleanup work across the files.

* Try new input focus style.

Fixes #7053.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment