WCAG 2 compliant variant of Lumo

[rolfsmeds]

Describe your motivation

Although the contrast in Lumo was significantly improved as part of the a11y project, the background colors used by buttons and input fields are still far from the 3:1 contrast ratio specified by WCAG 2.1 level AA.

While this can be argued to be a non-issue for buttons since they are typically identifiable as such even without a background, it is significantly more problematic for input fields, especially when empty.

Describe the solution you'd like

An "a11y" Lumo variant (similar to the Dark variant or compact preset), that, amongst other things, applies sufficiently contrasting borders around input fields, and, while we're at it, why not buttons as well. This would offer users who need full WCAG conformance an easy way of achieving that without the hassle of applying these changes themselves.

Describe alternatives you've considered

Further increasing the contrast of field backgrounds to reach 3:1 would make them a fairly dark gray that, at the very least would look awful and might even cause contrast issues between field background and text color (esp. that of placeholders).

Making bordered input fields the default is certainly an option, but at least in the short term it would probably be a bit too harsh of a difference to previous versions.

Additional information

It would probably be best to introduce a style property for the borders, both for use in the a11y variant, and to make it easy for users to customize them, both with and without the a11y variant.

[jouni]

Agreed, that it’s not a good option to increase the current bg color to 3:1 contrast. And even with a bordered input, having the border be 3:1 contrast is not visually very pleasing.

This is basically a "high contrast" variant, so I think we should just call it that instead of a more abstract "a11y".

Not sure if we should mix this with the more broad "component specific custom props" topic. But I suppose just adding one more seemingly random custom prop doesn't cause much damage.

[jouni]

We could also consider relying on @media (prefers-contrast: more) for this feature. Not super great support, but I’d call it decent. Only Firefox has it behind a flag.

[rolfsmeds]

Excellent idea, although it might wreak havoc on custom themes that don't account for it, so would probably need to be opt-in.

[knoobie]

@rolfsmeds This was reported in our test today as well. I know there was an issue already about it somewhere ;)

[rolfsmeds]

Some quick testing of how dark the field border would need to be to pass the 3.5:1 requirement of WCAG 2.1 AA

That's --lumo-contrast-50pct, and actually gives us 3.5:1, but the visual difference between that and 3.0:1 are minimal.

It is quite dark, and frankly not very appealing. On the other hand we would like our defaults to be properly accessible, rather than relying on a variant or property that the developer needs to enable. Thus, a dilemma.

[rolfsmeds]

Another possibility is to not even try to satisfy WCAG 2.1 contrast requirements, but instead skip directly to the upcoming WCAG 3.0, which uses a totally different contrast model called Advanced Perceptual Contrast Algorithm (APCA): https://www.w3.org/TR/wcag-3.0/#visual-contrast-of-text.

The WCAG 3.0 working draft doesn't give much details about what the final requirements will be, and currently doesn't even include non-text contrast in its scope. However, assuming that WCAG 3.0 will contain new, APCA-based criteria for non-text contrast, here is a (non-WCAG) page presenting some research and draft recommendations that might give some indication of what those criteria might be like: https://github.com/Myndex/SAPC-APCA/discussions/39

Especially of interest is this table of recommended contrast levels (Lc) for non-text elements: which, if I'm reading it correctly, says that elements whose smallest dimension is at least 15px, is Lc 15.

To clarify, I'm not suggesting a 15px thick border, but instead looking at whether APCA might recommend a reasonably light background on the field itself, which of course is more than 15px in size.

To figure out what Lc 15 means in practice, we can use this APCA Contrast Calculator tool: https://www.myndex.com/APCA/

Using that, given a background of #fff, a foreground (i.e. field surface) color of #dbdfe5 would already be Lc 16.6, i.e. more than enough. Applying that to the field surface gives us the following

which is noticeably darker, but not too bad looking.

[rolfsmeds]

Might also want to ensure that this variant is reasonably Windows High Contrast Mode friendly. (See https://github.com/vaadin/web-components/issues/5060)

[rolfsmeds]

Showing a focus ring on pointing-device focus would be another feature of this variant: https://github.com/vaadin/web-components/issues/2904

[rolfsmeds]

List of known remaining color contrast issues in Lumo / Vaadin components (work in progress):

• Input fields: border with sufficient contrast needed around field (read-only mode outline also needs adjusting)
• Button & Menu Bar: border with sufficient contrast needed around buttons
• Accordion & Details: filled variant needs border with sufficient contrast
• Notification: border of default style variant needs more contrast
• Rich Text Editor: active toolbar buttons need more contrast

The solutions for these will probably need to be a bit different. An opt-in high-contrast variant may be necessary to address some of them without affecting existing applications too much, while others could be solved in default Lumo by introducing properties for controlling them (and the high contrast variant will then utilize these by default).

[rolfsmeds]

Acceptance Criteria for the input field borders: https://github.com/vaadin/platform/issues/3841

[rolfsmeds]

Decided not to introduce a separate variant of Lumo for this, but instead provide the following a11y improvements:

• Optional borders around input fields: https://github.com/vaadin/platform/issues/3841
• Changing the default style of selected toolbar buttons in RTE: https://github.com/vaadin/web-components/issues/102
• Introducing invisible outlines around input fields to support forced-colors / Windows High Contrast Mode

[FritjofH]

Decided not to introduce a separate variant of Lumo for this

As in not doing this at all in the future? This is a feature we have been looking forward to quite a bit.

[rolfsmeds]

As in not doing this at all in the future? This is a feature we have been looking forward to quite a bit.

Not doing it as a separate variant of Lumo specifically. Instead, a CSS property will be introduced for adding borders around input fields, probably followed by another one for buttons in the future. The benefit of this is that it can easily be applied in any Lumo-based theme.

(The issue title wasn't specific to a new variant, which understandably made my comment a bit confusing. I've now updated the title to be appropriately specific.)

[rolfsmeds]

Closing as fixed by https://github.com/vaadin/platform/issues/3841