Notifications - UI component contrast understanding 1.4.11

[petewoodhouse-rg]

I'm not sure how to treat notifications regarding Non-text contrast guidelines

Does the complete notification count a single component and requires 3:1 contrast against its background?

Or as long as the dismiss cross (x) has enough contrast is this the only actionable element that needs to conform?

I'd recommend the complete notification because if not there would be no way of linking the dismiss cross(x) to the notification

This is a screenshot of a blog post I'm now writing (Probably shouldn't be posting an image with text here though!):

[patrickhlauke]

My take would be that the first case is not a failure, as you can still see the notification (albeit not its boundaries, perhaps) regardless of the lack of contrast / not being able to perceive its extent.

[petewoodhouse-rg]

From WCAG

Active User Interface Components: Visual information provided that is necessary for a user to identify that a control is present and how to operate it must have a minimum 3:1 contrast ratio with the adjacent colors.

'if a graphic is needed to understand the content or functionality'

Boundaries: if the visual indicator of the control is the only way to identify the control, then that indicator must have sufficient contrast.

My interpretation

To understand functionality the dismiss cross (Control) needs to be linked to the notification to know how to operate it.

The only way to identify the control (The dismiss cross) is linked to the notification is if it had a contrasting boundary.

Example

The example above shows that without the boundary and with other components nearby the control is not identifiable, and the functionality is not understandable - especially as all notifications are not dismissable.

[Myndex]

Hi @petewoodhouse-rg

IMO the real fail is that the dismiss cross is too small and too far away from the descriptive text and not as obvious the key clickable element.

But as to border, the border of the second version is TO THIN, if you are using it to claim a passible contrast, it's a fail.

NOTE: I am not presently a "W3C member" and I don't speak for them officially, but I am working on several proposals for visual accessibility especially contrast for the WCAG (see issue #695). There are a number of misconceptions on the subject I am working to clear up, detailed in that issue.

THIN BORDERS ARE NOT USEFUL
I have vision issues, and I will tell you right now, when I look at your two examples with the eye with the most severe problem, I see no difference in contrast between the first two examples. None whatsoever.

While a border is a useful element to enhance contrast for a normally sighted viewer, a thin border has no utility for someone with many of the various visual impairments, especially acuity.

The thin border you are using does nothing to assist local adaptation, and does noting to increase apparent contrast for anyone whose visual acuity causes a circle of confusion greater than ½ the width of the border (this means the border becomes blurred so much that it simply blends into the surround).

CONTRAST MINIMUMS
The contrast for both examples is a WCAG of 1.12. I believe there is a pending pull request that points out that thin borders can't be included in contrast calculations.

While I am on record as objecting to the WCAG contrast equations, nevertheless when one color is #FFF then the WCAG reported contrast is "close enough" for discussion and 1.12 is a fail, as it is for any guideline presented by every standard or guideline in the world if the element needs to be clearly defined.

The contrast you present in examples 1 & 2 is low, (assuming the same nominal 5% flare), Other standards and research would define the contrast of these dialog boxes (and the relevant minimums for same) as:

Weber: 11% (Minimum 40% or 50% depending on source, minimum for text is 70%)
Michaelson: 6%
Bowman-Sapolinski: 6% (Australian minimum is 30% for doorways, signage 45-60)
MPC Bartleson-Breneman (experimental): 0.34 (minimum non-text is 1.50)
L* Difference: 4%
SAC (experimental): 0.35 (minimum non-text is 1.50)

For these above contrast maths, the surround is #FFFFFF and the dialog box is #EBF3FB or #F2F2F2 as per your examples. The minimum contrasts listed above require the dialog to be no brighter than #C6C6C6 or #BBC5EA if you want a blue tint.

As for the current WCAG equation, it is inaccurate due to a severe perceptual non-uniformity which has been dealt with largely by increasing the minimum contrast requirements in the standard. That said, using the WCAG as the baseline with the brightest element at #FFF:

If the brightest color is #FFFFFF then the proscribed contrast for the box at 3:1 would require #949595 (#8093CF for blue tint), and this will then make the enclosed text harder to read.

