Use of the word“state” is not sufficiently consistent

[bruce-usab]

WCAG 2.1 added the word state to the glossary.

This glossary definition of the word state is consistent with (old 2.0) 4.1.2 (emphasis added to this and other excerpts):

For all user interface components (including but not limited to: form elements, links and components generated by scripts), the name and role can be programmatically determined; states, properties, and values that can be set by the user can be programmatically set; and notification of changes to these items is available to user agents, including assistive technologies.

The glossary definition is consistent with (new for 2.1) 1.4.11:

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;

From the conversation at w3c/wcag3#169 it occurred to me to do a word search through 2.0/2.1/2.2 for how we use this word, and which of those uses align with defined term state.

I am concerned that the (new for 2.2) uses of this word, in 2.4.11 and 2.4.12 are not sufficiently consistent with 4.1.2 and 1.4.11.

When user interface components receive keyboard focus … There is an area of the focus indicator that has a contrast ratio of at least 3:1 between the colors in the focused and unfocused states.

When user interface components have keyboard focus … There is an area of the focus indicator that has a contrast ratio of at least 4.5:1 between the colors in the focused and unfocused states.

As I understand it, the expectation is that a UIC like DIV or FIELDSET where keyboard focus moves to, is that there will be visible indicator. The problem, I think, is that these sort of UIC might not programmatically have a state change (at least not in the way change of state is used in 4.1.2).

1. Editorial (n.b., also applies to 2.1): 4.1.2 use of states should be linked to the glossary term. (SC 1.4.11 does link to the glossary.)
2. There are other (normative) uses of the word state where the word has a more colloquial meaning. Linking the word in 4.1.12 (as we do in 1.4.11) but leaving the other uses of the word unlinked does provide some clarity. Is that enough?
3. Is the use of the word state in 2.4.11 and 2.4.12 wholly consistent with use of the word (as a defined term) in 4.1.2 and 1.4.11?

As a point of reference, here are uses of the word state that are not a reference to the defined term:

general flash and red flash thresholds: … Note 3: The current working definition in the field … is where, for either or both states involved in each transition…

blinking: switch back and forth between two visual states in a way that is meant to draw attention

status message: change in content that is not a change of context, and that provides information to the user on the success or results of an action, on the waiting state of an application, on the progress of a process, or on the existence of errors

[alastc]

I am concerned that the (new for 2.2) uses of this word, in 2.4.11 and 2.4.12 are not sufficiently consistent with 4.1.2 and 1.4.11.

I'm not sure I understand, the definition is: "dynamic property expressing characteristics of a user interface component that may change in response to user action or automated processes"

Focus is listed as a potential state, and the new SCs are asking people to test between the two states. I'm not sure what the problem is.

As I understand it, the expectation is that a UIC like DIV or FIELDSET where keyboard focus moves to, is that there will be visible indicator. The problem, I think, is that these sort of UIC might not programmatically have a state change (at least not in the way change of state is used in 4.1.2).

Just because 4.1.2 is about programmatic states, doesn't restrict the use of the term to things which have meta-data associated with the states.

[bruce-usab]

@alastc I am so hoping that I am making a mountain out of a molehill here. With 2.1, we added the definition for state, which I thought was fine, because all the examples listed were consistent with I how I understood the term. It is always dangerous to make inferences from examples, but the word is one developers have long used. In terms of accessibility standards, I will offer the year 2000 original 508 Standards 1194.21(d) as evidence that a more specialized reading of the word is appropriate:

Sufficient information about a user interface element including the identity, operation and state of the element shall be available to assistive technology.

Obviously, that is perfectly compatible with 2008 WCAG 2.0 SC 4.1.2.

Your pointing out here that something like blinking meets the 2.1 definition for state means that 4.1.2 is much broader and far more encompassing than I think any of us thought about or might be comfortable with.

It now seems to me that the 2.1 definition made a retroactive and significant normative change to a well-established SC. The change and implications were subtle. With 2.4.11 and 2.4.12 reinforcing this broader meaning for state I will respectfully suggest that 2.2 would benefit from a bit more review of these two SC.

