Non-text contrast - Buttons example

[dashouse]

In the example used for Buttons it states that "a contrasting visual indicator to show that it is a button" is not required.

Is there any rationale for why this is not a requirement or any indication if it will be in the future?

It seems like the recommended approach is that users would benefit from having a visible hit area but is one step away from being a "must". Is there any concern about perceivable, operable and understandable in this context?

[patrickhlauke]

The guidelines could/should not explicitly require this, as it's far too sweeping a requirement (and would instantly make the majority of the web content out there fail). If it's clear from layout, context, etc that something is a control, then that passes.

Otherwise, imagine even on github here if we required every interactive element (link, button, etc) to have a clear border or distinguishing background ... it would turn the entire page into a giant button-fest, and would likely end up having the opposite effect for users, rather than provide clarity.

[dashouse]

Thanks @patrickhlauke I don't disagree in that scenario. I do wonder if there is any debate on significant actions - primary action on a form being different (and potentially cannot always rely on context) compared to a group of well placed / organised actions within a more complex interface.

Thanks for the clarification!

[patrickhlauke]

problem is always how to unambiguously/normatively define these things - e.g. even "what's the primary action on this page" can vary depending on what a user is actually trying to achieve, from moment to moment. there's already quite a lot of subjectivity involved here as it is, that might just make it even more subjective. that's always the weird balancing act with SCs - trying to be as unambiguous as possible (though of course, most of them still have subjectivity somewhere)

[mraccess77]

We tried to get a Visible Controls success criteria in WCAG 2.2 but it did not make it into the guidelines. This topic is of relevance for WCAG 3.

[patrickhlauke]

though visible controls had a slightly different objective here ... not to mandate a certain look, but to just give a baseline "it's actually visible right away, not just on focus/hover"

[dashouse]

For completeness sake this question was to help me try and define an internal standard for my organisation.

The draft has a 3 tier approach to Non text contrast of buttons.

Stand-alone primary / secondary actions require 3:1 boundary.This is essentially when the button is not integrated into another component and has high importance like "continue" on a form.

Tertiary - lower level actions in web and app can have the same affordance as a link and do not require a visible boundary

Integrated - Where a button element is integrated into another component or pattern, that button can lean on position / content / context of the entire component.

Of course there is a subtext that efforts should be made to exceed this, as long as doing so does not make the component harder to understand or use.

Appreciate that this kind of guidance is near impossible to create on a WCAG level but just posting if it can serve as any type of research in the future.

[mbgower]

Buttons can provide an interesting study in some nuances of this discussion, especially if we look at some examples.

IBM's Carbon design system provides 5 variations on classic buttons: primary, secondary, tertiary, danger, and ghost. (I'm ignoring all the other kinds of Carbon components that are also really just different kinds of buttons with tighter use case, such as operable tags, overflow menus, etc.)

All except the ghost button either have a solid background or a strongly contrasting border. The ghost button is similar in appearance to some used in iOS, effectively appearing like a blue text link (with no underline). The text contrasts 3:1 against typical body text.

It's important to mention that the colours of primary, secondary, and danger buttons (which all are solid) do not each contrast 3:1 with each other. But this is not a problem because 1) the importance of the button is conveyed in many ways besides colour, such as positioning and labelling -- the colour reinforces the nature of the button; 2) the interaction does not rely on users being able to recognize or express these 5 variants -- at best some users would be able to discuss what's different about a primary button on a page; 3) From a UX perspective, it is entirely possible to offer a far smaller palette of buttons and still have a functional page; 4) froma programmatic perspective, neither the implicit nor explicit role of "button" include a bunch of attributes that dictate a need for users to distinguish a vareity of button variants -- a single variant could represent all button states.

You'll notice that outside of the fact they each have a text label within the control, there is nothing that unites these buttons visually. Yet they can all provide the same basic function on a page. If you look through the Carbon style documentation, you'll see that a ghost button becomes more classically 'button-like- on focus or hover. So, once being interacted with, it becomes a bit more clearly not a link (for any users that even think about it). Ultimately, all these variations do not negatively impact time on task and usability for users. In fact, in many situations they improve those kinds of metrics for some users.

If the AGWG attempted to become more prescriptive in dictating the visual appearance of a button, we would risk failing well thought out component libraries, with little to demonstrate as benefit for any user group.

[mbgower]

Since you've accepted the answer, I'm going to assume this discussion can be closed.

Anyone should feel free to re-open if they have more to add.

[dashouse]

Thank you all for your help and guidance as always. I love Non-text contrast but I find out something I didn't entirely realise every few months. This chat has helped define a position.

The only feedback as a consumer of WCAG that interprets guidance to make reusable components (which is quite common with Design Systems) is that it's quite difficult to apply when the context is potentially unknown. Needing to err on the side of ignoring context or layout as a factor when designing elements.

It's also quite hard to create an understandable, repeatable rule when different elements have different rules e.g. buttons and inputs. I totally understand the rationale it's just hard to explain to others that are maybe new to the concept because of both the contextual nuance and the difference in examples.

[mbgower]

Yes, the way I've been tackling Non-text contrast with design teams is to use it as a call to try to increase the contrast where it aids users in understanding the interaction, yet also understand that where increased contrast results in a poorer user interaction (we've seen this to some degree where users have confused an emphasized outline on a tile with the tile having focus, for example), it's okay; there is some flexibility built into the guidance.

One heuristic that is very helpful: remove any lower-contrast visual effects entirely and see if the interaction is still understandable by users. If so, there's a strong case that meeting 3:1 is not "required to identify". On the other hand, if removing low-contrast effects from a control causes user confusion, that serves as a good indicator that the contrast should be bumped up to 3:1 so more users can discern it.