Using the minimum #C6C6C6 or #BBC5EA as defined by other similar standards, the WCAG contrast is 1.7:1 — this makes the box very visible, and the text easier to read with better contrast. Here are examples using these values:

In terms of having a very light dialog box with a border for contrast enhancement, experiments and research are still outstanding, but here are examples using your values. I've been leaning toward a 0.5em for minimum padding in a separate specification being researched, and 0.5em in this example also looks useful, though the 5px example might indicate a minimum for this color combination. Again, there is little existing research, so local adaptation and surround effects due to padding and borders is being studied and the results are not in yet by any means.

In closing, no a 1px border is not useful for enhancing contrast. It scales poorly and ultimately is not helpful for for impairments. But it's also not the only issue relating to contrast perception and its effect on visual acuity.

Personally, I find the following more usable than a ✕ placed somewhere. Even though the color of the div bg is too light, the action button makes it clear.

But a disturbing trend I see in UI design is something like this:

☺

[petewoodhouse-rg]

Thanks @Myndex

I partly agree (I even recently questioned IBM's implementation of adding a 1px border on only one side of a button to pass the criteria for their new design system.)

However, like most users of the WCAG my aim is to interpret them correctly and pass the current criteria. There will always be new research and future improvements to contend with.

Therefore my question still stands:

On the below examples is the interpretation of the current WCAG 2.1 regarding UI contrast correct?

The example above fails - without a contrasting boundary the control is not identifiable, and the functionality is not understandable - especially as all notifications are not dismissable.

The example above passes - with the boundary line the control is identifiable as a dismiss x to the notification, therefore the functionality is understandable. The blue border #336DC2 and the Grey background #F2F2F2 have a contrast ratio of 4.56:1 (Needs to have 3:1)

[Myndex]

Hi @petewoodhouse-rg

Reading https://www.w3.org/WAI/WCAG21/Understanding/non-text-contrast.html then I'd say these assumptions are correct. As far as I can the the current spec does not include a definition for minimum border size.

Minimum border (when used for contrast purposes) is something that needs to be in a future spec, along with minimum padding for text inside a div when that div is on a larger contrasting color.

As a designer, I don't consider the one that "technically passes" to be an "appropriate standard to live by," especially in light of a number of deficiencies in the present standard. It falls under "bare minimum" for the reasons I outlined in my earlier post.

These are my opinions as a designer (and for what it's worth, I started in graphic design before desktop computers, when we used razor blades and wax to layout a page on no-repro-blue grid lines). I mention this as you are writing an article, and today I have seen far too many websites that have adopted a low-contrast approach that technically meets WCAG guidelines but are otherwise poor design practice. And I further encourage you to look at issue #695 where I demonstrate some of the issues with the current spec(s) as stated.

[patrickhlauke]

Minimum border (when used for contrast purposes) is something that needs to be in a future spec, along with minimum padding for text inside a div when that div is on a larger contrasting color.

Just raising the fact that this is going to make testing far more complex - certainly manual testing will require juggling a variety of possible factors to come to a pass/fail assessment. And in many cases, "bare minimum" is indeed what WCAG shoots for, for pragmatic reasons.

[Myndex]

Minimum border (when used for contrast purposes) is something that needs to be in a future spec, along with minimum padding for text inside a div when that div is on a larger contrasting color.

Just raising the fact that this is going to make testing far more complex - certainly manual testing will require juggling a variety of possible factors to come to a pass/fail assessment. And in many cases, "bare minimum" is indeed what WCAG shoots for, for pragmatic reasons.

Well, the CSS is just a punch of numbers associated with tags like "border-width" and "padding" that are fairly easy to parse for a basic programatic assessment.

A more complete assessment would render the page as an image and use a perceptual image assessment model like ICAM or CIECAM02, or some variant. THAT would be next level stuff...

[patrickhlauke]

Well, the CSS is just a punch of numbers associated with tags like "border-width" and "padding" that are fairly easy to parse for a basic programatic assessment.

However, not every element has those defined directly, so for each bit of text, you need to potentially travel up whole chain of ancestors in the DOM to work it out. Just putting it out there that this is considerably more involved than the current testing (often with something like a color picker app) of foreground/background color values (and a look at the text's size as exposed in the browser's computed styles for that element)

[petewoodhouse-rg]

How about the issue of dismissable notifications needing a border so you can identify it and understand its functionality. Is that the correct interpretation?

P.s thanks @patrickhlauke @Myndex super helpful and super interesting

[awkawk]

@petewoodhouse-rg I agree that the second one passes, and I also agree that the first would not pass, but I think that @patrickhlauke's comment about human judgement is correct and I don't know that I would fail the first example in all cases. What makes the first a fail for me is that there are other controls nearby that are easily confused with the "x"

Here's a few variations. Would any of these pass?

[petewoodhouse-rg]

@awkawk thanks, I'd say the top and bottom pass...the middle I'm not so sure about, therefore I'd fail that one

[alastc]

Hi @petewoodhouse-rg,

On the first one, is the entire banner a control?

I'd have thought the thick blue line, the icon, and the text are not interactive, and only the cross is?

If that is the case, then the part of the SC scoped under "user-interface-components" is just the cross, and that has good contrast. I assume it is a button, and there isn't a requirement to have a border on the button.

The line & blue icon would come under the graphical-objects part of the SC, in which case the question is whether they are required to understand the content? If you have a variety of typess of icon (info, error, warning etc) then probably yes. I think the blue/white of the "i" pass there, although CCA is crashing on me at the moment.

If the entire banner is a button (which would be odd, but ok), then I'm not sure the equation changes, without a requirement to have a border the cross is sufficient.

[petewoodhouse-rg]

Hi @alastc

My understanding:

From WCAG
Active User Interface Components: Visual information provided that is necessary for a user to identify that a control is present and how to operate it must have a minimum 3:1 contrast ratio with the adjacent colors.

'if a graphic is needed to understand the content or functionality'

To identify that the control (The dismiss cross) operates (dismisses) the notification you need to understand it's linked to the message/notification, therefore, a contrasting boundary (Or other graphic) is required to understand the functionality.

Without a boundary, there's nothing linking the dismiss cross to the notification and also not all notifications are dismissable therefore a boundary (or other graphics) is needed to identify how to operate it.

[alastc]

Hi @petewoodhouse-rg,

I think you're connecting things too much, the understanding doc covers this, where the intent is:

active user interface components (i.e., controls) and meaningful graphics are distinguishable by people with moderately low vision.

I.e. it isn't intended to cover 'affordance', it doesn't ask you to add more graphics to make something understandable.

The cross itself is the control, so it is fulfilling the active components bullet.

Note the 'boundaries' section of the understanding document talks about not requiring a boundary for buttons/links.

Would it be more usable for there to be a boundary around the notification that associates it with the close button? Probably, but if the visible parts have good contrast I can't see how that would fail 1.4.11.

(Unless the whole banner were selectable, i.e. it was one 'active user interface component'.)

There are potential SCs around affordance & location that would be more relevent to this question, but those are not part of WCAG 2.1.

[StommePoes]

How practical is it to change the Understanding text?

I asked smart a11y people (professionals) if this would fail 1.4.11:

https://user-images.githubusercontent.com/22068434/59233077-d6b6b280-8b9b-11e9-84c1-37ac58498345.png

(from this ticket: microsoft/accessibility-insights-web#762)

The resounding answer was yes. Of course a bunch mentioned all the coga stuff and whatnot but to the specific question of THIS SC failing, they still said yes.

Does it make more sense to have the Understanding doc meet how everyone in the wild/real life is interpreting the doc? Or is Understanding as set in stone after the date as the SCs themselves?

This phrase seems to contradict the Understanding bit: "for a user to identify that a control is present and how to operate it ". Where I asked my question, even though the two buttons are set visually in a separate area from the text (a new line and aligned right), this was seen as insufficient to let people know they even were user interface controls.

[alastc]

We can change it, so long as we get consensus. (You'll see a few PRs for changing understanding docs in the list.)

The trickier question is how. The second heading is 'boundaries', the example in the section clearly shows a button with zero border/background, and says a border/background is not required.

It's a big page already, I don't want to keep adding things, how can we make what's there clearer?

Does it make more sense to have the Understanding doc meet how everyone in the wild/real life is interpreting the doc? Or is Understanding as set in stone after the date as the SCs themselves?

The understanding doc isn't set in stone, but updates should be to correct how people are interpreting it rather than changing what was intended by the normative text.

There was a little confusion after publishing where the 'state' aspect could be interpreted in a couple of ways, and after a lot of discussion we resolved that it should mean each state should have sufficient contrast (with the surroundings) rather than the transition of states have contrast with the other state (which come from the test - adjacent colors). Therefore we're looking to add/update a focus-more-visible SC to cover focus state changes.

even though the two buttons are set visually in a separate area from the text (a new line and aligned right), this was seen as insufficient to let people know they even were user interface controls

That is an area reasonable people could disagree, and it is certainly heading into usability territory. For example, the research the google team did found that there were a lot of factors that contribute (spacing, text color/bold etc). We currently have a reasonable but blunt approach, I think a bit more research is needed before we change that.

You also have to consider the reverse scenario - what would the impact be of requiring buttons/links to have a contrasting border/background? A few examples were raised prior to publication that showed it would make the visibility of some links worse rather than better.

[StommePoes]

The second heading is 'boundaries', the example in the section clearly shows a button with zero border/background, and says a border/background is not required.
It's a big page already, I don't want to keep adding things, how can we make what's there clearer?

What the Understanding page says here:

If a button with text also has a colored border, since the border does not provide the only indication there is no contrast requirement beyond the text contrast (1.4.3 Contrast (Minimum)). 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.

People seem to interpret it the total opposite:

If a button with text also has a colored border, even though the border does not provide the only indication there is a contrast requirement beyond the text contrast (1.4.3 Contrast (Minimum)). Note this is because 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.

...Although low-vision was also brought up as a reason. Several also claimed the buttons such as in the example image I posted were relying on colour alone for people to know they were buttons (I wouldn't argue that as they have action text and are visually separated from the block of text, but most others disagreed).

A few examples were raised prior to publication that showed it would make the visibility of some links worse rather than better.

People seem to be exempting links (and using color-alone as reasons to call out some poorly-visible links).

I will look through those other PRs (thanks) to get a feel and move things over to another issue/PR.

[petewoodhouse-rg]

@StommePoes @alastc @awkawk @patrickhlauke

Thanks for your help on this, I've written a draft article about passing these standards with some examples - is my understanding correct in this article? Does the article make it easier to understand the criteria?

The article:
https://medium.com/@petewoodhouse/contrasting-ui-components-passing-the-new-standards-cd1f96f96494

Any feedback or suggestions are very welcome

[JAWS-test]

I have read your article and think it describes the current state well. But it also points out the shortcomings of SC 1.4.11. A comprehensive SC on contrasts would also include all the visual means of structuring a page: This includes e.g. pop-ups, messages, tooltips, page sections etc.

In this respect I would answer your initial question regarding the notification as follows:

• in terms of accessibility, the border should have sufficient contrasts, but
• unfortunately the WCAG does not require this at the moment.

[mraccess77]

Hi @petewoodhouse-rg good article -- I recommend you adding in the article that the comparison between focused and non-focused states and hover and non-hovered states is also not included in SC 1.4.11. But selected and non-selected states as long as they were adjacent would be covered (at least that is my understanding) Also exempted are controls that are not modified by the author such as the default combo box, default playback controls, default button colors and focus indicators, etc.

[petewoodhouse-rg]

Thanks @awkawk @JAWS-test @mraccess77 i've published an updated article with the help of your feedback - I think it makes things easier to understand. As always, feedback is always welcome.

https://medium.com/ingeniouslysimple/contrasting-ui-components-passing-the-new-standards-cd1f96f96494

[alastc]

Note to self: incorporate some of the examples into the understanding doc!

[alastc]

Closing after updates from PR #931