Some input boundaries lack sufficient contrast

[anevins12]

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.

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]

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

[jasmussen]

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

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

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]

@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]

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]

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]

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:

[anevins12]

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]

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]

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]

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]

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]

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]

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]

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

[anevins12]

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]

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

Do you have background on that?

[anevins12]

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]

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]

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]

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]

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:

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]

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

[afercia]

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:

[afercia]

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

[karmatosed]

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

[afercia]

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]

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:

[afercia]

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

[karmatosed]

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]

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 ?