1.4.11 if a button has a background less than 3:1 and no border does it pass

[DavidMacDonald]

On the June 25 call "Example 3" shown below was presented as a pass of 1.4.11. It confused me and I want to check my assumptions with others on our current interpretation of 1.4.11. Do these pass of fail?

1) a button has a background but it is less than 3:1 contrast (no border). The button text is 4.5:1 on the button background as per 1.4.3. (as shown above)

2) a button has a visible border and background but both are less than 3:1 contrast against the page color. The button text is 4.5:1 on the button background as per 1.4.3 The text of the SC is this:

Visual information required to identify user interface components and states ... [has 3:1 contrast]

My interpretation is that the words "Example 3" are not enough to know that this is an interactive control. If an author is creating a background or border for a button to indicate it is a button, doesn't that background need to meet 3:1?

If there is no background and no border, then low vision people have no disadvantage so I would say it is exempt, but if there is a visible border or background in a button shape that indicates it is a button, then the SC kicks in and there needs to be sufficient contrast in the button or border. If not, I wouldn't know how a button that has text could ever fail this SC.

What do others think?

Whatever our consensus on what is necessary to know a button is an interactive control, I'd like to make it explicit in the understanding for 1.4.11.

[awkawk]

From: https://www.w3.org/WAI/WCAG21/Understanding/non-text-contrast

Boundaries This success criteria does not require that controls have a visual boundary indicating the hit area, but if the visual indicator of the control is the only way to identify the control, then that indicator must have sufficient contrast. If text (or an icon) within a button or placeholder text inside a text input is visible and there is no visual indication of the hit area then the Success Criterion is passed. 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.

[abijames]

I raised a similar example with the email group in February following conversations with designers about adopting 2.1. A summary of this follows but agree that there need further clarification on this in the understanding document as coloured buttons without border is a common scenario.

We had identified 2 questions that needed clarification

• if there is a visual indicator of the control other than through the colour of the hit area (e.g. through styling of the text as in this example), does it pass?

@alastc responded: It depends on the control, but a hit-area isn’t required, so if it is a link/button then there is no contrast requirement beyond the ‘content’ (text or icon). Other types of control rely more on visual information though, so inputs and checkboxes (for example) would need some visual indicators with contrast.

• if it easier to pass this success criteria when no indication of the hit area is provided (particularly with icon buttons), would that actually be more detrimental to accessibility/usability?

@alastc responded: That was part of the reason why we decided not to have a requirement for hit area, it would setup a negative incentive. So whilst it is desirable to have a hit-area (i.e. an affordance) for buttons, that is more from a usability point than accessibility (i.e. sucks for everyone).

The example I provided is at https://codepen.io/abijames/full/QYqPOR and screenshot below

[awkawk]

@DavidMacDonald and @abijames - let us know what specific changes you suggest are needed in the understanding document.

[DavidMacDonald]

@awkawk

The understanding says:

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 the type extra closing bracket - editorial fix)

Can you give an example of a stand alone button with text that fails this? I can't think of one given this interpretation. And if so then I think we need to simply say. "If a button has text inside it, it automatically passes" Otherwise we get into the squishy idea of having to decide whether the text and its position and space around it, is in itself enough.

[awkawk]

No, but a standalone button with text wasn't the target of the SC to begin with.

[DavidMacDonald]

No, but a standalone button with text wasn't the target of the SC to begin with.

I would think "interactive controls" includes buttons with text in them, since without the border or background its not always clear it is a button. However, it appears this opinion is not the consensus interpretation. So, I think we need to simply say something explicit, such as:

This SC doesn't apply to a stand alone button with text since the text and the space around it is sufficient to identify it as a button.

I'm guessing there will be others who are confused otherwise. I can do a pull request for this if I'm understanding @awkawk and @alastc properly.

[abijames]

I think a full exemption of buttons with text could be risky as it would exempt buttons with no background colour but a light border and buttons where text has no styling difference to surrounding text. The current Understanding document also includes examples of a button with text (in the boundaries section).

While it may not have been the original intention of the SC may not have been to include text buttons, the recent work shared by Google highlighted the need for further clarity of the interaction between contrast and identifiable controls. It would help if we can clarify what is meant by:

Visual information required to identify user interface components and states

If the "Visual information" used to indicate a control is only colour, would the text in the button then be required to pass 1.4.1 by applying the various techniques that are usually applied to link text. In that scenario, text on a borderless button with low colour contrast would require the text to have sufficient contrast or other styling compared to surrounding text if the button colour did not provide sufficient contrast to identify it as a control.