I so appreciate your summary sentence above. I think I am in fact advocating that SC restrict the use of the term to things which have meta-data associated with the states. That seems very pragmatic to me.

[bruce-usab]

HT to @kengdoj for pointing me to the ARIA definition for state (emphasis added):

A state is a dynamic property expressing characteristics of an object that may change in response to user action or automated processes. States do not affect the essential nature of the object, but represent data associated with the object or user interaction possibilities.

The bolded bit is an important distinction, and consistent with @alastc comment about meta-data. I submit that it is important for 2.2 to align with this stricter meaning of state.

[alastc]

HI @bruce-usab,

So how would you describe the difference between focused and unfocused?

E.g. I'm looking at the normative text that says "between the colors in the focused and unfocused states", and I can't think of a suitable alternative term.
It is the essentially the dictionary definition ("the particular condition that someone or something is in at a specific time.").

I'm also still not seeing the problem. Some SCs refer to states which have meta-data, and some states are visual and do not involve meta-data (at least from an author point of view).

I suppose technically there is meta-data involved in focus (and hover etc.) because the browser will track the different states. AT doesn't generally report that a thing is focused, but it does read out what is focused as a natural part of the interaction.

[bruce-usab]

@alastc — I think I would like to ask that there be a survey to AG WG for updating the 2.2 definition to fully align to that from ARIA (tr and ed – same in both docs).

The problem is using a more general meaning of a word in new SC text when older SC text is well understood to have a more specialized/nuanced/restrictive meaning.

The new (for 2.2) SC has the effect of changing the old SC, which I am sure you will agree is not something we intended to do with 2.1!

[bruce-usab]

Trying to be a little bit more productive rather than just throwing bricks…

E.g. I'm looking at the normative text that says "between the colors in the focused and unfocused states", and I can't think of a suitable alternative term. It is the essentially the dictionary definition ("the particular condition that someone or something is in at a specific time.").

I agree that that this use is essentially the dictionary definition. But that is exactly why I think there is a problem!

I do think these two SC can/should be written without using the word state. More words of course, but maybe not too many more.

Current:

There is an area of the focus indicator that has a contrast ratio of at least 3:1 between the colors in the focused and unfocused states.

Equivalent, but too long:

There is an area of the focus indicator that has a contrast ratio of at least 3:1 between the color in the user interface component before it receives keyboard focus and the color in the user interface component after it receives keyboard focus.

Proposed:

There is an area of the focus indicator that has a contrast ratio of at least 3:1 between the colors used before and after the user interface component receives keyboard focus.

[alastc]

Hi Bruce,

I’m happy to put this in front of the group, but we do need to specify the problem better.

For example, the current understand doc for 4.1.2 (since 2.0?) has included:

A particularly important state of a user interface control is whether or not it has focus. The focus state of a control can be programmatically determined, and notifications about change of focus are sent to user agents and assistive technology.

Why is focus, for focus appearance, not aligning with other definitions of state?

The ARIA definition you linked to is:

A state is a dynamic property expressing characteristics of an object that may change in response to user action or automated processes. States do not affect the essential nature of the object, but represent data associated with the object or user interaction possibilities.

Focus seems to fit into that (i.e. user-interaction possibilities), what’s the problem?

It is almost word-for-word the same definition we have for state in WCAG 2.1 that was added for non-text contrast.

[patrickhlauke]

i'm in a state of confusion over this 😄

but no, seriously, I think - and correct me if I'm wrong - @bruce-usab's concern here is the distinction between:

• state = a programmatic property/attribute, that can be queried in code, and can be exposed to assistive technologies (something like the actual property of being focused, selected, pressed, checked, disabled, readonly)
• state = a more generic/colloquial understanding, which is a superset of the former, but includes things that we could call a "state" but don't have a direct one-to-one mapping to an attribute/property in the DOM/a11y tree - blinking for instance

