Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Explanation of exception in F81 insufficient #873

Open
JAWS-test opened this issue Aug 26, 2019 · 11 comments · May be fixed by #1033
Open

Explanation of exception in F81 insufficient #873

JAWS-test opened this issue Aug 26, 2019 · 11 comments · May be fixed by #1033

Comments

@JAWS-test
Copy link

http://www.w3.org/WAI/WCAG21/Techniques/failures/F81:

It would also not fail if the color chosen had sufficient luminosity difference (lightness) from the other text that it would be easily be seen as different if viewed in black and white. In these cases - the information would not be displayed in color (hue) alone but also in "presentation" or "lightness" respectively

What is "sufficient luminosity difference"? 3:1 as in G183? And if: Why do links with 3:1 contrast need further clues to be able to recognize them and required or error fields do not:

if additional visual confirmation is available when a user points or tabs to the link

@alastc
Copy link
Contributor

alastc commented Sep 29, 2019

I think it would be useful to add to the technique:

  • A reference to G183.
  • A reference to non-text contrast, for things like an extra red border, of change of color for the input border.

@JAWS-test
Copy link
Author

I'd like that. However, 2 questions remain unanswered:

  • Why do links require further features for mouseover and incorrect fields do not?
  • Is the reference to 1.4.11 correct if 1.4.11 only considers directly adjacent elements?

@alastc
Copy link
Contributor

alastc commented Sep 30, 2019

  • You are leaping from one particular technique (G183) to an area that doesn't have a technique (input errors). The short answer is probably that G183 was written pre-touchscreen popularity when mouse & keyboard were the primary inputs, so mousing was included in the procedure. That doesn't mean anything about inputs.
  • It is correct in that it would help explain why a change in contrast could be a method. I'm not saying it would be the test for that, but that using a contrast change would be another visual queue compared to color alone.

@JAWS-test
Copy link
Author

You are leaping from one particular technique (G183) to an area that doesn't have a technique (input errors). The short answer is probably that G183 was written pre-touchscreen popularity when mouse & keyboard were the primary inputs, so mousing was included in the procedure. That doesn't mean anything about inputs.

The question would be whether the recognizability of links is more important than that of errors. If so, then I think the distinction is good. If no, then the requirement for links and form fields with errors should not be different.

@alastc
Copy link
Contributor

alastc commented Sep 30, 2019

It isn't about importance, the context is often quite different. For example, links can be buried in blocks of text, whereas an error message is generally near an input. As the context is generally different, so the requirements can be different.

@JAWS-test
Copy link
Author

whereas an error message is generally near an input

But F81 is about the fact that there is no error message. The incorrect fields are only marked with color. And thus just as little to recognize as only colored links in text.

@alastc
Copy link
Contributor

alastc commented Sep 30, 2019

You asked whether links and inputs should be treated differently, and I said they are used differently so they could be treated differently.

@JAWS-test
Copy link
Author

JAWS-test commented Sep 30, 2019

I think it would be useful to add to the technique: A reference to G183.

I also think this makes sense, but it is not sufficient, because additional requirements apply to links in G183. If these do not apply to other content, this should also be clearly stated:

  1. Check that pointing (mouseover) to the link causes a visual enhancement (such as an underline, font change, etc.)
  2. Check that moving keyboard focus to the link causes a visual enhancement (such as an underline, font change, etc.)

And G183 is only about the contrast of texts with each other and not about the contrast of non-text contents. Since WCAG distinguishes between text and non-text contrasts (1.4.3, 1.4.11), it is not clear whether this distinction also applies to G183.

With G183 it is also not clear whether it refers only to links or also to other interactive elements. The headline says "links or controls". The chapter "test" then only refers to links. If G183 applies to other elements, test steps 3 and 4 should only apply to links and test step 1+2 to all elements.

@mraccess77
Copy link

Keep in mind that sufficient techniques can go beyond what is required

@JAWS-test
Copy link
Author

Keep in mind that sufficient techniques can go beyond what is required

@mraccess77 Do you mean that G183 could also be formulated in such a way that a contrast of 3:1 is sufficient without links having to be displayed visually differently during focusing and mouseover?

If 3:1 is a general criterion to meet SC 1.4.1, why isn't it mentioned directly in the understanding?

@JAWS-test JAWS-test reopened this Feb 4, 2020
@JAWS-test2 JAWS-test2 linked a pull request Feb 4, 2020 that will close this issue
@alastc
Copy link
Contributor

alastc commented Jan 6, 2021

As an update: The understanding doc for 1.4.1 and technique G183 have been updated recently and I think address most of the conversation here.

Leaving open as the text of G81 could do with an update. E.g. in the note it could say:

It would also not fail if the color chosen had sufficient luminosity difference (lightness) from the other text that it would be easily be seen as different if viewed in black and white. Like technique G183 [link], a sufficient luminosity difference would be a contrast ratio of 3:1.

Not an urgent update though.

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

Successfully merging a pull request may close this issue.

3 participants