Skip to content

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

Open
@jake-abma

Description

@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)

Screen Shot 2020-11-13 at 12 30 20 PM

Activity

patrickhlauke

patrickhlauke commented on Nov 16, 2020

@patrickhlauke
Member

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

jake-abma commented on Nov 24, 2020

@jake-abma
ContributorAuthor

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

patrickhlauke commented on Nov 24, 2020

@patrickhlauke
Member

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

JAWS-test commented on Nov 24, 2020

@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

mraccess77 commented on Nov 24, 2020

@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

JAWS-test commented on Nov 24, 2020

@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

mraccess77 commented on Nov 24, 2020

@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

JAWS-test commented on Nov 25, 2020

@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

patrickhlauke commented on Nov 25, 2020

@patrickhlauke
Member

@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

JAWS-test commented on Nov 25, 2020

@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

mraccess77 commented on Nov 25, 2020

@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

patrickhlauke commented on Nov 25, 2020

@patrickhlauke
Member

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...

alastc

alastc commented on Nov 26, 2020

@alastc
Contributor

Going back to the original issue (text-spacing + text contrast).

Personally, I don't think there should be a different between text that spills out of it's container and is invisible (due to being under another element/box/background), or overlapping, or illegible due to contrast. If that happened as part of reflow I'd think the same thing as well.

That does go beyond our previous discussions on page variations though, so it would be good to agree on this.

Chair hat on: I think the appropriate place to address this (if agreed) would be the text-spacing understanding doc. Could someone draft an update that includes this as something in the "Effects of Not Allowing for Spacing Override" section?

patrickhlauke

patrickhlauke commented on Nov 27, 2020

@patrickhlauke
Member

Personally, I don't think there should be a different between text that spills out of it's container and is invisible (due to being under another element/box/background), or overlapping, or illegible due to contrast. If that happened as part of reflow I'd think the same thing as well.

i think the underlying question though is: do you fail this just under text spacing, or do you then also fail this under contrast (minimum)?

in this case, as it's a change to the author's original styles, i'd be inclined to fail it just under text spacing.

if something like text spilling out and become illegible/low contrast happened when resizing (using zoom, not text-only sizing) or reflowing though - not modifying the author styles, but just changing the environment / viewport dimensions that the content is presented in, then i'd personally fail under both resizing/reflowing and under contrast (minimum)

alastc

alastc commented on Dec 4, 2020

@alastc
Contributor

Personally, I'd probably fail under the trigger (e.g. text-spacing), but the conformance model doesn't try to cover that aspect as in either case it isn't a pass.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

      Development

      No branches or pull requests

        Participants

        @alastc@patrickhlauke@mraccess77@jake-abma@JAWS-test

        Issue actions

          Stacked SC: 1.4.12: Text Spacing AND 1.4.3: Contrast Do they have a interrelationship? · Issue #1524 · w3c/wcag