Stateful Applicability and Expectation

[tbostic32]

As we look to update the rules format to include state and subjective applicability, I wanted to create a single issue to connect all of the information/discussion that has occurred on these subjects so I can easily find and reference them.

• ACT_States_draft.txt Contains the results from a discussion in early 2021 about how we might handle state within rules. The gist at the time was to rely on css psuedo classes since they were objective measures of states and transitions whereas JavaScript DOM manipulation were not. However, as we will likely be starting to allow subjective applicabilities, we may need to revisit this state definition.
• #1511 Shows possibly the earliest issue with thoughts about how to incorporate state.
• #1010 and #1455 show possible implementations using the decisions made in the states draft above.

These will be good resources to get us onto the same page with what has been done. I think a few open questions that we still need to answer are:

1. What rules will need state? We have some rules that implicitly use state like Block of repeated content is collapsible where it could have included states for the content being open and closed and the expectation was that a transition existed. However, it instead easily abstracts this to a higher level in the expectation to ignore state and transitions all together:

there exists an instrument to make all nodes in this block not visible; and there exists an instrument to remove all nodes in this block from the accessibility tree.

2. Are there rules that don't currently use state that would be more easily explained if we were to use state?
3. If we allow subjective applicability statements, that opens the possibility of using JavaScript manipulations (e.g., "menu expanded") as state and state transitions definitions. How do we constrain this language to improve cohesiveness between rules?

[tombrunet]

Some quick comments on the draft:

• We found that transitions also need to be addressed, since the "State A" of an element is often a concern only when it changes, that is, it transitions from State A to some State B.

I'd argue this is less about the transition and more about it not being the default state. If an input is focused automatically on page load, I need to be more thoughtful about testing the non-focused state for that input. I wouldn't say I'm concerned about the transition as much as testing the non-default states.

there are states more important to test than others

Regarding the hover / non-hover state being important. I agree, but with a catch. If I hover something and it completely disappears, that's certainly important. If I hover a section and the foreground or background changes so that a large block of text is hard to read, that's also important. But, the more common case is a link that's barely compliant and the highlight pushes it just out of range. I'm sure we can make the technical argument that it fails, but the pointer obstructing the text is probably more of an issue than the text being slightly out of range - and I don't think I've ever heard an argument for less obstructive mouse pointers. The net is, there's likely some additional qualification needed in this area.

[tbostic32]

From the conversation we had on June 2, 2022, there seemed to be consensus that the current formulation of state in the applicability was overly confusing and perhaps more technical than it needed to be. To try to get a better consensus, I have drafted several different possible formulations below that I hope will serve as a starting point for our future conversations. The formulations intentionally range from more vague/less technical to less vague/very technical to hopefully help us determine the tradeoffs for each approach and which we think hits the "sweet spot" of being implementable, easy to understand, and increase tool harmonization.

Apologies that these are very rough and pay little attention to detail. My intention is to determine the pros and cons to different approaches without worrying about the minutiae.

Rule: Inline link in paragraph is distinguishable

Applicability: Same as in current rule proposal Expectation: Same as in current rule proposal. Must be true for each state

Up to the Implementer

Applicable States: All states for which the link has a unique hue value. Note: This means if more than one state has the same hue value, only one of the states with that hue value needs to be tested.

Specifying States to Test

Applicable States: Test the link in its default state and then when it matches one or more of the css pseudo class selectors listed below:

• :focus
• :hover
• :visited
• :any-link and :link
• :any-link and :visited

Specifying When Not to Test

Test the link in all states except when:

• The hue of the link is currently changing, such as during an animation
• The hue of the surrounding text is changing
• The position of the link is moving?

(Fake) Rule: aria-expanded set correctly for expandable elements

Applicability: Any element which may be activated to reveal additional content

Specifying States

Applicable States: An expandable element only has two states:

• Collapsed : Any additional content is hidden from the user
• Expanded: Any additional content is available to the user

