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

1.4.3, 1.4.11 Contrasts of disabled elements #869

Closed
JAWS-test opened this issue Aug 24, 2019 · 2 comments
Closed

1.4.3, 1.4.11 Contrasts of disabled elements #869

JAWS-test opened this issue Aug 24, 2019 · 2 comments

Comments

@JAWS-test
Copy link

I have two questions on this subject:

  • If I understood @patrickhlauke correctly (Should role button and input button be a WCAG fail if cannot be activated using space? #857), the WCAG SCs are normative and all other documents (Understanding, Failure etc.) are not normative. This means that the latter can explain the SCs, but cannot extend, restrict or even contradict them. In SC 1.4.11, there is no restriction regarding deactivated elements (as opposed to those in 1.4.3). In the Understanding to 1.4.11 there is the restriction to disabled elements. That would not be allowed, would it? I understand the justification in 1.4.11, but is it permitted at all?
  • Why should disabled elements always be excluded from the contrast requirement (for 1.4.3 and 1.4.11)? There are cases where these elements have to transport important information and thus should be recognizable.
    • Example 1: Completion of the order process - to check the entries, all form fields are displayed disabled. If they are wrong, the form can be processed again with a "Back" function.
    • Example 2: Application with missing access rights to change certain configurations, but the possibility to read them in disabled form fields.
@jake-abma
Copy link
Contributor

First question:

In SC 1.4.11, there is no restriction regarding deactivated elements (as opposed to those in 1.4.3).

This is not correct as 1.4.11 states "except for inactive components", see:

User Interface Components
Visual information required to identify user interface components and states, except for inactive components or where the appearance of the component is determined by the user agent and not modified by the author;


Second question:

Why should disabled elements always be excluded from the contrast requirement (for 1.4.3 and 1.4.11)?

You are right and it is correct that a group of people do want to perceive this information with enough contrast.
On the other site there is also the need from a visual perspective to make button "look" disables in order for the content to be understood in a fast and clear manner.

The result is that none of neither serves both worlds and this has been discussed many, many times in the WG. People in the WG do not disagree with both wishes but can't require one in favour of the other. A way to fix this might be the possibility of adding (disabled) icons, or providing multiple ways of showing disabled elements. In future this might also be done / possible with personalisation, work on this is being performed by the COGA TF.

Also in Silver (WCAG 3.0...) it will be on the agenda to see how we might find wording to solve this question.

@JAWS-test
Copy link
Author

First question: My fault, sorry!
Second question: That doesn't contradict itself to make something look deactivated and yet to present it with sufficient contrasts.

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

No branches or pull requests

2 participants