Bruce then mentions things like a <div> or <fieldset> counting as being focused, when in fact the element itself, if queried, won't report that it is focused (programmatically) - technically, an element inside the <div> etc is focused (i.e. it's "focus-within"). I'd extend this to the idea of many complex ARIA widgets using aria-activedescendant, where technically only the outer widget itself has focus, but there's a "virtual" focus being moved around. here again there's a pedantic mismatch between focus state being the "if you query this element, this has the focus" / what's document.activeElement, versus what the user understands/perceives as having focus. which reminds me conceptually of this #1001 (comment) (which points to an even earlier discussion that i couldn't locate at the time) on this hairy concept too.

so i'm guessing Bruce's concern here is that because there are two ideas of "state" (the technical one and the folksy/looser one) that it will cause confusion, and that having a glossary definition for one interpretation may retrospectively change the meaning of SCs that were (tacitly) using the other meaning of the word.

but i've not delved deeply into what the potential repercussions that Bruce mentions are. would need some examples of "in the past, with the tacit assumption that 'state' meant X, this thing would pass, or the SC would not apply at all to this ... now, with this glossary definition, that changes"

[bruce-usab]

Thank you @patrickhlauke for (once again) better expressing what I am trying to say!

[alastc]

Bruce's concern here is that because there are two ideas of "state" (the technical one and the folksy/looser one) that it will cause confusion, and that having a glossary definition for one interpretation may retrospectively change the meaning of SCs that were (tacitly) using the other meaning of the word.

Except I don't think that's the case because:

• The definition we used for state (added with non-text contrast) matches the ARIA one;
• 4.1.2 specifically mentions focus as an important state (in the understanding doc);
• Focus is a technical and visual state.

I.e. our use of 'state' with focus is within the definition we have, and the old SC (4.1.2) references focus as well. Focus is a bit different from something like "pressed" which has an author-set attribute, but it is still something that can be programmatically determined.

now, with this glossary definition, that changes"

Well, that was added in WCAG 2.1, and explicitly included focus then, so we aren't changing anything by adding SCs about focus and referencing that as a state.

[mbgower]

Hopefully this adds something to the conversation...

It is entirely possible to use a word in the sense of a defined term. You do that by linking to it.
The use of link to denote a defined term is especially the case inside the normative text of an SC.

It is also allowable to use a word in another sense: you can clarify that by not linking to the definition.
"State" can be a noun, adjective or a verb, so obviously not all occurrences of it are going to be about the defined term.

What I initally thought Bruce was asking about was whether there was such a thing as an unfocused state. I don't see too much disagreement on focus being a state (even with all the oddities these days with combobox searches which sorta have 2 through the use of active descendant). But it's a more interesting question asking if 'unfocused' is a state

<script type="text/javascript">
        function setFocus() {
            document.getElementById("focus").focus();
        }
  
        function removeFocus() {
            document.getElementById("focus").blur();
        }
    </script>

It's an interesting question, but s per Alastair's comments, I'm not sure it really causes a problem. As Bruce notes, if this is really something we want to commit cycles to it can be done easily if not gracefully modified by rejigging the words in the SCs a bit. However, I don't see any reason why there can't be a focused state, so...
Current:

between the colors in the focused and unfocused states.

Possible:

between the colors in the focused state and when not focused.

@bruce-usab I'm still trying to understand what is any impact you think there is by the current language. What is the problem you foresee?

[bruce-usab]

The impact is that someone new to WCAG 2x and reading 4.1.2 (for the first time) would — very logically and very reasonable — assume that the 4.1.2 use of the word state is the same as with 2.4.11 and 2.4.12 (i.e., the folksy/looser one).

This someone would therefore assume that 4.1.2 is requiring much more than it does, including some things which are not even technically feasible.

To avoid this pitfall, I am asking that 2.2:

1. Replace the definition for state with the one used in ARIA.
2. Link state in 4.1.2 to the glossary term.

It would be even in better if with 2.2 we can:

3. Avoid use of state in SC text if we do not really intend the strict ARIA-aligned technical meaning.

[alastc]

assume that the 4.1.2 use of the word "state" is the same as with 2.4.11 and 2.4.12... would therefore assume that 4.1.2 is requiring much more than it does, including some things which are not even technically feasible.

Ok, let's assume it is the same (strict) meaning, as defined.

And let's assume focus is referred to as a state, what impact does that have on 4.1.2?

the name and role can be programmatically determined;

Not relevant to this discussion.

states, properties, and values that can be set by the user can be programmatically set;

The user can set the state of something to focused by tabbing to it, or navigating to it with a screenreader and activating text-entry/forms-mode. Authors can set focus to items, but there is no requirement to do so.

and notification of changes to these items is available to user agents, including assistive technologies.

This is true of focus, with no author requirement. I.e. If you do set focus to something that is automatically announced.

I'm still not seeing a clash, and if there were I'd suggest adding a note to 4.1.2 about there being no author requirement for focus. Except that it already includes this:

A particularly important state of a user interface control is whether or not it has focus. The focus state of a control can be programmatically determined, and notifications about change of focus are sent to user agents and assistive technology.

It appears that this came up before, and was dealt with.

[mraccess77]

I'd point out that unfocused is a state "Focusable"- at least in terms of properties in prior accessibility APIs like MSAA. Unfocusable is the state of being focusable but and not focused. This is generally the default state for most controls. In platforms like HTML/Flash there are/were defined control states like focused, active, hover, default, disabled, etc. where each one could have a skin/style, etc..

[bruce-usab]

Ok, let's assume it is the same (strict) meaning, as defined.

The problem is that the 2.1 definition is not the same (strict) meaning. The 2.1 definition is closer to the looser colloquial usage. The 2.1 definition for state is a superset of the ARIA definition.

WCAG 2.0 SC 4.1.2 uses state consistent with the ARIA definition. This is not a problem.

WCAG 2.1 SC 1.4.11 uses state consistent with the ARIA definition. 2.1 also added the glossary term, and that definition is broader than the ARIA one. Strictly speaking, as noted a few times in this thread, this is not a problem. Also, for some reason, 4.1.2 does not link to state in the glossary. Somewhat ironically, this makes my concern for the shifting meaning less of a concern!

Proposed for 2.2 with 2.4.11 and 2.4.12 is the use of the term state which is not consistent with the ARIA definition. This, I submit, is a problem.

It appears that this came up before, and was dealt with.

Agreed, and before initially submitting this issue, I re-reviewed Understanding to affirm for myself that focus state is different than conveying that an area of the viewport containing the keyboard focus has changed in response to user action.

Sidebar: ARIA 1.1 (Dec 2017) predates 2.1 (June 2018). Was it our deliberate intention to use a different definition? (That would explain why 4.1.2 does not link to the glossary term. It would also change how I would suggest we plug this particular hole.)

[alastc]

The 2.1 definition for "state" is a superset of the ARIA definition.... 2.1 also added the glossary term, and that definition is broader than the ARIA one.

The aria definition is:
"a dynamic property expressing characteristics of an object that may change in response to user action or automated processes. States do not affect the essential nature of the object, but represent data associated with the object or user interaction possibilities."

In 2.1 state is:
"dynamic property expressing characteristics of a user interface component that may change in response to user action or automated processes. States do not affect the nature of the component, but represent data associated with the component or user interaction possibilities."

Apart from object becoming "user interface component", that's identical.

Also, for some reason, 4.1.2 does not link to state in the glossary.

I think that's because there wasn't a definition in 2.0, and we never went through finding older terms to link up. In general we don't link all instances of a term as it impacts readability. The 1st time it is used (in the guidelines page) should be linked, but subsequent uses need not be. (Although recently we've tended to link the first usage in each SC.)

Proposed for 2.2 with 2.4.11 and 2.4.12 is the use of the term "state" which is not consistent with the ARIA definition.

I'm still not seeing an inconsistency, perhaps because I interpret focus as a state that fits within all of the definitions we've mentioned. A user interface component can be in a state of focused, or not.

Also noting there is a concept of "Managed state" in the aria glossary, that starts "Accessibility API state that is controlled by the user agent, such as focus and selection.":
https://www.w3.org/2021/09/draft-wai-glossary#managed-state-aria-common

