Skip to content
This repository has been archived by the owner on Jun 30, 2018. It is now read-only.

Commit

Permalink
Inactive controls
Browse files Browse the repository at this point in the history
Based on the issues discussion #805 I added additional context and explanation for inactive controls.
  • Loading branch information
mbgower committed Apr 13, 2018
1 parent 367c737 commit 4507df3
Showing 1 changed file with 11 additions and 2 deletions.
13 changes: 11 additions & 2 deletions understanding/21/non-text-contrast.html
Original file line number Diff line number Diff line change
Expand Up @@ -96,9 +96,18 @@ <h4>Active User Interface Component Examples</h4>

<h4>Inactive User Interface Components</h4>

<p>User Interface Components that are not available for user interaction (eg: a disabled control in HTML) are not required to meet this color contrast requirements in WCAG 2.1. Due to the different needs and preferences of people with low vision and people with cognitive disabilities, a contrast requirement for disabled user interface components is recommended for future advancements in user preferences.</p>

<p>An inactive user interface component is visible but not currently operable. Example: A submit button at the bottom of a form that is visible but cannot be activated until all the required fields in the form are completed.</p>
<p><input type="submit" disabled></p>
<p>Inactive components, such as disabled controls in HTML, are not available for user interaction. The decision to exempt inactive conrols from the contrast requirements was based on a number of considerations:
<ul>
<li><strong>Backward compatibility.</strong> Existing WCAG 2.0 guidance for 1.4.3 Contrast (Minimum) specifically exempts <q>text or images of text that are part of an inactive user interface component</q>. It would be confusing and inconsist to exempt <strong>text</strong> in inactive components from contrast considerations while requiring sufficient contrast for the graphical container the text resides in.</li>
<li><strong>Conflicting needs and desires.</strong> Although meaningful information is conveyed by a lower-contrast disabled control (to those who can perceive it), not all users desire an increase in the prominence of disabled controls.</li>
<ul>
<li>Low-vision - some users want to ignore the disabled elements, just focusing on the enabled elements. Other low vision users want to see the disabled items clearly. So, there was not a one-size-fits all solution.</li>
<li> Cognitive - some people with cognitive differences really want to be able to focus on the active elements (and ignore the non-active elements). If we force stronger contrast on the disabled elements, it will likely be difficult for all sighted people to distinguish what is active (and what is disabled).</li></ul>

</ul>
A solution for treating the presentation of disabled controls based on user preferences is anticipated as a future advancement.</p>

</section>
</section><!-- end user-interface-component section -->
Expand Down

0 comments on commit 4507df3

Please sign in to comment.