This formulation integrates the state into the expectation directly. Expectation: aria-expanded is set to false when the element is collapsed or is set to true when the element is expanded

Alternate Formulation: Each expectation has a set of states that the expectation must be true for. Aggregated together, the expectations must cover every state given in the applicability. Expectation 1: aria-expanded is set to false Expectation 1 States: The element is collapsed

Expectation 2: aria-expanded is set to true Expectation 2 States: The element is expanded

Specifying Transitions:

Applicable Transitions: Anytime the expandable element transitions from the collapsed to the expanded state or from the expanded to the collapsed state.

Expectation 1: Aria-expanded is set to true within xx seconds of the element being expanded.

Expectation 1 States and Transitions: Expandable element going from closed to open

Expectation 2: Aria-expanded is set to false within xx seconds of the expandable list being collapsed.

Expectation 2 States and Transitions: Expandable element going from open to closed.

Specifying When Not to Test

????

(Fake) Rule Error text description exists for empty required fields

Applicability: Any input field that is required to submit the form

Up to the Implementer

Applicability Any state of text input for which the filed would be in an error state.

Expectation: A text description of the error exists in at least one state for each form field which has data requirements (either required, format, range, etc.)

Specifying States

Applicability: The input field should be tested in the following states:

• While entering text into the input field (onchange)
• After leaving the input field (onblur)
• After submitting the form Error message could be client-side, alert, after form submission, on saving a form(?), etc. How to include all simply?

Expectation A text description of the error exists in at least one of the applicable states.

Specifying When Not To Test

Applicability The input field should be tested in all states except when:

• The input field is empty
• The input field meets the field requirements

Expectation ????

[tbostic32]

State Transition Definition

In some of the previous discussions above we began to talk about state transitions without really defining what it means. In this comment I want to talk a little bit about what a state transition is and give a few examples of how it may apply to our work with ACT rules.

When we think about the state of a web page, we typically think of the content and functionality of a web page at a given instance in time (see WCAG state definition in Glossary.. A state transition can be thought of as a pair of states where we move from the first state to the second state through some "action". Importantly, the "action" causing the transition could be active, like clicking a button or entering text, or could be passive like a state transition occurring after some period of time. Additionally, the transition may be instantaneous or take a long period of time, for example a menu that expands with no animation or a search which takes multiple seconds to return results.

Below are a few examples of different types of state transitions that we should discuss and determine how or even if we would want to consider them for inclusion in our testing.

Examples

3.3.1 (Error Identification) Entering text into an input field triggers an automatic validation error (e.g., maybe the input format was not followed correctly) resulting in a form field error indicator

• Do we need to consider the state transition?
• Could any accessibility violations occur during the transition?
• Is it possible to test the before and after states independently and get accurate results (i.e., no need to consider transition)?

4.1.3 (Status Messages) Triggering a search function causes a loading icon to appear. After several seconds the results are returned and announced to the user.

• Do we need to consider the state transition?
• Could any accessibility violations occur during the transition?
• Is it possible to test the before and after states independently and get accurate results (i.e., no need to consider transition)?

2.1.1 (Keyboard) Using the mouse to click on an element causes a menu to expand (transitioning from the closed to expanded state). This same transition should occur when the element is activated using a keyboard. In this case, are we just testing that the transition exists for both or is there an alternative testing scheme?

• Do we need to consider the state transition?
• Could any accessibility violations occur during the transition?
• Is it possible to test the before and after states independently and get accurate results (i.e., no need to consider transition)?

2.3.x (Seizures and Physical Reactions) As we move from one state to another, there is the chance that seizure-inducing flashes could occur. Perhaps the most tractable approach would be to say that flashes never occur while operating on a web page. However, does that do much for harmonizing testing strategies?

• Do we need to consider the state transition?
• Could any accessibility violations occur during the transition?
• Is it possible to test the before and after states independently and get accurate results (i.e., no need to consider transition)?