There is also a new definition of "focus indicator" which is explicitly a state, "the pixels that are changed to visually indicate when a user interface component is in a focused state.":
https://www.w3.org/2021/09/draft-wai-glossary#focus-indicator-wcag-2

[alastc]

"focus state" is different than conveying that an area of the viewport containing the keyboard focus has changed in response to user action

Maybe this is the nub of it, but I don't understand what you mean by this. There is a visual representation of the focus state, just like there is a visual representation of something that is selected. That doesn't create an author requirement under 4.1.2.

[JAWS-test]

@alastc

That doesn't create an author requirement under 4.1.2.

That's debatable. If focus is a status, then according to 4.1.2 it must be conveyed not only visually but also programmatically. On the one hand, this is important so that a screen reader can output the focused element (e.g., via aria-activedescendant), on the other hand, so that a screen magnifier can display the focused element in the visible area and provide it with its own focus highlighting. For this to work, the coordinates of the focused element must be transmitted correctly.

[bruce-usab]

First, I must confess to how very much I was thrown off by the extra two line returns in the 2.1 definition. I now feel I read the first sentence only, jumped to the examples, and missed the sentence in the middle. I still think there is a problem because it still very much seems to me that state has a different usage in 2.4.11 and 2.4.12 than it does in 4.1.2 and 1.4.11.

To me, a critical part of the definition is: States … represent data associated with the component

This is not true for most applications of 2.4.11 and 2.4.12. There might an element within the UIC which has a focus state (using the strictest meaning possible) and 2.4.11 and 2.4.12 are about the text cursor getting focus (and that tracks with the opening part of the definition) but the UIC itself probably does not have data representing a focus state (using the strictest meaning possible).

[alastc]

If focus is a status, then according to 4.1.2 it must be conveyed not only visually but also programmatically.

Which is automatically done by the browser otherwise it wouldn't show the focus indicator. I think that's why aria has a concept of 'managed states'.

but the UIC itself probably does not have data representing a focus state (using the strictest meaning possible).

I'm fairly sure it does, but it is managed by the browser, which is why I was saying there is no "author requirement". If there was no data representing the focus state, then AT wouldn't be able to switch from browse to forms mode when a text input is focused, and the browser wouldn't show a focus indicator.

For those things to happen, there has to be "state" information. Also, this technique for logging what has focus wouldn't work if there were not information about which element has focus.

[JAWS-test]

Which is automatically done by the browser otherwise it wouldn't show the focus indicator. I think that's why aria has a concept of 'managed states'.

This is only the case in standard situations. However, if I define my own visible focus indicator, then the programmatically focused element no longer automatically matches the visually focused element, which often leads to the following problems:

• focused element is not displayed in the visible area,
• focused element is not perceivable and operable with screen reader.

Simple example: combobox where programmatic focus remains in input field when navigating through list items. If no aria-activedescendant is used, both problems occur, if aria-activedescendant is used, only the first problem occurs (as in the ARIA APG examples https://w3c.github.io/aria-practices/examples/radio/radio-activedescendant.html, https://w3c.github.io/aria-practices/examples/menu-button/menu-button-actions-active-descendant.html and https://w3c.github.io/aria-practices/examples/combobox/combobox-select-only.html).

[alastc]

Bruce wrote:

To me, a critical part of the definition is: "States … represent data associated with the component"

That might be critical from your point of view, but that sentence finishes "or user interaction possibilities", so focus (and others) do fit within the definition (for both aria and wcag versions).

I.e. a state can be defined by meta-data associated with a control, or it might be the interaction possibilities. Both are included in what 'state' means.

Jaws-test wrote:

if I define my own visible focus indicator, then the programmatically focused element no longer automatically matches the visually focused element

You make it sound like defining a different focus style (e.g. outline: 3px red solid;) stops focus working?
I assume you are talking specifically about the active-descendant case. That's relatively rare, although it should be considered.

focused element is not displayed in the visible area,

From your other issue on the ARIA repo, it sounds like that is a bug they are investigating?

focused element is not perceivable and operable with screen reader.

I'm not sure I understand, surely if the screenreader is navigating through the options, they are read out, and are by definition focused? (NB: We don't reference that definition of focus any more so we could drop it.)

