search

w3c / wcag

Web Content Accessibility Guidelines
https://w3c.github.io/wcag/guidelines/22/
Other
1.12k stars 254 forks source link

Clarification on the meaning of "disabled" and "turn off" #1480

Open carlosapaduarte opened 4 years ago

carlosapaduarte commented 4 years ago

Following the review of some ACT rules (https://github.com/act-rules/act-rules.github.io/issues/1394) we came to discuss the difference between "disable" (action) and "disabled" (state).

Several WCAG success criteria refer to the action, while they probably want to imply the state. For example:

Both these success criteria refer to the action of disabling (the response to an event) or turning off (a keyboard shortcut). However, if the mechanism responsible for disabling or turning off does so for only a period of time (e.g. after a timer expires the shortcut is turned back on or the response to the event is enabled again), the resource should not conform to the success criterion. At least that was our interpretation. This would be clarified if the success criteria referred explicitly to the state and not the action.

ghost commented 4 years ago

There's SC that refers to inactive user interface components, such as the contrast ones. And I've always taken this to mean an interactive element that currently used at that time by any user. For example:

<button disabled>Blah</button>

In these cases, I have always assumed that there must be a way to turn the functionality off permanently or at least within the context of the session.

For example, users can turn off functionality triggered by motion and turn off single key shortcuts. Both are to avoid accidental activation. For example, activating due to a tremor or activating with voice recognition software.

To that end, I agree that it would be useful to use the same language and potentially defined in the glossary.

patrickhlauke commented 2 months ago

However, if the mechanism responsible for disabling or turning off does so for only a period of time (e.g. after a timer expires the shortcut is turned back on or the response to the event is enabled again), the resource should not conform to the success criterion.

resurrecting this old issue ... i'm not convinced this necessarily follows from the SC. if the disabling/turning off gets reverted back, it would arguably still pass as it still provides a mechanism at that point. it would annoy users, but I doubt it'll be possible to unambiguously and normatively define for how long a mechanism must allow something to be disabled/turned off (forever? for the duration of the session? across different visits on different platforms?)