Problem/Motivation

Followup for #3604037: Indicate that grouping elements have child element errors for UX and a11y

At the moment it is really hard to distinguish vertical tabs with errors from the active vertical tab in forced color mode.
the email settings on the account settings page with three vertical tabs with error and the active tab second from the top and the rest of the five tabs underneath as none active tabs without errors in forced color mode

The white and yellow top and bottom solid borders are close color contrast wise. The borders on the left labeling erroneous tabs and the active tab are both white, the only difference is a differing width we've recommended back then as one of the outcomes during a ux meeting. Another detail that was proposed is making the borders for none active tabs dotted adding another visual cue #3631321: Improve the visual representation of none active vertical tabs in forced color mode. It also has to be noted the fact that both, the erroneous and active vertical tab being white, is a deliberate choice taken in #3604037: Indicate that grouping elements have child element errors for UX and a11y to keep the color of errors consistent across scenarios. Because based on their HTML elements the color for the errors differed across the three different scenarios available before that. So the erroneous and active vertical tabs having the same color was the smaller problem than errors having different coloring across scenarios and the reason we've agreed on moving the decision for the proper fix over to this dedicated issue. And the main problem we are facing, there is currently no dedicated system color for labeling errors and warnings in forced color mode. The list of available system colors is (https://www.w3.org/TR/css-color-4/#css-system-colors):

AccentColor -  Background of accented user interface controls.
AccentColorText - Text of accented user interface controls.
ActiveText - Text in active links. For light backgrounds, traditionally red.
ButtonBorder - The base border color for push buttons.
ButtonFace - The face background color for push buttons.
ButtonText - Text on push buttons.
Canvas - Background of application content or documents.
CanvasText - Text in application content or documents.
Field - Background of input fields.
FieldText - Text in input fields.
GrayText - Disabled text. (Often, but not necessarily, gray.)
Highlight - Background of selected text, for example from ::selection.
HighlightText - Text of selected text.
LinkText - Text in non-active, non-visited links. For light backgrounds, traditionally blue.
Mark - Background of text that has been specially marked (such as by the HTML mark element).
MarkText - Text that has been specially marked (such as by the HTML mark element).
SelectedItem - Background of selected items, for example a selected checkbox.
SelectedItemText - Text of selected items.
VisitedText - Text in visited links. For light backgrounds, traditionally purple.

Steps to reproduce

Proposed resolution

@mgifford, @kentr, and myself agreed on posting a question/feature request over in the issue queue for w3c css working group (https://github.com/w3c/csswg-drafts/issues) asking for what the recommended choice for semantically marking up errors and warnings in forced color mode would be but more likely to propose adding a dedicated system color. (*i will update the issue summary as soon as the issue is being created, it is currently still in the draft stage)

Remaining tasks

User interface changes

Introduced terminology

API changes

Data model changes

Release notes snippet

CommentFileSizeAuthor
forced_color.jpg152.95 KBrkoller

Comments

rkoller created an issue. See original summary.

rkoller’s picture

Title: Decide how to semantically label HTML elements for errors in forced color mode » Decide how to semantically label HTML elements for errors/warnings in forced color mode
mgifford’s picture

Issue tags: +forced colors, +high contrast