Focus is generally set by the user's interactions, so in that sense the 'data' associated with the focus state is monitored by the browser rather than the author. The author can set the focus in JS with .focus(), in which case whatever is the focused would be visually apparent to the user and read out by AT.

[JAWS-test]

@alastc

You make it sound like defining a different focus style (e.g. outline: 3px red solid;) stops focus working?

No, not at all.

I assume you are talking specifically about the active-descendant case.
That's relatively rare, although it should be considered.

This is a possible and by no means rare case. Whereby aria-activedescendant is not the problem, but part of the solution. It is really problematic without aria-activedescendant, as I wrote. I.e. a container gets the focus programmatically, but visually a child element in the container. Or an input field has the focus programmatically, but visually a list under the input field (e.g. for autocomplete functions). If I do not use an aria-activedescendant, the focused element is not perceptible for AT either and no output is produced by the screen reader. I have been testing websites in accordance with WCAG for many years and very often find this problem. If aria-activedescendant is used, then there is still the problem that the browser does not automatically scroll the focused element into the visible area because the focus is elsewhere for the browser.

Another very common problem, which has nothing to do with aria-activedescendant, is that programmatically an invisible element gets the focus and visually a visible element located elsewhere (e.g. a native checkbox that is visually replaced by a self-designed checkbox so that the native checkbox is positioned outside the viewport via CSS). In this case, the screen reader output is correct (unless the native checkbox is hidden with aria-hidden, which I have also seen several times), but the visible checkbox is also not scrolled into the visible area by the browser, which is especially problematic for screen magnifiers or at 400% zoom.

From your other issue on the ARIA repo, it sounds like that is a bug they are investigating?

It is not a bug from the browser, but a violation of WCAG that is so common but so few are aware of - that it has even been in the W3C's ARIA best practice examples for many years, even though they are developed and extensively tested by accessibility experts. And that is exactly my argument: if even they make such a mistake, it should be clear that everyone else does too, and that is why it was always important to me to take this issue into account in WCAG 2.2, which I strongly advocated, but which was unfortunately hardly taken into account.

But all that has nothing to do with the discussion here. My only point in discussing the state was to emphasise that focus is a state and correct focus is important from an accessibility perspective, but that as with any other states (e.g. checkbox checked, button pressed, input field disabled) the state consists of 2 parts: the visual state and the programmatic state. And both states do not coincide automatically, but the developers themselves have to take care that visual state and programmatic state match. In the case of a button, it is sufficient to use aria-pressed and a visual marking that is not based exclusively on colour. With focus, however, there are 3 things to keep in mind:

