Clarity on 1.4.11 as it applies to "Cards"

[chucktheonewhobutles]

A lot of sites use "cards" as interactive elements, but I'm not sure how these fit 1.4.11. For example, these cards function as single clickable elements:

Do these cards fail because the contrast between the card and background is too low? Do they pass because the text has high enough contrast and there is spatial contrast between those blocks? Do they pass or fail dependent on how focus is applied (e.g. the top left card shows focus on mouse-over)? Are these technically considered buttons?

Since this is a common element it would be nice to at least have an example that expresses how they pass or fail in 1.4.11.

[JAWS-test]

My personal opinion: Since the cards are purely decorative, they don't have to meet any contrast requirements. The contrasts of the text below the graphic (white on grey) must be sufficient according to 1.4.3. If this text did not exist, content bearing elements of the cards would have to meet the requirements of 1.4.11.

[patrickhlauke]

i'd say it's not necessary (even without any text) for a user to know these are individual cards in order to understand/use the content, so no failure of 1.4.11

[srinivasuchakravarthula]

If cards doesn't have to meet contrast requirements, how would users with low vision could differentiate between cards. I think there would be some purpose of using cards pattern and suggest they meet contrast needs of 1.4.11. It's not only about content but also user experience. Thanks, Srinivasu

[srinivasuchakravarthula]

In tis example, text is seperated from background image and works well. But if text is embedded on background image and unreadable, then it should be fail.

[JAWS-test]

Since the cards are interactive elements, the contrasts must be sufficient, either from the text as defined in 1.4.3 or from the graphics, if no text is available, as defined in 1.4.11.

[srinivasuchakravarthula]

I agree. Srinivasu Chakravarthula, CPWA

[chucktheonewhobutles]

@srinivasuchakravarthula

Is there anywhere in the WCAG that designates that elements need to pass EITHER through 1.4.3 OR 1.4.11?

I personally understand if that's the case—in this example the text performs the task of the entire card for low vision users—but I think it would be helpful for others to either have that clarified in the guidelines OR have examples that show how that works. There are a lot of websites using cards in various forms and I think as it stands now it's somewhat unclear where they fit in the guidelines.

[awkawk]

Pages need to meet 1.4.3 and 1.4.11. Most cards as I see them implemented have enough information to help people know that there is a cluster of related controls without the background needing to meet the contrast requirement.

[alastc]

I agree with Patrick & Andrew, the cards generally have text or images of text that would pass/fail under 1.4.3.

You don't have to know these things are 'cards', if you can read the text and select that.

The example at the top has good text, does anyone have an example that doesn't have text or images of text that would then (only) come under 1.4.11?

[mraccess77]

The card border could indicate a grouping which is alone communicates with low contrast. Low vision user might miss that information.

[chucktheonewhobutles]

@mraccess77 My concerns exactly. In the example the price is so far over that a low vision user might confuse which information belongs together so I feel like it fails there, but what if the price was clustered with the other information? Is the text being clustered enough to communicate the same thing a container would?

Similarly, would placing a stroke across just the bottom of the card be enough to group the information?

I'm not sure I understand how WCAG accounts for containers which arguably function as information in the way our brain parses them.

[alastc]

The card border could indicate a grouping which is alone communicates with low contrast. Low vision user might miss that information.

I can barely see the card borders with my glasses on, except for the top-left one, is that focused or hovered? The layout is a much stronger indicator of grouping, i.e. how things line up with the images.

If the image above is your view, then I think the grouping is a sufficient factor. That might very with screen size or interaction though, is there a link to this example @chucktheonewhobutles ?

[chucktheonewhobutles]

@alastc Of course! I pulled this example from Epic Games Store

This continues to be a great example, because the imagery has so much variation that there may be whole images with extremely low contrast with the background. In that case is the idea that content groupings should clear enough to function in the same way that the card containers do to group data and functionality?

[mraccess77]

In the example shown I am able to tell the associations -- but I've seen other examples where without the border it wasn't clear if the text applied to the image above or below it. That is the border of the card separated regions of content that otherwise were ambiguous. I've also seen borders of content that is overlayed over top of other page contents like chat widgets. Without the border it can be unclear of the relationship of the content to a separate chat window versus content of the page in general. So perhaps other factors may need to be taken into account such as these.

[chucktheonewhobutles]

@mraccess77 That's exactly what I'm curious about. The contrast is NOT high enough for the cards to communicate what is contained within them, but if the container fails can the content pass through spatial association? If so, is that outlined or contained within any other guidelines for clarity?

I'm working on a similar project and struggling with adding a border, but it seems that may not be necessary since we have high contrast type that is clearly clustered and the entire element is clickable. But then again, that's what I currently think based on the spirit of the guidelines and not so much any one particular rule.

[patrickhlauke]

of course, the problem here is to normatively define this kind of scenario, which is mostly a judgement call

[jake-abma]

Going back to the original question if card pass 1.4.11 in the example given I see the pictures as decoration and not:

Graphical Objects
Parts of graphics required to understand the content, except when a particular presentation of graphics is essential to the information being conveyed.

The text is a perfect alternative to serve for the "User Interface Components" part and the graphics are not essential.

The question if grouping should be a must for web content (with enough contrast for grouping "borders/backgrounds" and the like...) is one for another SC if we ever agree on such a judgemental wish.

So as far as I've got to know and see 1.4.11 at this moment, this one is a pass.

[alastc]

If you consider the image with the 'card' backgrounds removed:

As Jon said, the association is clear without the background color.

Unless we can come up with an SC aimed at providing visual affordances for particular elements, I don't see non-text contrast as the place to force images/buttons to have backgrounds/borders. There are too many examples which don't have contrasting borders/backgrounds and don't cause an issue.

We need to nail down those factors that can be used instead of (or as well as) borders, so we'd have language such as: "User-interface controls must be distinguished by one of these:".

[alastc]

Proposed response to run past the working group:

---

For links such as "cards" which have clear text and/or image content, non-text contrast does not require them to have a contrasting border or background, as the understanding doc states under 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.

We will look at adding an example to the understanding document to improve that paragraph.

For links & buttons there are usually other factors indicating what they are, including layout/spacing, mouse-overs (for some devices), or even that links are the only thing visible (in the screenshot above).

We had a similar discussion in #800, with a similar conclusion.

[patrickhlauke]

hah, as i was just on the epic store myself i took a screenshot and mocked up the with/without card background image ... and see that @alastc beat me to it

in this specific case, i'd say even without any card background, it's clear enough that the image+title+price are grouped, as this is also used consistently throughout the page.

We need to nail down those factors that can be used instead of (or as well as) borders, so we'd have language such as: "User-interface controls must be distinguished by one of these:".

as ever, the problem is much harder because of WCAG's binary pass/fail unambiguous normative requirement...these sorts of fuzzy "judgement call" type decisions are much easier to formulate in more general "best practice" terms (similar maybe to some of the AA and AAA requirements, though the fuzzier, the harder they are to get a clear steer on)

[chucktheonewhobutles]

I completely agree with the above conversations, but I would like to make a quick note. The examples used to show how the image acts as a container are all bright and therefore pass the contrast requirement. However, the example I specifically chose has dark images which mean that only parts of the container pass.

I'm specifically interested in this because I am working on a site with card images that vary from bright to dark (provided by outside teams, so they aren't controlled). It seems like it is appropriate to use content groupings such as text blocks, but is there any clarity on how close things need to be clustered to have a clear group? For instance, the prices on the above examples are so far over, but can we rely on user intuition in those groupings? For instance, would a low vision user assume that each price is grouped with the information to it's left since we have a pattern as follows:
INFO__________PRICE_INFO__________PRICE

I can definitely make a common sense judgment on this, but it would be good to know the specifics on how guidelines like these interact to avoid errors based on differing assumptions.

Like @alastc mentioned

We need to nail down those factors that can be used instead of (or as well as) borders, so we'd have language such as: "User-interface controls must be distinguished by one of these:".

I think that would be the most helpful step forward here.

[patrickhlauke]

I completely agree with the above conversations, but I would like to make a quick note. The examples used to show how the image acts as a container are all bright and therefore pass the contrast requirement. However, the example I specifically chose has dark images which mean that only parts of the container pass.

but does it make any difference to the user's understanding and ability to do things on the epic storefront? the image is decorative, for the most part. even if the user can't perceive the image, or understand that the image is related to the text under it, and that they are both contained in a card...the user can still find the game they want to get more info on or buy (for instance, just by the text, and ignoring the images completely), without needing to know that there were visual "cards" there at all?

is there any clarity on how close things need to be clustered to have a clear group?

there's some early mumblings about a possible SC for WCAG 2.2, but I personally have serious doubts about it being possible to define in a normative way how close things need to be grouped, as it both impacts too heavily on design, and can't easily be defined in absolute hard numerical terms (e.g. there's no reasearch that can be pointed to that explicitly says something like "as soon as things are futher apart than X (be it defined in %, em, whatever), users won't understand they're related" ... this is far more a best practice/usability type discussion than a hard binary pass/fail kind of issue)

[chucktheonewhobutles]

@patrickhlauke In short, it very much could have an effect on users.

If the decorative imagery has a high enough contrast with the background, then the image (even as decoration) provides context for how information is grouped and how interaction with that information might work. If the contrast isn't high enough for the image and the container doesn't pass the contrast, then those affordances either disappear or must be contained within other elements.

You are assuming a single user story: "I want to buy Control so I clicked on the words." That excludes other uses of the site, such as quickly browsing prices, which in these examples becomes complicated when the containers aren't clear. There are plenty of other ways that sites use cards to surface information and some kind of guidance or SC on elements similar to cards seems warranted.

It doesn't seem sustainable for the guidelines to have ONLY disparate elements with their own SC, as cards are a perfect example how different elements might converge to create an element that needs clarification. For instance, cards can be/contain text, icons, imagery, and act as a large button—so does each element NEED to fulfill each applicable SC, or do cards have their own SC? If the latter is the only option a border, or does clustered information pass? What constitutes clustering? Etc.

In other words, disparate elements may pass, but without context provided by containers/clustering, some information and affordances may be lost entirely to users needing accessibility. Therefore I'm suggesting it would be helpful for people utilizing the guidelines to be made aware of those things and how they might be able to solve for them.

I don't expect that we'll have pixel distances or relative size gaps designated (although I don't think it is as unlikely/unreasonable as you seem to), but at the very least having WCAG best practices for something like that would be very useful.

[alastc]

The group agreed with the response above, however, I'm leaving this open until we update the understanding doc.