Skip to content

added 5.B Roles test for user controls #469

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 15 commits into from
Apr 1, 2024
33 changes: 27 additions & 6 deletions _baselines/05Controls.md
Original file line number Diff line number Diff line change
Expand Up @@ -12,7 +12,7 @@ order-number: 6

The purpose of this Baseline test is to check the following accessibility properties of user controls:
- Name
- Role (test not yet available)
- Role
- State
- Value

Expand All @@ -21,6 +21,9 @@ The purpose of this Baseline test is to check the following accessibility proper
- [User interface component](https://www.w3.org/TR/WCAG22/#dfn-user-interface-components) is a part of the content that is perceived by users as a single control for a distinct function. User interface components include form elements and links as well as components generated by scripts. This test uses the term "user controls" for brevity.
- The accessibility properties of the user control must be correct if the user control changes.
- Per [WCAG 2.2 Understanding SC 1.4.1 Use of Color](https://www.w3.org/WAI/WCAG22/Understanding/use-of-color) authors cannot set the visited state of links. The anchor element does not include a "visited" attribute; therefore the author has no ability to alter the state through an attribute setting. Exclude visited/unvisited state of links from this Baseline test.
- [Section 5.3.1 Abstract Roles of Accessible Rich Internet Applications (WAI-ARIA)](https://www.w3.org/TR/wai-aria/#abstract_roles) lists abstract roles that authors must not use in content.
- Valid ARIA Widget Roles are available [Accessible Rich Internet Applications (WAI-ARIA)](https://www.w3.org/TR/wai-aria/). A "widget" is a "discrete user interface object with which the user can interact. Widgets range from simple objects that have one value or operation (e.g., check boxes and menu items), to complex objects that contain many managed sub-objects (e.g., trees and grids)."
- In the Baseline Test instructions, where an ARIA role is identified, it is the first valid ARIA role attribute value.

### 5.A Test Procedure for Control Name

Expand Down Expand Up @@ -55,18 +58,36 @@ The purpose of this Baseline test is to check the following accessibility proper

<p id="5aTR">If any of the above checks fail, then Baseline Test 5.A-ControlName fails.</p>

### 5.B Test Procedure for Control Role (not available)
### 5.B Test Procedure for Control Role

**Baseline Test ID: 5.B-ControlRole

#### Identify Content
<p id="5bIC">Identify user controls for a distinct function that have an explicit role attribute <code>role="[value]"</code>. Examples include forms, links, and toggle controls.</p>

#### Test Instructions
<ol id="5bcTI">
<li id="5bTI-1">Check that the role of the user control is valid and appropriate for its function. [SC 4.1.2]
<ul>
<li>Only the roles listed in <a href="https://www.w3.org/TR/wai-aria/#widget_roles">Accessible Rich Internet Applications (WAI-ARIA) Section 5.3.2 Widget Roles</a> are valid for user controls.</li>
</ul>
</li>
</ol>

#### Test Results

<p id="5bTR">If any of the above checks fail, then Baseline Test 5.B-ControlRole fails.</p>

### 5.C Test Procedure for Control State

**Baseline Test ID:** 5.C-ControlState
#### Identify Content
<p id="5cIC">Identify user controls for a distinct function. Examples include changes to forms, links, and toggle controls. Exclude the visited/unvisited state of links.</p>
<p id="5cIC">Identify user controls for a distinct function that can be set by the user. Examples include forms, links, and toggle controls. Exclude the visited/unvisited state of links.</p>
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

"a distinct function that can be set by the user" doesn't fit neatly with links ... maybe " set or activated"?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I like adding "or activited"

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That phrasing was from SC 4.1.2 "...states, properties, and values that can be set by the user can be programmatically set".

I think "set" covers activated. Whether a link has been activated is excluded from this test.

I'll make some more edits to the test instructions. See if that helps.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@cliffbert and @drewnielson - please take another look.



#### Test Instructions
<ol id="5cTI">
<li id="5cTI-1">Check that the state of the user control is correct. Attributes such as <code>hidden</code>, <code>disabled</code>, and the use of <a href="https://www.w3.org/WAI/standards-guidelines/aria/">WAI-ARIA</a> to control component states must be used correctly.[SC 4.1.2]</li>
<li id="5cTI-1">Check that the state of the user control is correct. Attributes such as <code>hidden</code>, <code>disabled</code>, and the use of <a href="https://www.w3.org/WAI/standards-guidelines/aria/">WAI-ARIA</a> to control component states must be used correctly. [SC 4.1.2]</li>
<li id="5cTI-2">If the state of the user control changes with use of the application, check that the state of the user control is correct after a change of state. [SC 4.1.2]
<ul>
<li>Depending on the control, a change of state may be triggered by various actions, such as changing values or states of other components, toggling a function, entering data in the component, mouseover, etc.</li>
Expand All @@ -77,7 +98,7 @@ The purpose of this Baseline test is to check the following accessibility proper

#### Test Results

<p id="5cTR">If any of the above checks fail, then Baseline Test 5.2-ControlState fails.</p>
<p id="5cTR">If any of the above checks fail, then Baseline Test 5.C-ControlState fails.</p>

### 5.D Test Procedure for Control Value

Expand All @@ -94,7 +115,7 @@ The purpose of this Baseline test is to check the following accessibility proper

#### Test Results

<p id="5dTR">If any of the above checks fail, then Baseline Test 5.3-ControlValue fails.</p>
<p id="5dTR">If any of the above checks fail, then Baseline Test 5.D-ControlValue fails.</p>

### Advisory: Tips for streamlined test processes

Expand Down
1 change: 1 addition & 0 deletions _baselines/ChangeLog3.md
Original file line number Diff line number Diff line change
Expand Up @@ -16,6 +16,7 @@ Note: Minor punctuation, formatting and spelling changes not included.
| 2. Focus | Accessibility Requirements: SC 3.2.1 replaced "component" with "user interface component" per [WCAG 2.0 Errata](https://www.w3.org/WAI/WCAG20/errata/) Editorial Errata 9. |
| 3.A Non-Interference | Identify Content: added links to Baseline Tests. |
| 5. User Controls | Was Changing Content. New test to cover SC 4.1.2 more accurately. |
| 5.B Control Role | Added new test |
| 5.C Control State | Identify Content: excluded state of visited/unvisited links. |
| 6. Images | Limitations, Assumptions, Exceptions: removed "Equivalent descriptions for an image within page text could allow an image to be considered decorative. However, this does not necessitate removal of any accessible text attributes from the image." |
| 6. Images | Test Method Rationale: added "The image tests evaluate the images as they were coded to indicate whether they are meaningful or decorative, leaving that determination to the author of the content. However, there are certain scenarios as described in the tests where the author's determination would be incorrect." |
Expand Down