• programmatic focus for screen readers
• programmatic focus in terms of size and position for screen magnifiers (unfortunately not covered by WCAG, see also SCs for users of screen magnifiers wcag3#175)
• visual focus

[alastc]

@JAWS-test - ok, but how does that factor into the question of: Can we use the term 'focus state' when saying that an item has focus?

[JAWS-test]

@alastc

ok, but how does that factor into the question of: Can we use the term 'focus state' when saying that an item has focus?

That doesn't have much to do with it. That's why I wrote:

But all that has nothing to do with the discussion here.

The whole discussion only arose because you thought focus was a visual and not a programmatic state:

That doesn't create an author requirement under 4.1.2.

I, on the other hand, think that focus is also a state that is relevant in 4.1.2, because if the visually focused element does not have focus programmatically, then assistive technology does not work. In this respect it has a little to do with the discussion, because it shows that state in the sense of focus is not so different from state in terms of other things (like pressed, selected, disabled).

[alastc]

I, on the other hand, think that focus is also a state that is relevant in 4.1.2, because if the visually focused element does not have focus programmatically, then assistive technology does not work.

But, I assume, if it is marked up with aria-activedescendant (or whatever is appropriate) then it would meet 4.1.2 as it is programmatically available? There might be a browser issue with not scrolling to the sub-component, but that's a separate thing.

So I think we are agreeing that focus is a state. I'm saying there's little or no impact on the use of 4.1.2, and I think the issue you're raising is a user-agent problem.

[JAWS-test]

@alastc

aria-activedescendant works for screen readers. Some screen magnifiers now understand it too. Browsers currently ignore it and it is debatable whether a browser should take aria-activedescendant into account when scrolling into view.

But what about hidden content that gets invisible focus while at the same time a visible element gets a focus indicator via CSS? I see a gap in the WCAG on this topic, because this is clearly the responsibility of the web author to ensure that the position and size of the focused object is correctly communicated. For technical reasons, neither the browser nor the screen magnifier can do this. There is no problem for screen readers, but a big problem when using the focus highlighting of the screen magnifier and when using zoom (regardless of whether zoom in the browser or zoom with the screen magnifier)

[alastc]

I see a gap in the WCAG on this topic, because this is clearly the responsibility of the web author to ensure that the position and size of the focused object is correctly communicated.

Ok, but I don't think that fits into focus-appearance or name/role value as they are currently defined. The sooner we put these to bed the sooner we can move onto other things.

It looks like w3c/wcag3#175 includes that point, so can we drop it from this thread please?

[alastc]

I think we need a summary of this discussion in order to make it digestible for anyone who hasn't been following along. How is this for a question framing, particularly for @bruce-usab:

---

WCAG 2.1 added the word "state" to the glossary for non-text contrast, which is a term that was already used by 4.1.2 Name/role/value.

Focus appearance (min + enh) uses the term "state" in the contrast bullet:

Contrast: The area has a contrast ratio of at least 3:1 between its colors in the focused and unfocused states.

Bruce is concerned that the usage in focus-appearance implies there is a requirement for authors to do something with the focus state in 4.1.2.

Alastair thinks that focus is a state, both visually and programmatically, but not one that authors need to worry about under 4.1.2.

If we were to change focus-appearance it would be to something like:

Contrast: The area has a contrast ratio of at least 3:1 between the colors when the component is focused and when not focused.

Should we:

• Update focus-appearance to avoid the word 'state';
• Leave it as it is;
• Something else

[bruce-usab]

That might be critical from your point of view, but that sentence finishes "or user interaction possibilities", so focus (and others) do fit within the definition (for both aria and wcag versions).

I do not disagree that, technically, the use of state word (in 2.4.11 and 2.4.12) fits the definition. It is not sufficiently consistent with the term as used in 4.1.2. The fact that one has to parse the definition so closely is evidence that 2.4.11 and 2.4.12 are shifting the meaning of the term.

I.e. a state can be defined by meta-data associated with a control, or it might be the interaction possibilities. Both are included in what 'state' means.

I am strongly of the opinion that we should reserve use of the word state in SC text to meta-data associated with a control. We use the word (more loosely) in definitions, and that is fine.

I'm saying there's little or no impact on the use of 4.1.2…

I respectfully disagree, since insufficiently consistent use of this key term could open 4.1.2 up to reinterpretation.

[bruce-usab]

Cross posting! Yes @alastc — that summarized the discussion. I very much prefer your alternative:

Contrast: The area has a contrast ratio of at least 3:1 between the colors when the component is focused and when not focused.

My +1 to your first bulleted option, update focus-appearance to avoid the word 'state'

[alastc]

Thanks Bruce, I was just testing out the question before adding to the survey.

[bruce-usab]

Thanks Alastair looks good to me!

Yes, I am concerned that the usage in focus-appearance implies there is a requirement for authors to do something with the focus state in 4.1.2.

I am more concerned that the usage in focus-appearance implies that 4.1.2. includes requirements for authors to programmatically expose all user interaction possibilities.

[patrickhlauke]

If we were to change focus-appearance it would be to something like:

Contrast: The area has a contrast ratio of at least 3:1 between the colors when the component is focused and when not focused.

pre-emptively saying that i could live with this, if it quells concerns about the use of state (which i personally didn't have a problem with, but i can see how thin-slicing the very technical aspect of what state really means, technically, can lead down apparent weird rabbit holes/loopholes)