Stateful Rules #1953
Comments
|
Another suggestion that was brought up was to include states and transitions in the Input Aspects of the rule. In this thread, I would make the proposals:
|
|
A couple of comments from our meeting:
|
Link has minimum contrast when in link, visited, focus, and hover statesApplicabilityAny element that matches the
ExpectationFor each test target, the highest possible contrast between the foreground colors and background colors is at least 4.5:1 or 3.0:1 for larger scale text, except if the test target is part of a text node that is purely decorative or does not express anything in human language. Comments:
Expandable element has valid aria-expanded attribute in expanded and collapsed statesApplicabilityAny element where interacting with the element toggles the visibility of child elements. Note: In the case where an element is not controlling its children, another rule for aria-controls would be needed. ExpectationWhen the element is expanded (children are visible) aria-expanded is set to true. When the element is collapsed (children are hidden), aria-expanded is set to false. Comments:
Expandable element is keyboard accessible in expanded and collapsed statesApplicabilityAny element where interacting with the element toggles the visibility of child elements. Note: In the case where an element is not controlling its children, another rule for aria-controls would be needed. ExpectationThe element for toggling between the expanded and collapsed states (altering the visibility of the children elements) can be activated using both the mouse and keyboard (i.e., mouse and keyboard event types) AssumptionAssumes another method for expanding the element is not available (e.g., an “Expand All” button at the top of the page) Comments:
Status Messages Available to User (Awful Title)ApplicabilityAny element whose activation causes a status message to be sent to the user. ExpectationStatus message element has See Sufficient Techniques for 4.1.3 Comments:
|
Status MessagesCompared to Link has minimum contrast when in link, visited, focus, and hover states and Expandable element has valid aria-expanded attribute in expanded and collapsed states, status messages has the unique challenge that there is no clear way to define the applicability since any element on the page could potentially cause a status message to appear. Below are several thoughts on how we might begin approaching this. Applicability - Specify event and element types as much as possibleAny Expectation - Requiring the tester to make an actionThe success criterion is automatically satisfied if initiating an event handler on the test target:
If initiating an event handler on the test target causes
Discussion Points:
|
|
In our last conversation, Wilco mentioned viewing Carlos' rule Error message describes invalid form field value since it has the hint of statefulness to it. Lets first review that rule and see how it was setup. Applicability - In short, a better version than what I had above. It grabs all HTML elements that meet the following conditions:
Which is basically to say, things that can take input. Then, for the expectation, Carlos does something clever, and uses the following wording to start each expectation:
With this wording, Carlos essentially isn't requiring that a form error exists (it might not if the form field is filled out correctly), but instead shifts the focus to if there is a form error, it must meet these expectations. This is a clever way to get to the error state without needing to tell the tester to trigger an error specifically (i.e., it implicitly handles the page state). The question then, is could we generalize this to the status messages problem above? Unfortunately, I'm not so sure. There are a couple key differences that make it difficult.
I'm honestly not sure if we can handle the change in context requirement without referencing state more explicitly than we have done in previous rules. It seems like we need to reference some type of interaction that causes a status message to appear. |
|
In our last discussion, we determined the need to have some sort of "Action Taken" heading or sub-heading in order to allow for the change of context requirement in the Status Messages. Below are possible attempts at how we might do this. The proposal below is to add a new section above the applicability called Preparatory Steps. This section holds one or more steps that lead up to the evaluation of the rule. Each step itself must include an applicability and an action. The applicability should objectively describe the elements that will be subject to specified action. Preparatory StepsStep 1Applicability: HTML element that has one of the following semantic roles Note: The list of applicable semantic roles is derived by taking all the ARIA 1.1 roles that:
Action: Any action that initiates a change in the applicable element (e.g., entering text, clicking, mouse drag) Applicability (copied from Carlos' error rule)This rule applies to any text that becomes visible after executing the preparatory steps and for which:
ExpectationThe test target (i.e., the element containing the newly visible text) must meet one of the following criteria
Questions
Error message describes invalid form field value (Rewrite)Preparatory StepsStep 1Applicability: HTML element that has one of the following semantic roles Note: The list of applicable semantic roles is derived by taking all the ARIA 1.1 roles that:
Action: Any action that initiates a change in the applicable element (e.g., entering text, clicking, mouse drag) Applicability (copied from Carlos' error rule)This rule applies to all form field error indicators on the current page after running the preparatory steps. ExpectationEach of the conditions below is satisfied by at least one form field indicator.
Questions
|
|
Some alternatives, trying to write this without new sections: Approach using "where-after" languageApplicabilityFor each [HTML element] containing [visible text], where this text appeared after the [activation] of an [HTML element] with one of the following rules:
Exception:
ExpectationThe test target (i.e., the element containing the newly visible text) must meet one of the following criteria
"Where-after" language for modalsOne of the more "procedural" tests I know is on returning focus to the modal trigger, after the modal is closed. We could write it like this: ApplicabilityFor each [HTML element] with an [aria-modal] attribute, where a [semantic] ExpectationEach test target receives [focus] after the modal is closed, except if the test target is not [included in the accessibility tree] |
|
Here are a couple examples of different test cases that we can use for discussion: Successful Form (Manual)<html lang="en">
<head></head>
<body>
<form id="example_form">
<label for="username">Username</label>
<input type="text" id="username"/>
<input type="submit" />
</form>
<p role="status" id="submit_message"></p>
</body>
<script>
let form = document.querySelector('#example_form');
let alert = document.querySelector('#submit_message');
let username = document.querySelector('#username');
form.addEventListener('submit', function(event) {
event.preventDefault();
if(username.value.length > 0) {
alert.textContent = "Success";
}
})
</script>
</html>Successful Form (Auto)<html lang="en">
<head></head>
<body>
<form id="example_form">
<label for="username">Username</label>
<input type="text" id="username"/>
<input type="submit" id="submit"/>
</form>
<p role="status" id="submit_message"></p>
<script>
// Handler for sending success notification
let form = document.querySelector('#example_form');
let username = document.querySelector('#username');
let submit = document.querySelector('#submit');
let alert = document.querySelector('#submit_message');
form.addEventListener('submit', function(event) {
event.preventDefault();
if(username.value.length > 0) {
alert.textContent = "Success";
}
});
// Automatically fill out form
setTimeout(() => {username.value = 'W3C_User';}, 1000);
setTimeout(() => {submit.click();}, 2000);
</script>
</body>
</html>Log Message Updates<html lang="en">
<head></head>
<body>
<div id="weatherlog" role="log">
<h4 id="logHeading">Weather Alerts</h4>
<ul id="log-entries">
</ul>
</div>
<script>
// Simulate weather updates
let weatherTypes = ['Sunny', 'Cloudy', 'Rainy'];
let logIndex = 0;
let logEntries = document.querySelector('#log-entries');
setInterval(() => {
let li = document.createElement('LI');
let timeOfEntry = `${((2 * logIndex) % 24).toString().padStart(2, '0')}:00`
li.textContent = `At ${timeOfEntry} it is ${weatherTypes[logIndex % 3]}`;
logEntries.prepend(li);
logIndex += 1;
}, 3000);
</script>
</body>
</html>A few questions that came up while making these examples:
|
Problem: Defining states and transitions between states can be very difficult due to the number of ways in which states can be implemented within web pages.
Aria spec definition of state:
In the past, in 2021, we decided that the states we cared about should be tied to CSS psuedo classes since they are an inherently objective measurement of state. https://www.w3.org/TR/selectors-4/#useraction-pseudos. This would include things like:
1. Focus
2. Hover
3. Visited (for links)
4. Active
5. Valid/Invalid (Only with html input specification)
6. Enabled/Disabled
7. Required
8. not Checked/Checked
9. And possibly more
As each of these only denotes a single state, we could also potentially expand the definition to include transitions between states (e.g., between not checked and checked), allowing us to test some user interactions with the page. However, the downside of this approach is that CSS-psuedo classes cannot represent all possible states or state changes of interest that might occur. A quote from our findings in early 2021:
So, to give examples, with just CSS Psuedo selectors we would struggle to handle the following scenarios:
1. An error message pops up as a result of bad form input (would only trigger :invalid if HTML5 input specs used)
2. A dropdown menu is expanded (initial element would be hovered and eventually active, but its difficult to tie that to the "expansion")
3. An image carousel rotates either due to human action or on a timer
So what can we do:
1. We can stay with CSS psuedo selectors as our measurement of state, understanding its gaps and working around them. Perhaps try to estimate the number of rules that would be difficult to write with this definition.
2. Expand our state definition to include states given by other W3C standards such as aria. For example, aria would (at least) include the states busy (loading) and expanded.
3. Allow subjective applicability that allows us to define new states as needed, likely requiring new glossary entry's.
Pros and Cons of 1&2
Pro - CSS psuedo selectors and other W3C have well-defined, and agreed upon definitions.
Con - ^^ cannot accurately represent all states, some of which may be very important.
Con - Rule understanding may be difficult. "Applicable States" will use CSS psuedo classes when they may not even be present within the rule.
Pros and Cons of 3:
Pro - Allows ability to define all states as needed.
Con - How to ensure accurate understanding by all users of the rules?
Con - Significant deviation from current ACT format which could cause problems.
The text was updated successfully, but these errors were encountered: