Stacked SC: 1.4.12: Text Spacing AND 1.4.3: Contrast Do they have a interrelationship?

[jake-abma]

Changing styles for Mars demo works fine: https://dequeuniversity.com/demo/mars/

When I do change styles the contrast fails though, See the "Mars map" and "help" text

Now I have followed discussions in the past about stacking SC (specially with reflow), but not sure if this is a fail...
(I don't see a note in Text spacing or Contrast about the interrelationship)

[patrickhlauke]

Personally, I'd flag that as a mild failure here under Text Spacing - while not fully "loss of content" it does result in content that's potentially illegible

[jake-abma]

I get where you come from but do we have 'mild failures'? or will it end up in the 'recommendation' / supplemental part of an audit?

Can we say its "loss of content" or is it just collateral damage and flag it as a best practice?

If we are supposed to 'stack' SCs, it's 1.4.3 Contrast for sure... (making it clear what the issue is)

[patrickhlauke]

1.4.12 feels a bit special because it's a case where user has willfully/actively modified the author's intended styles, and it feels odd penalising an author for not foreseeing that if a user messed with their CSS, there might be situations where their content fails for various other SCs. but then, 1.4.12 is still something authors must check (at least for the baseline spacings mentioned in the requirement). so yeh, i'm a bit torn here. but from a philosophical principle, i'd agree that SCs should stack, as these are just variations of the same page (and yes this increases testing, same way that the whole "different media query breakpoints need to be tested" aspect increases testing, but them's the realities of modern web where pages do adapt to different scenarios, and should still pass other SCs even in those cases).

[JAWS-test]

If the text adjusted according to SC 1.4.12 suddenly runs into an area where text and background color are identical, the font would no longer be readable and SC 1.4.12 would not be fulfilled. However, if the font and background color differ, the question would be what the contrast requirements are. And I would assume that all other WCAG SC still apply, i.e. also the contrast requirements from SC 1.4.3.
I only find it difficult to deal with criteria that have more to do with each other in terms of content, e.g. SC 1.4.12 and SC 1.4.10: Must it still be possible to adjust the text spacing at 320px?

[mraccess77]

My understanding is that text spacing does need to be supported at 320CSS pixel widths as well because that is a page variation and everything must be tested at each variation.

[JAWS-test]

My understanding is that text spacing does need to be supported at 320CSS pixel widths as well because that is a page variation and everything must be tested at each variation.

If I follow this logic, then 1.4.4 should be valid at 1.4.10 too, 200% zoom is possible at 320px width. I do not believe, that many pages fulfill this...

[mraccess77]

I'd say that at 320CSS pixels 1.4.4 would be met through browser zoom which allows for horizontal/vertical enlargement rather than expecting the page to reflow further past 320CSS pixels. Many user agents have ways to perform this type of zoom without triggering reflow. For example, on my touch screen laptop pinch zoom on the touch screen is often treated differently than browser zoom with mouse and keyboard.

[JAWS-test]

I'd say that at 320CSS pixels 1.4.4 would be met through browser zoom

I don't think it's necessary to test 200% zoom at 320px, because according to Understanding 1.4.10 the 320px is required to be able to zoom 400%, so if I require 320px + 200% zoom, the page must allow 800% in the end. But this is not required by the WCAG. Quite the opposite: in 1.4.10 there is even the exception that with 400% zoom the content only needs to be enlarged by 200%. I also assume that someone who needs 800% zoom uses a screen magnifier and therefore does not need a browser zoom

[patrickhlauke]

@JAWS-test not quite correct. SCs apply to all possible media query breakpoint/variations. a user may start at 320 CSS px width on their phone, and they still need to be able to zoom to at least 200%.

we don't expect reflow to work at widths below 320 CSS px because that becomes eminently difficult (when you can barely fit an entire long word in the width), so horizontal scrolling is allowed beyond that point.

[JAWS-test]

@patrickhlauke: I do not agree.

All SCs apply to all possible breakpoints according to 5.2.2 Full Pages. But this has nothing to do with SC 1.4.10 and 320px. Breakpoints can also be at 40000px, 300px and 20px and would then have to be tested.

320px are defined in SC 1.4.10 for 400% zoom. And it would not make sense to test 400% zoom together with 200% zoom.

I do not see that SC 1.4.10 has anything to do with phones that are 320px wide. It has to do with desktop screens with 1280px width.

The only thing that applies: A display with 320px or less does not have to meet 1.4.10 at zoom. A display with 640px only needs to meet 1.4.10 up to 200% zoom, etc.

[mraccess77]

I agree you would not need to test 200% zoom at 320CSS pixels. The goal with SC 1.4.4 is to make sure that at some point you can reach 200% of the default size of text - this is generally starting from the 1280x768 type size and zooming in to ensure at some point it can be reached.

[patrickhlauke]

I agree you would not need to test 200% zoom at 320CSS pixels.

so you're exempting mobile sites from allowing pinch to zoom, for instance? I'm sure that's not what you mean...