Merge branch 'develop' into marked-as-decorative-secondary

Author: Jym77

.github/ISSUE_TEMPLATE/ACCESSIBILITY_SUPPORT.md

@@ -0,0 +1,84 @@
+---
+name: Accessibility support template
+about: Issue for tracking accessibility support on ACT Rules
+title: ''
+labels: ['accessibility support']
+assignees: ''
+---
+
+## Accessibility support
+
+(( Put the accessibility support item here ))
+
+## ACT Rules
+
+- ... List the rules here, link to its acc support section
+
+## Test cases
+
+### Test case 1 ...
+
+(( Add test case here ))
+
+```html
+code snippet here
+```
+
+[Open this test case]()
+
+(( Add a link to a code pen or other hosted test case. Keep in mind this test case needs to be accessible and persistent. ))
+
+#### Preconditions
+
+Before running the test, check your settings. In many cases default settings aren't strictly required and will not impact the results. Use common sense here. If non-default settings are necessary for you, record the settings used in the reported results.
+
+- Ensure browsers are in the default settings, turn off unnecessary extensions
+- Ensure ATs are in the default settings
+- Ensure operating system are in default settings
+- Ensure software uses the correct version (usually the latest version)
+
+#### Test instructions
+
+(( Provide instructions on how to test the test case, this should include: ))
+
+- Which technologies to use
+- Any setting changes necessary to run the test
+- Any variation in how to operate the different assistive technologies
+- Step by step instructions on how to check the test case
+- What the expected results are
+
+### External links
+
+(( List any external links to bugs in browsers & AT, WPT, or spec issues. Be sure to open issues in the appropriate repositories. ))
+
+<!--
+Links to external resources to look for / raise issues
+- Web platform tests: https://github.com/web-platform-tests/wpt
+- JAWS issues: https://github.com/FreedomScientific/VFO-standards-support/issues
+- NVDA issues: https://github.com/nvaccess/nvda/issues
+- Firefox issues: https://bugzilla.mozilla.org/
+- Chromium issues: https://issues.chromium.org/issues?q=componentid:1363614+
+- Safari issues: https://github.com/WebKit/webkit/issues
+- ARIA: https://github.com/w3c/aria/issues
+- HTML: https://github.com/whatwg/html/issues
+- CSS: https://github.com/w3c/csswg-drafts/issues
+- AccName: https://github.com/w3c/accname/issues
+- HTML AAM: https://github.com/w3c/html-aam/issues
+- ARIA in HTML: https://github.com/w3c/html-aria/issues
+- PowerMapper tests: https://www.powermapper.com/tests/
+- Accessibility support: https://www.a11ysupport.io/
+-->
+
+## Test results
+
+Please report test results in a comment below. Please use the following format:
+
+```md
+## Test case X
+
+- Date: ...
+- Operating system: ..., version ...
+- Browser: ..., version ...
+- Assistive technology: ..., version ...
+- Test result: Passed / Failed (if failed, how was it different from expected?)
+```

.github/ISSUE_TEMPLATE.md renamed to .github/ISSUE_TEMPLATE/rules-issue-template.md

@@ -1,3 +1,12 @@
+---
+name: Rules issue template
+about: issues related with ACT Rules
+title: ''
+labels: ''
+assignees: ''
+
+---
+
 Please describe the issue with references and relevant examples where necessary.
 
 --- or ---

_rules/__tests__/headings.js