Would that provide a suitable example to work from?

[DavidMacDonald]

@abijames This seems reasonable. There needs to be a visual distinction between the button text and the surrounding text, the way an inline link needs a visual distinction.

[mraccess77]

I understood the requirements for 1.4.11 to be if there were visually identifying elements like borders then they would have to meet the contrast requirements. I never heard until yesterday (and it's been a year) that for buttons there was an exception that the button text alone was sufficient and that buttons need not be subject contrast requirements for identification. If we exclude buttons -- why not exclude inputs with placeholders? Why have a requirement for contrast of links in text if buttons don't have the requirement? If buttons don't need to follow contrast requirements -- why make page tabs follow them either or lists or combo boxes? What makes button different than these other UI elements that identify them as dropdown, input boxes with placeholders, or tab controls.

I believe the intention of the low vision task force was to require that when buttons had identifying elements some of those identifying elements would need sufficient contrast -- we had agreed that it wouldn't have to be the whole identifying element -- but some aspect such as a side. In my opinion we should continue to require that.

[DavidMacDonald]

@mraccess77

I understood the requirements for 1.4.11 to be if there were visually identifying elements like borders then they would have to meet the contrast requirements.

That is exactly my understanding.

I never heard until yesterday (and it's been a year) that for buttons there was an exception that the button text alone

Same for me.

and that buttons need not be subject contrast requirements for identification

That's a proposal by @abijames which might help bridge the gap between the way I (and it sounds like you also) understood the SC and the example 3 above.

[awkawk]

I understood the requirements for 1.4.11 to be if there were visually identifying elements like borders then they would have to meet the contrast requirements.

It isn't that buttons are excluded.

If users can identify that the control is there without using the border to do so, then the border doesn't need to meet 3:1.

If users can identify that the control is there without using a background color to do so, then the background color doesn't need to meet 3:1.

If you have a button with just text that users can identify as a control, then that text needs to meet the 4.5:1 ratio and 1.4.11 is met also.

If you have a button with just text that users cannot identify as a control, then it might meet the 4.5:1 ratio and fail the 1.4.11 requirement.

[DavidMacDonald]

@awkawk

If users can identify

That seems pretty squishy. We've never depended on a user being able to do something in WCAG, but rather the characteristics of the content. That is one of the big changes proposed in Silver.

[mraccess77]

@awkawk wrote If you have a button with just text that users cannot identify as a control, then it might meet the 4.5:1 ratio and fail the 1.4.11 requirement.

How would we test that? Can you provide an example? It seems like Alastair is saying any control with text indicates a hit area and there are no 1.4.11 requirements when the control provides text for the hit area. Seems like 1.4.11 for UI control would really only apply to radio buttons and checkbox type controls or when input fields didn't have placeholder. Pretty much every other control would just pass the identifiable requirements.

[awkawk]

How would we test that?

Same way that we test whether the correct role is used for a component. Someone needs to review it and make a call.

[mraccess77]

@awk so are you suggesting we analyze the words used and determine if the words are clear enough? That seems very subjective.

[awkawk]

@mraccess77 It might be the text, it might be the positioning, it might be some other factor. Yes, there is a measure of subjectivity to it.

If you have a button with text, a background color, and a border, can you say definitively that the background or the border must always meet 3:1?

[mraccess77]

@awkawk wrote If you have a button with text, a background color, and a border, can you say definitively that the background or the border must always meet 3:1?

I thought that was the purpose of the UI portion of this SC -- that was the intention from the LVTF. It's certainly testable whether it needed all of the time or not.

[alastc]

To add the context from the email list, this is the email thread prior to 2.1's publication that determined that links/buttons do not generally require a visible border/background.

Looking at the examples, there are links in there (like the Funka menu) where individual links do not have any visual indicator separately from the text.

I thought it was pretty clear from that thread/discussion that:

• If we required contrasting borders/backgrounds around links/buttons that would have a negative impact overall, and it certainly got push-back even from accessibility-specialist organisations.
• If we required that borders/backgrounds (if present) must have contrast it would setup a situation where designers would take off those subtle backgrounds if that was the choice.

The PR that removed "if there is an indicator then it has sufficient contrast" based on that discussion was created June 1st 2018.

I might have used a short-hand such as “links / buttons don’t require a border”, I don’t (quite) mean excluded per-se. I could create an example where a button is de-styled and hidden in text which I think would fail.

In general it is really hard to say that a link in a plain looking menu (only differentiated by position like the current LevelAccess or Nomensa main menus) doesn’t require a visual indicator, and that a link/button in another place does require something. As we can’t do that (which we agreed prior to 2.1 publication) we updated the understanding doc to that effect ( snippet above ) and included the first example which has no border/outline.

Apologies, I pasted the wrong link in the email to the list, this is where the larger updates to the NTC understanding were merged in (Jan 2019): PR 550

Which included:

Not in scope:

• Boundaries for links / buttons.
• Default (untouched) focus indicators.

That update made the earlier decision clearer in the understanding text.

David wrote:

There needs to be a visual distinction between the button text and the surrounding text, the way an inline link needs a visual distinction.

Most inline links have an underline (hopefully!). If a button has a particular position, font-weight, or any (subjective) factor to differentiate it from non-interactive content then I’d be inclined to pass it.

If a button relies on a color difference, I'd fail that under use-of-color. In general this SC is more effective for form controls and custom inputs. If we want an SC for affordances (which I think we do) it would need a different structure/test, which might be better suited to Silver.

[DavidMacDonald]

If a button relies on a color difference, I'd fail that under use-of-color.

It sounds like if there is at least a 3:1 contrast with the static content around it, it would pass under the current line of thinking. As per G183

[jake-abma]

Not requiring border / background / indicator makes it more subjective

Requiring creates push-back and studies make clear not always needed (but they often lack testing with user of different abilities, what if you zoom in so much you don't get proper context?)

Seems like a deadlock to me and whatever choice we don't serve all.

Referring to the call yesterday with important UICs and "above the fold", ending up with attributes / programmatically determinable. If that is an option for such a SC (at AA), why not in this case as we already require a proper role?

[alastc]

David - yep, that's what I meant.

Jake - this SC is aimed at being the requirement without personalisation/AT, so relying on metadata for some sort of personalisation isn't really the goal.

There could be some future SC involving that, but it would need to be at least somewhat mature, and I haven't seen the tech out there yet. (Same applies to the other SC really.)

[alastc]

Hi @DavidMacDonald, I think the answer to the question in the title is generally "yes", with caveats from this discussion, is it ok to close this issue?

[abijames]

@alastc before this discussion is closed, could we consider if we could add is an example to the understanding document of a button with a coloured background a text explaining why it would pass? Otherwise I fear this question will keep coming up every few months.

[alastc]

I've done a PR (#813), which can be previewed here.

It is the 3rd example in the table, does that help?

[alliv8]

Would be awesome if this caveat could be referenced somewhere more prominently. We're transitioning our design system at BrowserStack to be accessible and our entire design team debated whether neutral buttons, like the ones found on Github, Google Calendar / Gmail, Atlassian, Gitlab need to have an accessible border or background color, as the buttons in the above products don't.

Attaching a few screenshots for context:

Would it be possible to reference screenshots from a popular design system like material ui for example in the 1.4.11 page as well? Could definitely help designers and developers in the future looking for more clarity on this topic. https://material-ui.com/components/buttons/

[patrickhlauke]

Would be awesome if this caveat could be referenced somewhere more prominently.

in the understanding doc https://www.w3.org/WAI/WCAG21/Understanding/non-text-contrast.html it gives examples such as

Boundaries This success criterion does not require that controls have a visual boundary indicating the hit area, but if the visual indicator of the control is the only way to identify the control, then that indicator must have sufficient contrast. If text (or an icon) within a button or placeholder text inside a text input is visible and there is no visual indication of the hit area then the Success Criterion is passed. 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. Figure 1 A button (active control) without a visual boundary, and the same button with a focus indicator that is a defined visual boundary of grey (#949494) adjacent to white.

In general: if something is still understandable as a control or button (because of its position in the page, familiarity, context, etc) then it doesn't need to have a strongly contrasted/visible border or background. So ... "it depends(tm)" ... but if you imagine them without any border/background, would it still be visually clear to an average user that those are controls, rather than just static text/icons? If you feel that yes, it's still clear, then you can pass this SC even if the contrast of the border/background is low (though if you should do it from a usability/going above and beyond WCAG perspective is another question)

[Vikingwind]

I think all of those famous design systems like Material design, carbon and Base etc will give answer about this discussion. Border or background of a button with label/text do not need to have 3:1 contrast request. But border or background of standalone element as a checkbox, radio, input, textfield need to meet that request. But label needs to meet 4.5:1 request in a button. By the way all states must meet request as enabled/ default, and disabled button don't have request, but text inside it must still meet 4.5:1 for text readable request.