Input fields: option for always showing focus outlines (WCAG 2.2)

[knoobie]

What is the problem?

If you focus a text field or any other field component with the mouse, only the label gets highlighted. If you focus a field with the keyboard the proper "outline" is applied. This behavior has to be present or configure-able for mouse-focusing as well.

WCAG Criteria: 2.4.7 Focus Visible (Level AA)

The current state violates it explicitly, because the highlighting of the default inputs is "turned of".

See Failure of Success Criterion 2.4.7 due to styling element outlines and borders in a way that removes or renders non-visible the visual focus indicator

This describes a failure condition that occurs when the user agent's default visual indication of keyboard focus is turned off or rendered non-visible by other styling on the page without providing an author-supplied visual focus indicator. Turning off the focus indicator instructs the user agent not to present the focus indicator. Other styling may make it difficult to see the focus indicator even though it is present, such as outlines that look the same as the focus outline, or thick borders that are the same color as the focus indicator so it cannot be seen against them.

Some could argue that the "blue" label is a visual focus indicator, but I don't think it's enough.

Browsers

• Chrome
• Firefox
• Safari
• Safari on iOS
• Edge

Screen Readers

• None
• NVDA
• JAWS
• VoiceOver on MacOS
• VoiceOver on iOS

[web-padawan]

This is intentional: we only apply outline when focus-ring attribute is set which means field is focused using keyboard.

@jouni WDYT about this? Should we change the behavior, or just document it and mark this as "won't fix"?

[knoobie]

I've spoken with our professional accessibility tester and showed her the current https://a11y-vaadin-playground.netlify.app/pages/v22/text-field.html version, her response:

the change in contrast from gray to blue, for example, has a far too low contrast distance and may not even be perceived by the user. With the new WCAG 2.2 there was a new criteria added where focus requirements are specified. 2.4.11 Focus Appearance (Minimum)
Additionally, the change in the background color of the faulty field to light red is also insufficiently noticeable

She would highly recommend to already follow the latest WCAG 2.2, It's only a matter of time until the EU updates the law from 2.1 to 2.2.

[jouni]

I agree it will improve accessibility for all users if the focus outline is visible also when focused with a pointer. Although, it is not required according to WCAG 2.1:

Note that a keyboard focus indicator can take different forms. One common way is a caret within the text field to indicate that the text field has the keyboard focus.

Examples

When text fields receive focus, a vertical bar is displayed in the field, indicating that the user can insert text, OR all of the text is highlighted, indicating that the user can type over the text.

WCAG 2.2 will very likely change this (which is probably what @knoobie’s friend was referring to):

A 1px wide vertical line (such as a blinking cursor) would not pass the size requirement, a text input would need a larger or separate focus indicator.

---

The main motivation for not showing the outline when focused via pointer, when I made this design decision, was iOS. I haven’t seen any text input focus indicators on it, and can’t find a setting to turn them on.

From there, my rationale was that if you clicked on a field, you know where the focus went.

I realize it makes it more difficult to figure out where the focus if you leave the page/app momentarily and come back to continue where you left off, at least if it’s a large screen with many inputs.

Because of some of these reasons, I’m still considering if we could make small touch devices an exception. But I think I’m close to getting over it, and accepting the outline no matter how a text input is focused.

Note, that Select is an exception, as it does not receive keyboard input. It should only get the outline when focused with the keyboard.

Also, as I type this on a "rich text editor" in GitHub, I suppose we should apply the focus outline to our RTE as well?

[web-padawan]

I suppose we should apply the focus outline to our RTE as well?

Good catch. I will create a separate issue for it.

[knoobie]

Thanks @jouni for your throughout response! Yes, I wasn't sure if this is a violation based on the 2.1 wcag (it doesn't feel right, that's why I opened the ticket)

Afterwards I got in touch with our expert and the first thing she mentioned was the newly created criteria from 2.2 wcag which in turn exactly described my "something is not right feeling". :)

From a design perspective I can totally understand why you didn't want to add it in the beginning when you redesigned valo to lumo!

The current design really matches iOS native behavior in apps. But I'm typing currently on my phone and GitHub looks like it has a clearly visible focus for my current input while typing - so yeah, looks like something that should be looked into for V22 or V23 for even better UX :)

[web-padawan]

We are about to release beta for Vaadin 22, it's planned for next week. But we can probably consider such UX changes in one of the next majors.

[rolfsmeds]

Ideally we would provide some kind of app-wide configuration flag for this, e.g. in the form of a Lumo css property, so that each app could be easily configured to use either the current behavior or the new one.

[jouni]

Yeah, could be something like --lumo-text-input-pointer-focus-outline: none; to get the current behavior back.

[knoobie]

Push to hopefully get this on the plate for v24 to make sure the next major is future proof 😉