@@ -58,7 +58,7 @@ describeRule('headings', ruleData => {
 	/**
 	 * Check for `required` `h2` headings
 	 */
-	const requiredH2 = [`Applicability`, `Assumptions`, `Accessibility Support`, `Background`, `Test Cases`]
+	const requiredH2 = [`Applicability`, `Background`, `Test Cases`]
 	const h2Headings = getHeadingOfDepth(headings, 2)
 	test.each(requiredH2)('has required `h2` - `%s`', heading => {
 		expect(h2Headings).toContain(heading)
@@ -67,9 +67,9 @@ describeRule('headings', ruleData => {
 	/**
 	 * Check for `required` `h3` headings
 	 */
-	const requiredH3 = [`Passed`, `Failed`, `Inapplicable`]
+	const requiredH3 = [`Assumptions`, `Accessibility Support`, `Passed`, `Failed`, `Inapplicable`]
 	const h3Headings = getHeadingOfDepth(headings, 3)
-	test.each(requiredH3)('has required `h2` - `%s`', heading => {
+	test.each(requiredH3)('has required `h3` - `%s`', heading => {
 		expect(h3Headings).toContain(heading)
 	})
 

_rules/aria-attr-defined-5f99a7.md

@@ -1,6 +1,7 @@
 ---
 id: 5f99a7
 name: ARIA attribute is defined in WAI-ARIA
+rules_format: 1.1
 rule_type: atomic
 description: |
   This rule checks that each `aria-` attribute specified is defined in ARIA 1.2.
@@ -26,17 +27,17 @@ This rule applies to any attribute that starts with `aria-`.
 
 Each target attribute is defined in [WAI-ARIA Specifications][].
 
-## Assumptions
+## Background
 
-There are no assumptions.
+The presence of unknown ARIA attributes is often the result of a typo or other developer error. These attributes are ignored by browsers and other assistive technologies. This often means that a state or property which should exist is missing.
 
-## Accessibility Support
+### Assumptions
 
-There are no accessibility support issues known.
+There are no assumptions.
 
-## Background
+### Accessibility Support
 
-The presence of unknown ARIA attributes is often the result of a typo or other developer error. These attributes are ignored by browsers and other assistive technologies. This often means that a state or property which should exist is missing.
+There are no accessibility support issues known.
 
 ### Bibliography
 

_rules/aria-hidden-no-focusable-content-6cfa84.md

@@ -1,6 +1,7 @@
 ---
 id: 6cfa84
 name: Element with aria-hidden has no content in sequential focus navigation
+rules_format: 1.1
 rule_type: atomic
 description: |
   This rule checks that elements with an `aria-hidden` attribute do not contain elements that are part of the sequential focus navigation and focusable.
@@ -34,14 +35,6 @@ This rule applies to any element with an `aria-hidden` [attribute value][] of `t
 
 None of the target elements has an [inclusive descendant][] in the [flat tree][] that are [focusable][] and part of the [sequential focus navigation][].
 
-## Assumptions
-
-Interacting with the page does not result in changing the `aria-hidden` [attribute value][] of target elements. An example of such a situation would be when closing a modal dialog makes previously hidden elements that were not [focusable][] or part of the [sequential focus navigation][] become [focusable][] and part of the [sequential focus navigation][].
-
-## Accessibility Support
-
-Some user agents treat the value of `aria-hidden` attribute as case-sensitive.
-
 ## Background
 
 Using `aria-hidden="false"` on a descendant of an element with `aria-hidden="true"` [**does not** expose that element](https://www.w3.org/TR/wai-aria-1.2/#aria-hidden). `aria-hidden="true"` hides itself and all its content from assistive technologies.
@@ -52,6 +45,14 @@ An element with an `aria-hidden` attribute set to `true` that is also part of th
 
 The 1 second time span introduced in the exception of the definition of [focusable][] is an arbitrary limit which is not included in WCAG. Given that scripts can manage the focus state of elements, testing the focused state of an element consistently would be impractical without a time limit.
 
+### Assumptions
+
+Interacting with the page does not result in changing the `aria-hidden` [attribute value][] of target elements. An example of such a situation would be when closing a modal dialog makes previously hidden elements that were not [focusable][] or part of the [sequential focus navigation][] become [focusable][] and part of the [sequential focus navigation][].
+
+### Accessibility Support
+
+Some user agents treat the value of `aria-hidden` attribute as case-sensitive.
+
 ### Related rules
 
 - [Element with presentational children has no focusable content](https://www.w3.org/WAI/standards-guidelines/act/rules/307n5z/)

_rules/aria-required-context-role-ff89c9.md

@@ -1,6 +1,7 @@
 ---
 id: ff89c9
 name: ARIA required context role
+rules_format: 1.1
 rule_type: atomic
 description: |
   This rule checks that an element with an explicit semantic role exists inside its required context.
@@ -33,16 +34,6 @@ This rule applies to any [HTML or SVG element][] that is [included in the access
 
 Each test target is the child in the [accessibility tree][] of an element that has a [semantic role][] that is one of the [required context roles][] of the target element.
 
-## Assumptions
-
-The rule assumes that the [explicit role][] of the applicable elements is appropriate for their element. I.e. A heading incorrectly marked up with `role="cell"` does not fail [success criterion 1.3.1 Info and Relationships][sc131] for not being in the context of a `row`. Having an inappropriate role is itself an issue under 1.3.1 Info and Relationships, so in either scenario a failure of this rule means this success criterion is not satisfied.
-
-## Accessibility Support
-
-- User agents do not all have the same accessibility tree. This can lead to different results for this rule, depending on which accessibility tree is used as input.
-- `aria-owns` has limited support in some user agents.
-- There exist some combination of popular browsers and assistive technologies who do not announce correctly relationships based on a mix of [implicit][implicit role] and [explicit][explicit role] roles.
-
 ## Background
 
 The applicability of this rule is limited to the [WAI-ARIA 1.2 Recommendation][aria 1.2] roles. The [WAI-ARIA Graphics Module][] does not include any [required context roles][]. The [Digital Publishing WAI-ARIA Module (DPUB ARIA) 1.0][dpub 1.0] only has two roles with [required context roles][] (`doc-biblioentry` and `doc-endnote`); both of them have issues with their use of role inheritance, and both of them are deprecated in the [Digital Publishing WAI-ARIA Module (DPUB ARIA) 1.1][dpub 1.1] editor's draft.
@@ -57,6 +48,16 @@ This rule is restricted to direct parent-child relation in the [accessibility tr
 
 Some user agents try to correct missing [required context roles][] or incorrect [content model][]. This often results, for example, in an isolated list item being presented as part of a one-item list containing only itself. Therefore, most test cases contain several targets to try and circumvent these corrections in order to better demonstrate the issue.
 
+### Assumptions
+
+The rule assumes that the [explicit role][] of the applicable elements is appropriate for their element. I.e. A heading incorrectly marked up with `role="cell"` does not fail [success criterion 1.3.1 Info and Relationships][sc131] for not being in the context of a `row`. Having an inappropriate role is itself an issue under 1.3.1 Info and Relationships, so in either scenario a failure of this rule means this success criterion is not satisfied.
+
+### Accessibility Support
+
+- User agents do not all have the same accessibility tree. This can lead to different results for this rule, depending on which accessibility tree is used as input.
+- `aria-owns` has limited support in some user agents.
+- There exist some combination of popular browsers and assistive technologies who do not announce correctly relationships based on a mix of [implicit][implicit role] and [explicit][explicit role] roles.
+
 ### Bibliography
 
 - [Understanding Success Criterion 1.3.1: Info and Relationships](https://www.w3.org/WAI/WCAG22/Understanding/info-and-relationships.html)

_rules/aria-required-id-references-in6db8.md

@@ -1,6 +1,7 @@
 ---
 id: in6db8
 name: ARIA required ID references exist
+rules_format: 1.1
 rule_type: atomic
 description: |
   This rule checks that every ID reference required by WAI-ARIA exists
@@ -34,17 +35,17 @@ This rule applies to any `aria-controls` attribute defined on an [HTML element][
 
 Each test target's [attribute value][] is a space-separated list of one or more IDs. At least one of those IDs must match an `id` [attribute value][] in the same [shadow tree][] or, if not within a [shadow tree][], within the same [document][document tree].
 
-## Assumptions
+## Background
 
-There are no assumptions.
+This rule is written specifically for `aria-controls`, because it is the only [ID Reference List][] property that is [required by WAI-ARIA][]. The `aria-controls` property is only required by the `scrollbar` role and by an expanded `combobox`. There are no [ID Reference][] properties that are required by WAI-ARIA for any role.
 
-## Accessibility Support
+### Assumptions
 
-Some user agents treat the value of `aria-*` attribute as case-sensitive (even when these are not IDs) while some treat them as case-insensitive.
+There are no assumptions.
 
-## Background
+### Accessibility Support
 
-This rule is written specifically for `aria-controls`, because it is the only [ID Reference List][] property that is [required by WAI-ARIA][]. The `aria-controls` property is only required by the `scrollbar` role and by an expanded `combobox`. There are no [ID Reference][] properties that are required by WAI-ARIA for any role.
+Some user agents treat the value of `aria-*` attribute as case-sensitive (even when these are not IDs) while some treat them as case-insensitive.
 
 ### Bibliography
 

_rules/aria-required-owned-element-bc4a75.md

@@ -1,6 +1,7 @@
 ---
 id: bc4a75
 name: ARIA required owned elements
+rules_format: 1.1
 rule_type: atomic
 description: |
   This rule checks that an element with an explicit semantic role has at least one of its required owned elements.
@@ -34,25 +35,25 @@ Each test target only [owns][] elements with a [semantic role][] from the [requi
 
 **Note:** The definition of [owned by][] used in this rule is different than the definition of ["owned element" in WAI-ARIA](https://www.w3.org/TR/wai-aria-1.2/#dfn-owned-element). See more in the [owned by][] definition.
 
-## Assumptions
+## Background
+
+Some [required owned elements][] are only valid if they themselves [own][owns] (or "contain") elements with a given [semantic role][]. This is denoted by an arrow (meaning "containing") in the role description. For example, the role `menu` has `group → menuitemradio` as one of its [required owned elements][], meaning that elements with a role of `menu` may only [own][owns] elements with a role of `group` who themselves only [own][owns] elements with a role of `menuitemradio`.
+
+The applicability of this rule is limited to the [WAI-ARIA 1.2 Recommendation][wai-aria 1.2] roles. The [WAI-ARIA Graphics Module][] and [Digital Publishing WAI-ARIA Module (DPUB ARIA) 1.1 (Editors draft)][dpub 1.1] do not include any [required owned elements][].
+
+**Note:** [Subclass roles](https://www.w3.org/TR/wai-aria-1.2/#subclassroles) of [required owned elements][] are not automatically included as possible [required owned elements][]. For example, the `treeitem` role is not a [required owned elements][] for [`list`](https://www.w3.org/TR/wai-aria-1.2/#list), even though `treeitem` is a [subclass role](https://www.w3.org/TR/wai-aria-1.2/#subclassroles) of `listitem`.
+
+### Assumptions
 
 If the [explicit semantic role][] on the target element is incorrectly used, and any relationships between elements are already programmatically determinable, failing this rule may not result in accessibility issues for users of assistive technologies, and it should then not be considered a failure under [WCAG success criterion 1.3.1 Info and Relationships](https://www.w3.org/TR/WCAG22/#info-and-relationships).
 
-## Accessibility Support
+### Accessibility Support
 
 - User agents do not all have the same accessibility tree. Particularly the method of deriving which element owns which other elements varies between browsers. This can lead to different results for this rule, depending on which accessibility tree is used as input.
 - `aria-owns` has limited support in some user agents.
 - Assistive technologies are not consistent in how they handle situations where a [required owned element][] has a missing or incorrect role. This can lead to situations where inaccurate owned elements behave as expected in one assistive technology, but not in another.
 - Some user agents treat the value of `aria-busy` as case-sensitive.
 
-## Background
-
-Some [required owned elements][] are only valid if they themselves [own][owns] (or "contain") elements with a given [semantic role][]. This is denoted by an arrow (meaning "containing") in the role description. For example, the role `menu` has `group → menuitemradio` as one of its [required owned elements][], meaning that elements with a role of `menu` may only [own][owns] elements with a role of `group` who themselves only [own][owns] elements with a role of `menuitemradio`.
-
-The applicability of this rule is limited to the [WAI-ARIA 1.2 Recommendation][wai-aria 1.2] roles. The [WAI-ARIA Graphics Module][] and [Digital Publishing WAI-ARIA Module (DPUB ARIA) 1.1 (Editors draft)][dpub 1.1] do not include any [required owned elements][].
-
-**Note:** [Subclass roles](https://www.w3.org/TR/wai-aria-1.2/#subclassroles) of [required owned elements][] are not automatically included as possible [required owned elements][]. For example, the `treeitem` role is not a [required owned elements][] for [`list`](https://www.w3.org/TR/wai-aria-1.2/#list), even though `treeitem` is a [subclass role](https://www.w3.org/TR/wai-aria-1.2/#subclassroles) of `listitem`.
-
 ### Bibliography
 
 - [Understanding Success Criterion 1.3.1: Info and Relationships](https://www.w3.org/WAI/WCAG22/Understanding/info-and-relationships.html)

_rules/aria-state-or-property-permitted-5c01ea.md

@@ -1,6 +1,7 @@
 ---
 id: 5c01ea
 name: ARIA state or property is permitted
+rules_format: 1.1
 rule_type: atomic
 description: |
   This rule checks that WAI-ARIA states or properties are allowed for the element they are specified on.
@@ -50,14 +51,6 @@ For each test target, one of the following is true:
 
 No test target is [prohibited][] on the [semantic role][] of the element on which it is specified.
 
-## Assumptions
-
-There are no assumptions.
-
-## Accessibility Support
-
-Implementation of [Presentational Roles Conflict Resolution][] varies from one browser or assistive technology to another. Depending on this, some elements can have a [semantic role][] of `none` and their attributes fail this rule with some technologies but users of other technology would not experience any accessibility issue.
-
 ## Background
 
 The presence of prohibited ARIA attributes is often the result of a developer using an incorrect role, or a misunderstanding of the attribute. These attributes are ignored by browsers and other assistive technologies. This often means that a state or property which should exist is missing.
@@ -66,6 +59,14 @@ In HTML, there are language features that do not have corresponding implicit WAI
 
 Assessing the value of the attribute is out of scope for this rule.
 
+### Assumptions
+
+There are no assumptions.
+
+### Accessibility Support
+
+Implementation of [Presentational Roles Conflict Resolution][] varies from one browser or assistive technology to another. Depending on this, some elements can have a [semantic role][] of `none` and their attributes fail this rule with some technologies but users of other technology would not experience any accessibility issue.
+
 ### Related rules
 
 - [ARIA state or property has valid value](https://www.w3.org/WAI/standards-guidelines/act/rules/6a7281/)