Skip to content

Significant updates for Test 5 #377

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
Oct 26, 2022
106 changes: 33 additions & 73 deletions _baselines/05Changing.md
Original file line number Diff line number Diff line change
Expand Up @@ -11,33 +11,28 @@ order-number: 6
### Test Method Rationale

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

### Limitations, Assumptions, or Exceptions

- [User interface component (as defined by WCAG)](https://www.w3.org/TR/WCAG21/#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.
- Examples of controls include changes to buttons, form labels, menu items, and links.
- User-initiated and automatic updates to the name and role of controls are covered in this test. User-initiated changes of state and value of controls are covered in this test. Changes to non-user controls (text, images, etc.) are not covered in this test.
- [User interface component (as defined by WCAG)](https://www.w3.org/TR/WCAG21/#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.

### 5.1 Test Procedure for Changes in Control Name
### 5.1 Test Procedure for Control Name

**Baseline Test ID:** 5.1-ChangedControlName

#### Identify Content
<p id="1IC">Identify changes (both user driven and automatic) in the functionality, appearance or label of user controls. </p>
<ul>
<li>Depending on the control, a change of name 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>
<li>Examples include entering a response in a form field for country changes the next form field's label from "state" to "province", selecting a control toggles its functionality from sorting ascending to descending, a link appends "Updated" to its name when the linked page is edited.</li>
</ul>
<p id="1IC">Identify user controls for a distinct function. Exclude forms and links as these are covered by [Baseline 10. Forms](../10Forms), [Baseline 14. Links](../14Links), respectively.</p>


#### Test Instructions
<ol id="1TI">
<li id="1TI-1">Perform an action to modify the name of the user control.</li>
<li id="1TI-2">Check that the combination of the accessible name and accessible description is not empty after the change. [SC 4.1.2]</li>
<li id="1TI-3">Check that the non-empty combination of the accessible name and accessible description describes the control's purpose after the change. [SC 1.1.1] For details on the computation of the accessible name and accessible description, references include:
<li id="1TI-1">Check that the combination of the accessible name and accessible description is not empty. [SC 4.1.2]</li>
<li id="1TI-2">Check that the non-empty combination of the accessible name and accessible description describes the control's purpose. [SC 4.1.2] For details on the computation of the accessible name and accessible description, references include:
<ul>
<li><a href="https://www.w3.org/TR/html-aam-1.0/#input-type-text-input-type-password-input-type-search-input-type-tel-input-type-url-and-textarea-element" target="_blank" rel="noopener">HTML Accessibility API Mappings 1.0 for text <code>input</code></a></li>
<li><a href="https://www.w3.org/TR/html-aam-1.0/#input-type-button-input-type-submit-and-input-type-reset" target="_blank" rel="noopener">HTML Accessibility API Mappings for <code>input</code> controls</a></li>
Expand All @@ -46,28 +41,36 @@ The purpose of this Baseline test is to check the following accessibility proper
<li><a href="https://www.w3.org/TR/html-aam-1.0/#other-form-elements" target="_blank" rel="noopener">HTML Accessibility API Mappings for Other Form Elements</a></li>
</ul>
</li>
<li id="1TI-3">If the name of the user control changes with use of the application, repeat the previous test steps and check that the accessible name is correct after the change.
<ul>
<li>Depending on the control, a change of name 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>
<li>Examples include entering a response in a form field for country changes the next form field's label from "state" to "province", selecting a control toggles its functionality from sorting ascending to descending, a link appends "Updated" to its name when the linked page is edited.</li>
</ul>
</li>
</ol>

#### Test Results

<p id="1TR">If any of the above checks fail, then Baseline Test 5.1-ChangedControlName fails.</p>
<p id="1TR">If any of the above checks fail, then Baseline Test 5.1-ControlName fails.</p>

### 5.2 Test Procedure for Control Role (not available)

### 5.2 Test Procedure for Control State
### 5.3 Test Procedure for Control State

**Baseline Test ID:** 5.2-ControlState
#### Identify Content
<p id="2IC">Identify user-initiated changes to the state of user controls. Examples include changes to buttons, form labels, menu items, and links.</p>
<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>
<li>Examples include a disabled "Submit" button is enabled when all required form fields are filled in, a link becomes visible after a user-initiated calculation completes, a check box changes from checked to unchecked, links that are hovered or visited.</li>
</ul>
<p id="3IC">Identify user controls for a distinct function. Examples include changes to forms, links, and toggle controls.</p>


#### Test Instructions
<ol id="2TI">
<li id="2TI-1">Check that the state of the user control is correct when in its default state. [SC 4.1.2]</li>
<li id="2TI-2">Attributes such as <code>hidden</code>, <code>disabled</code>, and the use of <a href="https://www.w3.org/WAI/standards-guidelines/aria/">ARIA</a> to control component states must be used correctly.</li>
<li id="2TI-3">Perform an action to modify the state of the user control.</li>
<li id="2TI-4">Check that the state of the user control is correct after a change of state. [SC 4.1.2]</li>
<li id="2TI-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/">ARIA</a> to control component states must be used correctly.[SC 4.1.2]</li>
<li id="2TI-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>
<li>Examples include a disabled "Submit" button is enabled when all required form fields are filled in, a link becomes visible after a user-initiated calculation completes, a check box changes from checked to unchecked, links that are hovered or visited.</li>
</ul>
</li>
</ol>

#### Test Results
Expand All @@ -78,67 +81,24 @@ The purpose of this Baseline test is to check the following accessibility proper

**Baseline Test ID:** 5.3-ControlValue
#### Identify Content
<p id="3IC">Identify controls that have a value that can be changed by a user. Examples include forms that accept user input to modify another component.</p>
<ul>
<li>Depending on the control, a change of value may be performed by entering a number, selecting from a list of options, etc.</li>
<li>Examples include adjusting a slider modifies a date range that is highlighted in a calendar, entering numbers in text fields determines a graph's data points, and selecting colors determines the appearance of links.</li>
</ul>
<p id="3IC">Identify controls that have a value that can be changed by a user. Examples include form fields and sliders.</p>

#### Test Instructions
<ol id="3TI">
<li id="3TI-1">Check that the value of the user control is correct when at its default value. [SC 4.1.2]</li>
<li id="3TI-2">Modify the value of the user control.</li>
<li id="3TI-1">Check that the value of the user control is correct. [SC 4.1.2]</li>
<li id="3TI-2">Modify the value of the user control. Depending on the control, a change of value may be performed by entering a number, selecting from a list of options, etc.</li>
<li id="3TI-3">Check that the value of the user control is correct after a change of value. [SC 4.1.2]</li>
</ol>

#### Test Results

<p id="3TR">If any of the above checks fail, then Baseline Test 5.3-ControlValue fails.</p>
<!--
#### Identify Content
<p id="1IC">Identify changes in presented content (both user-driven and automatic). Examples include changes to images, navigation trees, data table sort controls, automatic information updates, form elements, revealed content, etc.</p>
<ul>
<li>It may be necessary to use the mouse to determine whether state changes occur on hover or on click.</li>
<li>Depending on the component, 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>
</ul>
--
#### Test Instructions
<ol id="1TI">
<li id="1TI-1">Check that the page provides a notification of the change in content programmatically. [SC 4.1.2]
<ul>
<li>Programmatic event notifications include alert dialogs, focus shifts to the content that changed, and ARIA live regions.</li>
</ul>
</li>
<li id="1TI-2">For each change in content, check that the combination of name, role, state, and value of the changed content is accurate. [SC 4.1.2]
<ol>
<li id="1TI-2i">Name: the name is accurate after a change.
<ul>
<li>Apply the <a href="https://www.w3.org/TR/html-aam-1.0/#accessible-name-and-description-computation">accessible name and description computation</a>, if applicable.</li>
</ul>
</li>
<li id="1TI-2ii">Role: the role accurately describes the purpose of the element after a change, if applicable.
<ul>
<li>Consider ARIA role, element type, and other descriptive text.</li>
</ul>
</li>
<li id="1TI-2iii">State: the state of the element is accurate after a change, if applicable.
<ul>
<li>Evaluate ARIA and element-specific attributes (e.g., <code>&#060;option selected=”true”&#062;</code>).</li>
</ul>
</li>
<li id="1TI-2iv">Value: the value is updated after a change, if applicable.</li>
</ol>
</li>
</ol>
--
#### Test Results
<p id="1TR">If any of the above checks fail, then Baseline Test 5.1-ChangeContent fails.</p>
-->

### Advisory: Tips for streamlined test processes

- Changes to controls may also include changes in color to convey information. If so, this test should check that the information is programmatically determinable. If color is used as the only visual means of conveying information (or changes in information), then the content would fail to meet SC 1.4.1 Use of Color (addressed in [Baseline 7. Sensory Characteristics](../07Sensory)).
- The default accessible name and accessible description of user controls (prior to change) are tested in other Baseline tests, such as [Baseline 10. Forms](../10Forms), [Baseline 14. Links](../14Links). It may be helpful to perform the test for Changes in Control Name with those tests.
- This test may require interaction with controls to assess changes in name, role, state, value. For this test, interaction may be performed with a mouse and/or by keyboard.
- The accessible name and accessible description of some user controls are tested in other Baseline tests, such as [Baseline 10. Forms](../10Forms), [Baseline 14. Links](../14Links). For user controls that have dedicated Baseline Tests, please map to those tests for accessible name instead of 5.1-ControlName.
- This test may require interaction with controls to assess changes in name, role, state, value. Interaction instructions such as a test plan may be helpful.

#### WCAG 2.0 Techniques
- [F20: Failure of Success Criterion 1.1.1 and 4.1.2 due to not updating text alternatives when changes to non-text content occur](https://www.w3.org/WAI/WCAG21/Techniques/failures/F20.html)
2 changes: 1 addition & 1 deletion _baselines/10Forms.md
Original file line number Diff line number Diff line change
Expand Up @@ -49,7 +49,7 @@ Review form instructions for completeness and programmatic association to their
#### Test Instructions
<ol id="1TI">
<li id="1TI-1">Check that the combination of the accessible name and accessible description is not empty. [SC 4.1.2]</li>
<li id="1TI-2">Check that the non-empty combination of the accessible name and accessible description describes the form's purpose. [SC 1.1.1] For details on the computation of the accessible name and accessible description, references include:
<li id="1TI-2">Check that the non-empty combination of the accessible name and accessible description describes the form's purpose. [SC 4.1.2] [Form components that include non-text content should also map to SC 1.1.1.] For details on the computation of the accessible name and accessible description, references include:
<ul>
<li><a href="https://www.w3.org/TR/html-aam-1.0/#input-type-text-input-type-password-input-type-search-input-type-tel-input-type-url-and-textarea-element" target="_blank" rel="noopener">HTML Accessibility API Mappings 1.0 for text <code>input</code></a></li>
<li><a href="https://www.w3.org/TR/html-aam-1.0/#input-type-button-input-type-submit-and-input-type-reset" target="_blank" rel="noopener">HTML Accessibility API Mappings for <code>input</code> controls</a></li>
Expand Down
2 changes: 1 addition & 1 deletion _baselines/ChangeLog3.md
Original file line number Diff line number Diff line change
Expand Up @@ -11,7 +11,7 @@ Note: Minor punctuation, formatting and spelling changes not included.
|--------------------|-----------------------|
| Multiple Baseline Tests | Test Instructions: corrected outline numbering, added missing requirement mappings |
| 3.1 Non-Interference | Identify Content: added links to Baseline Tests |
| 5. Changing Content | Significant changes to this test to cover SC 4.1.2 more accurately. Name changed to Test 5. User Controls. |
| 5. Changing Content | Significant changes to this test to cover SC 4.1.2 more accurately. Name of test changed to 5. User Controls. |
| 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.1 Meaningful Image | Instruction 2: removed mapping to 1.1.1 and 4.1.2 |
| 7. Sensory Characteristics | Advisory: corrected first bullet to remove "must also provide textual cues" |
Expand Down