Skip to content
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

Update act-rules-format.md for mapping secondary accessibility requirements #531

Merged
merged 55 commits into from
Jul 10, 2023
Merged
Changes from 42 commits
Commits
Show all changes
55 commits
Select commit Hold shift + click to select a range
d06205a
Update act-rules-format.md
kengdoj Jul 15, 2022
ae658ba
Update act-rules-format.md
kengdoj Jul 15, 2022
5c8814d
Update act-rules-format.md
kengdoj Jul 15, 2022
ca118f3
Update act-rules-format.md
kengdoj Jul 28, 2022
faca230
Update act-rules-format.md
kengdoj Jul 28, 2022
c6a0bcd
Update act-rules-format.md
kengdoj Jul 28, 2022
3a42ca5
Update act-rules-format.md
kengdoj Aug 10, 2022
8aab815
Update act-rules-format.md
kengdoj Aug 25, 2022
4dc257e
Update act-rules-format.md
kengdoj Aug 25, 2022
4149fc8
Update act-rules-format.md
kengdoj Aug 25, 2022
94e3ddb
Update act-rules-format.md
kengdoj Aug 25, 2022
1edfa96
Update act-rules-format.md
kengdoj Aug 25, 2022
d78ced1
Update act-rules-format.md
kengdoj Aug 25, 2022
50e6f96
Update act-rules-format.md
kengdoj Aug 25, 2022
ad065fa
Update act-rules-format.md
kengdoj Aug 25, 2022
428c777
Update act-rules-format.md
kengdoj Aug 25, 2022
62ad17a
Update act-rules-format.md
kengdoj Aug 25, 2022
3d83ed9
Update act-rules-format.md
kengdoj Aug 25, 2022
7850c84
Update act-rules-format.md
kengdoj Aug 25, 2022
c6604c6
Update act-rules-format.md
kengdoj Aug 25, 2022
3321f8f
Update act-rules-format.md
kengdoj Aug 25, 2022
f1d4051
Update act-rules-format.md
kengdoj Aug 25, 2022
c2cb8bd
Update act-rules-format.md
kengdoj Aug 25, 2022
b59f9c5
Update act-rules-format.md
kengdoj Aug 25, 2022
ca1fde0
Update act-rules-format.md
kengdoj Aug 25, 2022
0463d8a
Update act-rules-format.md
kengdoj Aug 25, 2022
a54100d
Update act-rules-format.md
kengdoj Aug 25, 2022
6b3314e
Update act-rules-format.md
kengdoj Sep 7, 2022
d1c0d9e
Update act-rules-format.md
kengdoj Sep 22, 2022
9518e6d
Update act-rules-format.md
kengdoj Sep 22, 2022
052858c
Update act-rules-format.md
kengdoj Sep 22, 2022
1852468
Update act-rules-format.md
kengdoj Sep 22, 2022
46152cc
Update act-rules-format.md
kengdoj Oct 6, 2022
f268da2
Update act-rules-format.md
kengdoj Nov 17, 2022
a3fdbc7
Update act-rules-format.md
kengdoj Nov 29, 2022
e701f60
Update act-rules-format.md
kengdoj Dec 6, 2022
6da8df5
Update act-rules-format.md
kengdoj Dec 6, 2022
83cfcfb
Update act-rules-format.md
kengdoj Dec 6, 2022
2e1418c
Update act-rules-format.md
kengdoj Dec 6, 2022
be78cdb
Update act-rules-format.md
kengdoj Dec 6, 2022
6173784
Update act-rules-format.md
kengdoj Dec 6, 2022
e6af050
Apply suggestions from code review
kengdoj Dec 6, 2022
639b64b
Apply suggestions from code review
kengdoj Dec 6, 2022
47b5c37
Update act-rules-format.md
kengdoj Dec 6, 2022
9aeb2e7
Update act-rules-format.md
kengdoj Dec 6, 2022
40d3449
Update act-rules-format.md
kengdoj Dec 6, 2022
fb80828
Update act-rules-format.md
kengdoj Dec 6, 2022
0f6dea9
Update act-rules-format.md
kengdoj Dec 6, 2022
b6ec42b
Update act-rules-format.md
kengdoj Dec 6, 2022
17350fe
Update version & editors
WilcoFiers Jan 18, 2023
ed0f372
Creates subdirectory
daniel-montalvo Jun 20, 2023
6fb98a9
Creates subdirectory
daniel-montalvo Jun 20, 2023
0124152
Merge branch 'main' into kengdoj-secondaryaccreqs
daniel-montalvo Jun 20, 2023
c9b2608
Bikeshed cleanup
daniel-montalvo Jun 20, 2023
6b9c187
Update act-rules-format/act-rules-format.bs
kengdoj Jul 6, 2023
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
97 changes: 92 additions & 5 deletions act-rules-format.md
Original file line number Diff line number Diff line change
Expand Up @@ -160,26 +160,36 @@ Refer to the [Rule Type](#rule-types) section for detailed definitions of the ru
Accessibility Requirements Mapping {#accessibility-requirements-mapping}
------------------------------------------------------------------------
kengdoj marked this conversation as resolved.
Show resolved Hide resolved

When an ACT Rule is designed to test conformance to one or more [=Accessibility requirements documents=], the rule <em class="rfc2119">must</em> list all [=accessibility requirements=] from those documents that are not satisfied when one or more of the [=outcomes=] of the rule is `failed`. For example, when designing a rule for WCAG that tests if image buttons have alternative text, the rule maps to success criteria 1.1.1 Non-text content, and 4.1.2 Name, Role, Value. That ACT Rule will list both success criteria in its accessibility requirements mapping.
When an ACT Rule is designed to test conformance to one or more [=Accessibility requirements documents=], the rule <em class="rfc2119">must</em> list all [=accessibility requirements=] from those documents that are not satisfied when one or more of the [=outcomes=] of the rule is `failed`. The rule <em class="rfc2119">should</em> list accessibility requirements that could be not satisfied when the rule outcome is failed. There are two types of accessibility requirements:
Copy link
Collaborator

Choose a reason for hiding this comment

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

Is this a "should" or a "may"?

kengdoj marked this conversation as resolved.
Show resolved Hide resolved
- Conformance Requirements
Copy link
Collaborator

Choose a reason for hiding this comment

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

Suggested change
- Conformance Requirements
- [Conformance Requirements](#conformance-requirements)

kengdoj marked this conversation as resolved.
Show resolved Hide resolved
- Secondary Requirements
Copy link
Contributor

Choose a reason for hiding this comment

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

Should these be links to the corresponding sections?

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

yes, links will be added.

kengdoj marked this conversation as resolved.
Show resolved Hide resolved

Each [=accessibility requirement=] in the mapping <em class="rfc2119">must</em> include the following:

1. either the name, title, identifier or summary of the accessibility requirement, and
2. the name of the [=accessibility requirements document=], and
3. a link or reference to the [=accessibility requirements document=] if one exists, and
4. the conformance level associated with the accessibility requirement, if one exists.

4. the conformance level associated with the accessibility requirement, if one exists, and
5. whether the requirement is a conformance requirement or a secondary requirement.
Copy link
Collaborator

@WilcoFiers WilcoFiers Dec 12, 2022

Choose a reason for hiding this comment

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

Suggested change
5. whether the requirement is a conformance requirement or a secondary requirement.
5. whether the requirement is a conformance requirement or a secondary requirement.
<div class="note">
<p><strong>Editors note:</strong> The ACT Task Force is looking for feedback on the definitions of conformance requirement and secondary requirements. These are currently defined based on author intent, which is not necessarily as strict as many other definitions in this document. One possible solution could be to use "requirement strictness". Requirement B is considered stricter than A if every test subject that does not satisfy A also does not satisfy B, but that A can be satisfied when B is not satisfied.</p>
<p>The terms <em>conformance requirement</em> and <em>secondary requirements</em> are not yet finalized. The ACT Task Force is looking for alternative terms that could be more descriptive.</p>
</div>

Copy link
Collaborator

Choose a reason for hiding this comment

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

You propose "requirement strictness" as a solution in the editors notes but I don't see how that would solve the problems seen in scenarios 2 and 4. I think it could be part of the solution, but could not be the whole solution.

As I have re-read the scenarios the "rules of thumb" for measuring them seems to be the below for me. I don't think you could wrap 2 and 3 into requirement strictness.

  1. "Requirement Strictness" - Handles scenarios 1 and 3
  2. "Passed = satisfied outcome, failed $\neq$ failed outcome" - Scenario 2
  3. "Applicable to only some, but not all, passed and failed test cases" - Scenario 4

Copy link
Collaborator

Choose a reason for hiding this comment

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

You may be right. I haven't looked into it yet. It's something to discuss I think.


### Outcome Mapping ### {#outcome-mapping}
For each accessibility requirement in the mapping, an ACT Rule <em class="rfc2119">must</em> indicate what the [=outcomes=] of the rule mean for satisfying an accessibility requirement for that [=test subject=].
Copy link
Collaborator

Choose a reason for hiding this comment

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

What is the outcome mapping for secondary requirements like?

kengdoj marked this conversation as resolved.
Show resolved Hide resolved

#### Conformance Requirements ### {#conformance-requirements}

When a rule is designed to test a specific accessibility requirement, the accessibility requirement is mapped as a Conformance Requirement when both of the following conditions are true:

For each accessibility requirement in the mapping, an ACT Rule <em class="rfc2119">must</em> indicate what the [=outcomes=] of the rule mean for satisfying that accessibility requirement for that [=test subject=]. When one or more of the outcomes for a test target is `failed`, the accessibility requirements are <dfn>not satisfied</dfn> for the test subject. When all of the outcomes are `passed` or `inapplicable`, the accessibility requirements could be <dfn>satisfied</dfn>, or <dfn>further testing is needed</dfn>. Rules that can be used to determine if an accessibility requirement is *satisfied* are called <dfn>satisfying tests</dfn>.
- Failed Outcomes: When one or more of the outcomes for a test subject is `failed`, the accessibility requirement is <dfn>not satisfied</dfn> for the test subject, and
- Passed or Inapplicable Outcomes: When all of the outcomes are `passed` or `inapplicable` for a test subject, the accessibility requirement could be <dfn>satisfied</dfn> or <dfn>further testing is needed</dfn> for the test subject.

Rules that can be used to determine if an accessibility requirement is *satisfied* are called <dfn>satisfying tests</dfn>.
kengdoj marked this conversation as resolved.
Show resolved Hide resolved
kengdoj marked this conversation as resolved.
Show resolved Hide resolved
kengdoj marked this conversation as resolved.
Show resolved Hide resolved
Copy link
Contributor

Choose a reason for hiding this comment

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

Why do we need this definition, and why is it mixed with the definition of "Conformance Requirements"?

Copy link
Collaborator

Choose a reason for hiding this comment

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

This is from the current version of the spec. We can't take it out. The reason it needs to be here is that secondary requirements cannot be satisfying tests.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Suggested change
Rules that can be used to determine if an accessibility requirement is *satisfied* are called <dfn>satisfying tests</dfn>.
Rules that can be used to determine if an accessibility requirement is *satisfied* are called <dfn>satisfying tests</dfn>. When all of the outcomes are `passed`, the accessibility requirement is <dfn>satisfied</dfn> for the test subject.


<div class=note>
<p>**Note:** In the [Web Content Accessibility Guidelines](https://www.w3.org/WAI/standards-guidelines/wcag/) [[WCAG]], success criteria do not evaluate to `passed`, `failed` or `inapplicable`. Rather they can be *satisfied* (or not). (See the [WCAG 2.1 definition: satisfies a success criterion](https://www.w3.org/TR/WCAG21/#dfn-satisfies).) If a success criterion is *not satisfied*, a web page can only conform if there is a conforming alternative version, as described in [WCAG 2.1 Conformance Requirement 1](https://www.w3.org/TR/WCAG21/#cc1).</p>
</div>

<aside class=example>
<header>Example accessibility requirements mapping for a rule that tests if an image button has an accessible name:</header>
<header>Example accessibility requirements mapping for a rule that was designed to test if an image button has an accessible name maps success criteria 1.1.1 Non-text content and 4.1.2 Name, Role, Value as conformance requirements:</header>
<blockquote><ul>
<li>
[Success criterion 1.1.1: Non-text content](https://www.w3.org/TR/WCAG21/#non-text-content)
Expand All @@ -206,6 +216,83 @@ For each accessibility requirement in the mapping, an ACT Rule <em class="rfc211
</ul></blockquote>
</aside>

#### Secondary Requirements ####
kengdoj marked this conversation as resolved.
Show resolved Hide resolved

A secondary accessibility requirement is a requirement that is correlated with the rule, but for which the rule is not designed to test. The outcome of the rule impacts the result of the accessibility requirements, but the rule is not intended to test the conformance of that requirement. This correlation often results in some test cases not satisfying these secondary accessibility requirements.
kengdoj marked this conversation as resolved.
Show resolved Hide resolved

kengdoj marked this conversation as resolved.
Show resolved Hide resolved
When only one of the conditions is true or both conditions are only sometimes true for an accessibility requirement, the rule <em class="rfc2119">may</em> map the accessibility requirement as Secondary. When an ACT rule maps to a Secondary requirement, it <em class="rfc2119">must</em> include an explanation of why that requirement is Secondary in the Background section of the rule.
kengdoj marked this conversation as resolved.
Show resolved Hide resolved

kengdoj marked this conversation as resolved.
Show resolved Hide resolved
Copy link
Contributor

Choose a reason for hiding this comment

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

With the current definition, 2.4.9 is still a Conformance Requirement for any 2.4.4 rule.
I think we need to add something like:

When requirement B is a stricter version of requirement A, and requirement A is a Conformance requirement; then the rule must list requirement B as a Secondary requirement (not as a Conformance requirement).

With "stricter version" being:

Requirement B is a stricter version of requirement A if every test subject that does not satisfy A also does not satisfy B.


kengdoj marked this conversation as resolved.
Show resolved Hide resolved
Some scenarios when a rule will have Secondary requirements include:

kengdoj marked this conversation as resolved.
Show resolved Hide resolved
**Scenario 1**: only the "Failed Outcomes" are true for the requirement

A rule was designed to test a minimum accessibility requirement and there exists a stricter requirement. In this scenario, the rule’s failed outcomes can determine that the stricter accessibility requirement is not satisfied, and the rule’s passed outcomes may not determine that the stricter requirement is satisfied. It is possible that the accessibility requirement may be not satisfied when the rules outcomes are passed. The stricter requirement is a Secondary requirement.

<aside class=example>
<header>Example: a rule that tests if text has minimum contrast</header>
<blockquote>This rule was designed to test Success Criterion 1.4.3 Contrast Minimum (AA). A stricter requirement, Success Criterion 1.4.6 Contrast (Enhanced) (Level AAA), will be not satisfied when the rule outcome is failed, and may be not satisfied when the rule outcomes are passed. This rule’s mapping:
Copy link
Contributor

Choose a reason for hiding this comment

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

I'm afraid that doesn't match the definition:

  • Passed or Inapplicable Outcomes: When all of the outcomes are passed or inapplicable, the accessibility requirement could be satisfied or further testing is needed.

Now, when the rule passes, both 1.4.3 and 1.4.6 may be not satisfied on the page. For 1.4.3 because it also applies to images of text and the rule doesn't; for 1.4.6 because of images of text and the higher threshold. So this condition is true for both (and so is the "Failed Outcomes" condition).

I definitely think the idea is good but I don't think the definition is good yet 😕
I think the difference we need to make is between "all outcomes are passed => the requirement may be satisfied or not satisfied for the test subject (=classical further testing is needed)" versus "an outcome is passed => the requirement may be satisfied or not satisfied for this test target".

The first one describes the relation of the rule for both 1.4.3 and 1.4.6, but the second only describes it for 1.4.6.
I could not find a way to describe the relation we want for 1.4.3 without breaking elsewhere (e.g. "an outcome is passed => the requirement is satisfied for this test target" wouldn't describe the mapping of "image has accessible name" to 1.1.1.

Anyway, I feel that with the current condition on Passed outcome, 1.4.6 is still a conformance mapping for such a rule, which is not what we want.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

@Jym77 - there have been updates since you left this and the other comments. Do the latest changes address your concerns?

Copy link
Contributor

Choose a reason for hiding this comment

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

@kengdoj Yes, I think it works.
I'm not a huge fan of having the difference put solely on the intention of the rule author (the rule is/is not designed to test the requirement), but I guess it does work.

Copy link
Collaborator

Choose a reason for hiding this comment

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

That's not the only difference. A requirement can only be a conformance requirement if when the rule fails, the requirement is not satisfied.

Copy link
Contributor

Choose a reason for hiding this comment

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

But for this case (out of the 4 scenarios), when the rule fails, 1.4.6 is not satisfied.
So the difference between 1.4.3 and 1.4.6 on this rule is solely on the intention of the rule author.

When an ACT Rule is designed to test conformance to one or more [=Accessibility requirements documents=], the rule must list all [=accessibility requirements=] from those documents that are not satisfied when one or more of the [=outcomes=] of the rule is failed.

This states that 1.4.6 must be listed as a requirement (either conformance or secondary).

When a rule is designed to test a specific accessibility requirement, the accessibility requirement is mapped as a Conformance Requirement when both of the following conditions are true:

(emphasise mine)
This state that 1.4.6 is not necessarily a "conformance requirement" because the rule "is designed" to test 1.4.3.

So, in this case, the only difference is the author intention. (for the other 3 scenarios, it is also the mapping, I agree).
There is the suggestion I made and the note that has been added that we could use strictness to make sure that in this case 1.4.6 can only be a secondary requirement. I would prefer to have it normatively since it would avoid the discussions whether 1.4.6 should be "conformance" or "secondary" in this case. But it does work as it is now, and maybe it is good enough to leave it like that rather than add complexity…

<ul>
<li>Conformance Requirement: Success Criterion 1.4.3 Contrast (Minimum)</li>
<li>Secondary Requirement: Success Criterion 1.4.6 Contrast (Enhanced)</li>
<ul><li>Background Section: Success Criterion 1.4.6 is mapped as a Secondary requirement because the SC may be <dfn>not satisfied</dfn>when the rule’s outcomes are `passed`. </li></ul>
</ul>
</blockquote>
</aside>

**Scenario 2**: only the "Passed or Inapplicable Outcomes" are true for the requirement
<ol style="list-style-type: lower-alpha">
<li>A rule was designed to test a specific type of solution for an accessibility requirement, but the rule does not cover all solutions that can be used to meet the requirement. In this scenario, the rule’s failed outcomes cannot determine that an accessibility requirement is not satisfied because further testing is needed. The rule’s passed outcomes can determine that an accessibility requirement is satisfied. The accessibility requirement is a Secondary requirement.</li>

<aside class=example>
<header>Example: a rule that tests if a focusable element has no keyboard trap via standard navigation</header>
<blockquote>This rule was designed to test for a specific solution that can be used to meet Success Criterion 2.1.2: No Keyboard Trap. The rule does not test for other possible solutions, such as the use of non-standard navigation, so its failed outcomes cannot determine that the accessibility requirement is <dfn>not satisfied</dfn>. This rule’s mapping:
<ul>
<li>Secondary Requirement: Success Criterion 2.1.2: No Keyboard Trap</li>
<ul><li>Background Section: This rule tests for one solution that can meet Success Criterion 2.1.2. SC 2.1.2 is mapped as a Secondary requirement because other solutions (such as use of non-standard navigation to exit a keyboard trap) can be used to meet this SC that are not tested by this rule.</li></ul>
kengdoj marked this conversation as resolved.
Show resolved Hide resolved
</ul>
</blockquote>
</aside>

<li>A rule was designed to test an accessibility requirement and there exists a less strict accessibility requirement. In this scenario, the rule’s passed outcomes can determine that the less strict requirement is satisfied, and the rule’s failed outcomes may not determine that the less strict requirement is not satisfied. It is possible that the accessibility requirement may be satisfied when the rule’s outcome is failed. The less strict accessibility requirement is a Secondary requirement.</li>

<aside class=example>
<header>Example: a rule that tests Enhanced Contrast</header>
<blockquote>This rule was designed to test Success Criterion 1.4.6 Contrast (Enhanced) (Level AAA). A less strict requirement, Success Criterion 1.4.3 Contrast Minimum (AA), will be satisfied when the rule outcomes are passed, and may be satisfied when the rule outcomes are failed.This rule’s mapping:
<ul>
<li>Conformance Requirement: Success Criterion 1.4.6 Contrast (Enhanced)</li>
<li>Secondary Requirement: Success Criterion 1.4.3 Contrast (Minimum)</li>
<ul><li>Background Section: Success Criterion 1.4.3 is mapped as a Secondary requirement because the SC may be <dfn>satisfied</dfn>when the rule’s outcomes are `failed`.</li></ul>
</aside>
</ul>
</ol>

**Scenario 3**: both outcomes are only sometimes true

A rule was designed to test an accessibility requirement and under certain conditions, other accessibility requirements apply. In this scenario, the other accessibility requirements are sometimes, but not always, satisfied or not satisfied because they are not always applicable in the rule. These other accessibility requirements are a Secondary requirement.
Copy link
Collaborator

@tbostic32 tbostic32 Dec 13, 2022

Choose a reason for hiding this comment

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

Suggested change
A rule was designed to test an accessibility requirement and under certain conditions, other accessibility requirements apply. In this scenario, the other accessibility requirements are sometimes, but not always, satisfied or not satisfied because they are not always applicable in the rule. These other accessibility requirements are a Secondary requirement.
A rule was designed to test an accessibility requirement and under certain conditions, other accessibility requirements apply. In this scenario, the other accessibility requirements are only sometimes evaluated since they are not always applicable in the rule. These other accessibility requirements are a Secondary requirement.

I found the second sentence here a bit confusing. I think this edit says the same thing but simplifies the langauge a bit? (the word evaluated might need to be changed)

As a second question, does "not always applicable in the rule" == "there exists a passed or failed test case for which the requirement is not applicable" (wording could be better). In my opinion, I think this should be the case, if it isn't then it means we are missing a test case. I think making "not always applicable in the rule" more concrete by referencing test cases makes it more measurable (e.g., applicable to some but not all passed and failed examples == secondary requirement under scenario 4) and makes it more understandable.


<aside class=example>
<header>Example 1: a rule that tests if a link has a non-empty accessible name</header>
<blockquote>This rule was designed to test links for accessibility requirements 4.1.2 Name, Role, Value (Level A), 2.4.4 Link Purpose (In Context) (Level A), 2.4.9 Link Purpose (Link Only) (Level AAA). When a &lt;map&gt; element is used with <area> elements to define an image map, this is also a link area. Testing for non-empty accessible name for &lt;area&gt; elements would map to another accessibility requirement 1.1.1 Non-text Content. Because the rule tests for all links and SC 1.1.1 only applies certain links, this rule’s mapping:
kengdoj marked this conversation as resolved.
Show resolved Hide resolved
<ul>
<li>Conformance Requirement: Success Criteria 4.1.2 Name, Role, Value (Level A), 2.4.4 Link Purpose (In Context) (Level A), 2.4.9 Link Purpose (Link Only) (Level AAA)</li>
<li>Secondary Requirement: Success Criterion 1.1.1 Non-text Content</li>
<ul><li>Background Section: Success Criterion 1.1.1 Non-text Content is mapped as a Secondary requirement because the SC applies only to certain types of links (<area> element links), not to all links. </li></ul>
</ul>
</blockquote>
</aside>

<aside class=example>
<header>Example 2: A rule that tests that elements that have an explicit role also specify all required states and properties </header>
<blockquote>This rule was designed to test a requirement of WAI-ARIA. In some cases, a failed outcome for this rule may result in WCAG 2 Success Criterion 4.1.2 Name, Role, Value being not satisfied, but not always. This rule’s mapping:
<ul>
<li>Conformance Requirement: WAI-ARIA 1.1</li>
<li>Secondary Requirement: Success Criterion 4.1.2 Name, Role, Value
<ul><li>Background Section: Success Criterion 4.1.2 Name, Role, Value is mapped as a Secondary requirement because it only applies to user controls. </li></ul>
</li>
</ul>
</blockquote>
</aside>

### Mapping Outside WCAG ### {#mapping-outside-wcag}

Expand Down