-
Notifications
You must be signed in to change notification settings - Fork 55
1.4.11 - *active* user interface components? #617
Comments
Actually, I guess the definition for "user interface component" needs to stay as-is, because it is already used in many other places that still need it to include inactive UI components. For example, an inactive component still needs to have name, role, value. So, if the intent of the word "active" in Success Criterion 1.4.11 Graphics Contrast is to exempt inactive/disabled components, then the SC language should specifically state that inactive/disabled components are exempt. This is what Success Criterion 1.4.3 Contrast (Minimum) and Success Criterion 1.4.6 Contrast (Enhanced) both do. This would allow us to remove the misleading/confusing word "active" from the phrase " |
Possible solutions: find an alternative word for ACTIVE - perhaps functioning or operating or operable. Hmm, if a component is non-disabled but broken (it does not do what it is supposed to do) is it still functioning or operating. That leaves Operable - able to be used. This seems to work. Proposal |
I think making it 'operable' user interface components works, and it causes the least change. It would get quite wordy with a full exception for inactive components. |
I don't think that it would be too wordy, and introducing a new term (new except in that we use it as the name for an entire principle). To include mention of inactive would be like this: Visual information used to indicate states and boundaries of user interface components, except for inactive components or where the appearance of the component is determined by the user agent and not modified by the author; |
I fully support Andrew's wording. And I agree that this would be better than an addition of a new term/definition. |
Andrew's wording works for me.
…On Jan 6, 2018 6:44 PM, "jared-w-smith" ***@***.***> wrote:
I fully support Andrew's wording. And I agree that this would be better
than an addition of a new term/definition.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#617 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AG_WLyl1LmSv80Z2lLdz_V9pcOftf5Z4ks5tIBNlgaJpZM4Q7YTH>
.
|
ok, that works. |
Accepted change in CFC a couple weeks ago. The change to my suggestion above is editorial from what was in the CFC. |
One phrase in this SC that is especially concerning to me is "active user interface components". The "active" state of components is defined as the state when the user is activating the control (see https://www.w3.org/wiki/CSS/Selectors/pseudo-classes/:active or search for "active" in the ARIA spec). This would very likely be interpreted to only require sufficient contrast during this state. I think the intent is to exempt inactive/disabled components, but "active" is not the opposite of "disabled" or "inactive" in this context.
I believe "active" should be removed from the SC language, and the definition for "user interface component" amended to exempt disabled components.
The text was updated successfully, but these errors were encountered: