Proposed definition for Inactive

[awkawk]

Context: https://www.w3.org/2020/06/09-ag-minutes#item07
Survey: https://www.w3.org/2002/09/wbs/35422/2020-05-cwa/results#x302

---

Preview | Diff

[patrickhlauke]

a rewording/restructuring of the proposed PR here? #638

[awkawk]

@patrickhlauke yes, based on the discussion on the call earlier today.

[patrickhlauke]

i'll close the other one then...

[awkawk]

@patrickhlauke that's fine as the WG seemed to want to go in this direction. If we need to redirect again we can always reopen 638

[bruce-usab]

Just dropping in to say I have reread the proposed definition and I think it is really quite good.

Thanks! This edit is much better than my idea of simply replacing inactive with disabled.

[cwadamsoforacle]

Looks good to me.

[patrickhlauke]

Just a heads-up ... is this going to be merged?

[jnurthen]

What about controls that take focus but cannot be activated such as a date in a grid which is not available or the other control types specified at https://w3c.github.io/aria-practices/#kbd_disabled_controls.

[patrickhlauke]

i think that's covered by the proposed definition there, since it says nothing about whether or not the inactive component can receive focus or not...just that it's not available for user interaction (unless you mean that even the act of focusing on it is an interaction?) / operable.

[jnurthen]

yes IMO focusing is an interaction so this doesn't apply if focusable as written

[mbgower]

That wording from the APG really complicates things. I'm inclined to say that if something is navigable but not operable, it should not be considered disabled (and should not be given a pass on text contrast considerations). We spent a lot of time at IBM designing read-only versions of components; it was difficult, but it is possible. There should be a way of achieving minimum contrast for unavailable options in a listbox (to use one of the APG examples), if the desire is to make them discoverable by all. Letting them be 'discoverable' programmatically but not visually seems inequitable.

[jnurthen]

How about?

Suggested change

	<p>A state of a <a>User Interface Component</a> when it is not available for user interaction, such as a disabled control in HTML. An inactive user interface component is present but not currently operable using standard input mechanisms such as keyboard, pointer, or assistive technology.</p>
	<p>A state of a <a>User Interface Component</a> when it is not available for user interaction, such as a disabled control in HTML. An inactive user interface component is present, and in some cases may even be focusable, but is not currently operable using standard input mechanisms such as keyboard, pointer, or assistive technology.</p>

[patrickhlauke]

i'd still say that this is unnecessary, but can live with it...

[mbgower]

Nope, I think this is marring the definition of inactive, which I think is both inoperable AND not navigable.

Suggested change

	<p>A state of a <a>User Interface Component</a> when it is not available for user interaction, such as a disabled control in HTML. An inactive user interface component is present but not currently operable using standard input mechanisms such as keyboard, pointer, or assistive technology.</p>
	<p>A state of a <a>User Interface Component</a> when it is not available for user interaction, such as a disabled control in HTML. An inactive user interface component is present but not currently operable or navigable using standard input mechanisms such as keyboard, pointer, or assistive technology.</p>

[alastc]

It would be useful to resolve whether we think 'inactive' controls can be focusable before taking it back to the group.

Sorry, slipped off my radar as the issue was closed.

[patrickhlauke]

personally, still think that the concepts of inactive/disabled/inoperable and focusable are two orthogonal things. thinking for instance about readonly inputs that can receive focus by default, but are inoperable in the sense that it's not possible to edit them (unless this now opens up a different can of worms about "is being in a readonly state really 'inactive'?")

but it's definitely worth mentioning this, as not everybody (even here) seems to agree. i can live with something along the lines of @jnurthen's suggestion (or even as a separate standalone Note: in some cases, inactive user interface components are still focusable, but once focus is on them they can't be operated).

[jnurthen]

personally, still think that the concepts of inactive/disabled/inoperable and focusable are two orthogonal things. thinking for instance about readonly inputs that can receive focus by default, but are inoperable in the sense that it's not possible to edit them (unless this now opens up a different can of worms about "is being in a readonly state really 'inactive'?")

I have always understood that readonly controls are NOT inactive. Read-only controls can be operated (you can move the cursor and copy them) so they certainly shouldn't be exempt from any contrast requirements.

[patrickhlauke]

so we may need some clarification of this aspect too, perhaps?

• inactive means you can't activate it/change the selection (for <select> type things)/check it/toggle it
• you may be able to focus it (i.e. whether it's focusable or not is orthogonal to whether it's active or inactive)
• read-only inputs don't count as inactive because you can still select their content and copy it (and because it would open up too much of a loophole if they were exempted from contrast requirements etc)

[jnurthen]

It would be useful to resolve whether we think 'inactive' controls can be focusable before taking it back to the group.

We go into this a bit in ARIA Authoring Practices https://www.w3.org/TR/wai-aria-practices-1.2/#kbd_disabled_controls

[JAWS-test]

The fact that disabled or inactive elements are excluded from the contrast requirements is, in my opinion, a mistake in the WCAG. This is shown by the ARIA example. If the ARIA Guidelines say that sometimes disabled elements should be accessible so that they can be perceived with assistive technology, then these elements should also have sufficient contrast. See #869

[alastc]

The fact that disabled or inactive elements are excluded from the contrast requirements is, in my opinion, a mistake in the WCAG.

Perhaps, but it is due to there not being a solution to the problem of many people thinking the control is active when it isn't. I've seen that happen myself in usability testing. Without a solution to that problem, it isn't likely to change.

If Patrick's list above is agreeable then perhaps something like (bold for new, at the end):

A state of a User Interface Component when it is not available for user interaction, such as a disabled control in HTML. An inactive user interface component is present, and in some cases may even be focusable, but is not currently operable using standard input mechanisms such as keyboard, pointer, or assistive technology. A read-only control is active because the text should be readable and available for copy operations.

[patrickhlauke]

would be good for this to be finalised/clarified (as this topic has come up in discussions again today)

[patrickhlauke]

I'd reopen this, as it seemed close to agreed/consensus at the time, and probably still something that would be good having?

[patrickhlauke]

@alastc would be good to get this looked at again in the WCAG 2.x calls at some point soon to clear the deck

[netlify]

✅ Deploy Preview for wcag2 ready!

Name	Link
🔨 Latest commit	ddf8f07
🔍 Latest deploy log	https://app.netlify.com/sites/wcag2/deploys/6712837a2ec2cc00087aa021
😎 Deploy Preview	https://deploy-preview-1154--wcag2.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify site configuration.

[mbgower]

I have always understood that readonly controls are NOT inactive. Read-only controls can be operated (you can move the cursor and copy them) so they certainly shouldn't be exempt from any contrast requirements.

I agree that a read-only control is not inactive. Most can take focus, and if a read-only control's content was greyed out, I would consider that a failure of Contrast, since the content is in a state intended for consumption. So I'm inclined to say that something that can take focus is not inactive. That seems to be supported by the final note:

A read-only text input field which is focusable using standard input mechanisms is considered to be active.

[fstrr]

We go into this a bit in ARIA Authoring Practices https://www.w3.org/TR/wai-aria-practices-1.2/#kbd_disabled_control

If anyone is looking for that content, I believe it's moved to this Developing A Keyboard Interface page.