Merge branch 'act-rules:develop' into develop

dan-tripp-siteimprove · web-flow · commit f920a4726c1b · 2023-06-21T20:34:33.000-04:00
diff --git a/_rules/aria-attr-defined-5f99a7.md b/_rules/aria-attr-defined-5f99a7.md
@@ -83,19 +83,11 @@ This `div` element with a role of `textbox` has multiple `aria-` attributes whic
 
 #### Passed Example 4
 
-This `input` element with a role of `spinbutton` has multiple `aria-` attributes specified which are all defined in [WAI-ARIA Specifications][].
+This `input` element with a type of `number` has multiple `aria-` attributes specified which are all defined in [WAI-ARIA Specifications][].
 
 ```html
 <label for="spinbutton">Enter a number between 0 and 100:</label>
-<input
-	id="spinbutton"
-	role="spinbutton"
-	aria-valuemax="100"
-	aria-valuemin="0"
-	aria-valuenow="25"
-	type="number"
-	value="25"
-/>
+<input id="spinbutton" aria-valuemax="100" aria-valuemin="0" aria-valuenow="25" type="number" value="25" />
 ```
 
 ### Failed
diff --git a/_rules/html-page-title-descriptive-c4a8a4.md b/_rules/html-page-title-descriptive-c4a8a4.md
@@ -37,7 +37,10 @@ htmlHintIgnore:
 
 ## Applicability
 
-This rule applies to the [document title][] of each [html web page][] if this [document title][] contains not only [whitespace](#whitespace) [text nodes](https://dom.spec.whatwg.org/#text).
+This rule applies to the [document title][] of each [html web page][], except if one of the following is true:
+
+- The [html web page][] has no [document title][]; or
+- The [document title][] contains only [whitespace](#whitespace) [text nodes](https://dom.spec.whatwg.org/#text).
 
 ## Expectation
 
@@ -126,7 +129,7 @@ This `title` element, which is within the `body`, describes the content of the d
 
 #### Failed Example 1
 
-This `<title>` element does not describe the content of the document.
+This `title` element does not describe the content of the document.
 
 ```html
 <html lang="en">
diff --git a/_rules/iframe-non-empty-accessible-name-cae760.md b/_rules/iframe-non-empty-accessible-name-cae760.md
@@ -16,16 +16,17 @@ input_aspects:
 acknowledgments:
   authors:
     - Jey Nandakumar
+    - Tom Brunet
     - Wilco Fiers
   funding:
     - WAI-Tools
 ---
 
 ## Applicability
 
-This rule applies to `iframe` elements that are [included in the accessibility tree][] and do not have a negative `tabindex` [attribute value][].
-
-**Note:** `frame` element is deprecated, this rule does not consider `frame` or `frameset` elements.
+This rule applies to `iframe` elements that are [included in the accessibility tree][] and for which all of the following are true:
+- the `iframe` does not have a negative `tabindex` [attribute value][]; and
+- the `iframe` does not have an [explicit semantic role][] of `presentation` or `none`.
 
 ## Expectation
 
@@ -37,14 +38,18 @@ If an `iframe` is not perceived by the user as a single control, it does not qua
 
 ## Accessibility Support
 
-- Some browsers include `iframe` elements in the [sequential focus navigation][]. This ensures that the contents of `iframe` elements can be scrolled and accessed by using the keyboard. When an `iframe` is removed from the accessibility tree, this rule is still applicable for those browsers, unless the `iframe` is explicitly removed from [sequential focus navigation][] (by having the `tabindex` attribute set to a negative value).
-
 - Browser and assistive technology support for `iframe` elements is currently **inconsistent**. Some examples of inconsistencies include (but are not limited to):
   - There is a known combination of a popular browser and assistive technology that ignores `aria-label` and only announces `title` attribute as an [accessible name][]
   - Some assistive technologies ignore empty `iframe` elements, regardless of if they are focusable or if they have an accessible name.
+  - Some browsers instantly redirect focus from `iframe` elements  to the first focusable element inside that iframe. This redirect makes it appear as though the `iframe` never receives focus. This occurs even if the `iframe` has a non-negative `tabindex` [attribute value][].
+  - Not all browsers redirect focus on `iframe` elements. This ensures that the contents of `iframe` elements can be scrolled and accessed by using the keyboard. This must not be circumvented by using a negative tabindex, as this will make the `iframe` completely inaccessible for keyboard navigation.
 
 ## Background
 
+The `frame` element is deprecated, this rule does not consider `frame` or `frameset` elements.
+
+Due to inconsistencies in handling focus on `iframe`, this rule ignores `iframe` elements for which there is an attempt to hide them from assistive technologies.  Whether `iframe` elements that are inapplicable to this rule still require an accessible name varies between browsers.
+
 ### Bibliography
 
 - [H64: Using the title attribute of the frame and iframe elements](https://www.w3.org/WAI/WCAG21/Techniques/html/H64)
@@ -110,10 +115,8 @@ This `iframe` element has an empty (`""`) [accessible name][] because the `title
 
 This `iframe` element has an empty (`""`) [accessible name][] because the `title` attribute value is trimmed of [whitespace][] by the [accessible name computation][accessible name and description computation].
 
-**Note:**: Because `iframe` elements are part of [sequential focus navigation][], the [explicit semantic role](#explicit-role) of `none` will be ignored, due to the [Presentational Roles Conflict Resolution](https://www.w3.org/TR/wai-aria-1.1/#presentational-roles-conflict-resolution).
-
 ```html
-<iframe title=" " src="/test-assets/SC4-1-2-frame-doc.html" role="none"> </iframe>
+<iframe title=" " src="/test-assets/SC4-1-2-frame-doc.html"> </iframe>
 ```
 
 ### Inapplicable
@@ -139,7 +142,15 @@ This `iframe` is not [included in the accessibility tree][] because of setting a
 This `iframe` element has a negative `tabindex` [attribute value][].
 
 ```html
-<iframe tabindex="-1" src="/test-assets/SC4-1-2-frame-doc.html"> </iframe>
+<iframe tabindex="-1" src="/test-assets/SC4-1-2-frame-doc.html" style="height: 250px"> </iframe>
+```
+
+#### Inapplicable Example 4
+
+This `iframe` element has an [explicit semantic role][] of `none`.
+
+```html
+<iframe src="/test-assets/SC4-1-2-frame-doc.html" role="none"> </iframe>
 ```
 
 [accessible name]: #accessible-name 'Definition of accessible name'
diff --git a/_rules/image-button-non-empty-accessible-name-59796f.md b/_rules/image-button-non-empty-accessible-name-59796f.md
@@ -60,7 +60,7 @@ The [input type="image" Accessible Name Computation algorithm](https://www.w3.or
 
 ## Background
 
-Contrarily to `img` elements, an empty `alt` attribute does not make image button decorative; image buttons have a button role and are therefore exposed as interactive elements. Consequently, an empty `alt` attribute does not provide a "usable string" for image buttons and the computation defaults to other means of providing a name, as defined in [input type="image" Accessible Name Computation algorithm](https://www.w3.org/TR/html-aam/#input-type-image-accessible-name-computation).
+Contrarily to `img` elements, an empty `alt` attribute (`alt=""`) does not make an image button decorative; image buttons have a button role and are therefore exposed as interactive elements. Consequently, an empty `alt` attribute does not provide a "usable string" for image buttons and the computation defaults to other means of providing a name, as defined in [input type="image" Accessible Name Computation algorithm](https://www.w3.org/TR/html-aam/#input-type-image-accessible-name-computation).
 
 ### Related rules
 
diff --git a/_rules/image-non-empty-accessible-name-23a2a8.md b/_rules/image-non-empty-accessible-name-23a2a8.md
@@ -52,7 +52,7 @@ There are no assumptions.
 
 ## Accessibility Support
 
-- There are several popular browsers that do not treat images with empty `alt` attribute as having a role of `presentation` but instead add the `img` element to the accessibility tree with a [semantic role][] of either `img` or `graphic`.
+- There are several popular browsers that do not treat images with an empty `alt` attribute (`alt=""`) as having a role of `presentation` but instead add the `img` element to the accessibility tree with a [semantic role][] of either `img` or `graphic`.
 - Implementation of [Presentational Roles Conflict Resolution][] varies from one browser or assistive technology to another. Depending on this, some [semantic][semantic role] `img` elements can fail this rule with some technology but users of other technologies would not experience any accessibility issue.
 - Images can have their role set to `presentation` through an empty `alt` attribute. [Presentational Roles Conflict Resolution][] does not specify what to do if such an image is [focusable][] (it only specifies what to do in case of explicit `role="none"` or `role="presentation"`). Some browsers expose these images and some don't. Thus, this rule may fail for technologies that expose these without creating an accessibility issue for users of other technologies.
 
diff --git a/_rules/sequentially-focusable-element-has-visible-focus-oj04fd.md b/_rules/sequentially-focusable-element-has-visible-focus-oj04fd.md
@@ -40,9 +40,9 @@ There are no accessibility support issues known.
 
 Default styling in user agents provides a focus indication for focusable elements (even those that are not focusable by default), as shown in Passed Examples 1 and 2. Many examples in this rule need to **remove** that indicator in order to illustrate various situations. This is bad practice and should normally be avoided.
 
-WCAG 2.0 and 2.1 do not have any requirement of how big or small focus indicator should be, or how far or near from the [focusable][] element it should be. Thus it is possible to pass this rule and [Success Criterion 2.4.7 Focus Visible][sc247] with barely perceptible changes at the other end of the page. That would however still be an accessibility issue. WCAG 2.2 includes [Success Criterion 2.4.11 Focus Appearance][sc2411] and [Success Criterion 2.4.12 Focus Not Obscured (Minimum)][sc2412] specifying how big the focus indicator should be. All Examples in this rule satisfy those success criteria.
+WCAG 2.0 and 2.1 do not have any requirement of how big or small focus indicator should be, or how far or near from the [focusable][] element it should be. Thus it is possible to pass this rule and [Success Criterion 2.4.7 Focus Visible][sc247] with barely perceptible changes at the other end of the page. That would however still be an accessibility issue. WCAG 2.2 includes [Success Criterion 2.4.11 Focus Appearance][sc2411] and [Success Criterion 2.4.12 Focus Not Obscured (Minimum)][sc2412] specifying how big the focus indicator should be. All Passed Examples in this rule satisfy those success criteria.
 
-WCAG has no clear requirement of unicity of the focus indicator for each [focusable][] element. Therefore, this rule can pass even if several focus indicators are identical. Such a situation may nonetheless cause confusion and all Examples in this rule avoid it.
+WCAG does not require that the focus indicator for each [focusable][] element is unique in appearance. Therefore, this rule can pass even if several focus indicators are identical. Such a situation may nonetheless cause confusion and all Examples in this rule avoid it.
 
 ### Bibliography
 
diff --git a/_rules/text-contrast-afw4f7.md b/_rules/text-contrast-afw4f7.md
@@ -38,7 +38,7 @@ This rule applies to any [visible][] character in a [text node][] that is a [chi
 
 ## Expectation
 
-For 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][].
+For each test target, the [highest possible contrast][] between the [foreground colors][] and [background colors][] is at least 3.0:1 for [large scale text][] and 4.5:1 for other texts, except if the test target is part of a [text node][] that is [purely decorative][] or does not express anything in [human language][].
 
 ## Assumptions
 
@@ -431,7 +431,7 @@ This text is part of a [disabled][] widget because it is a child of an element w
 [foreground colors]: #foreground-colors-of-text 'Definition of Foreground color of text'
 [highest possible contrast]: #highest-possible-contrast 'Definition of Highest possible contrast'
 [human language]: https://www.w3.org/TR/WCAG21/#dfn-human-language-s 'WCAG 2.1, Human language'
-[larger scale text]: #large-scale-text 'Definition of Large scale text'
+[large scale text]: #large-scale-text 'Definition of Large scale text'
 [origins]: https://www.w3.org/TR/css3-cascade/#cascading-origins 'CSS 3, origin'
 [presentational roles conflict resolution]: https://www.w3.org/TR/wai-aria-1.1/#conflict_resolution_presentation_none 'WAI-ARIA, Presentational Roles Conflict Resolution'
 [purely decorative]: https://www.w3.org/TR/WCAG21/#dfn-pure-decoration 'WCAG 2.1, Purely decorative'
diff --git a/_rules/text-contrast-enhanced-09o5cg.md b/_rules/text-contrast-enhanced-09o5cg.md
@@ -43,7 +43,7 @@ This rule applies to any [visible][] character in a [text node][] that is a [chi
 
 ## Expectation
 
-For each test target, the [highest possible contrast][] between the [foreground colors][] and [background colors][] is at least 7:1 or 4.5: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][].
+For each test target, the [highest possible contrast][] between the [foreground colors][] and [background colors][] is at least 4.5:1 for [large scale text][] and 7.0:1 for other texts, except if the test target is part of a [text node][] that is [purely decorative][] or does not express anything in [human language][].
 
 ## Assumptions
 
@@ -455,7 +455,7 @@ This text is part of a [disabled][] widget because it is a child of an element w
 [foreground colors]: #foreground-colors-of-text 'Definition of Foreground color of text'
 [highest possible contrast]: #highest-possible-contrast 'Definition of Highest possible contrast'
 [human language]: https://www.w3.org/TR/WCAG21/#dfn-human-language-s 'WCAG 2.1, Human language'
-[larger scale text]: #large-scale-text 'Definition of Large scale text'
+[large scale text]: #large-scale-text 'Definition of Large scale text'
 [origins]: https://www.w3.org/TR/css3-cascade/#cascading-origins 'CSS 3, origin'
 [presentational roles conflict resolution]: https://www.w3.org/TR/wai-aria-1.1/#conflict_resolution_presentation_none 'WAI-ARIA, Presentational Roles Conflict Resolution'
 [purely decorative]: https://www.w3.org/TR/WCAG21/#dfn-pure-decoration 'WCAG 2.1, Purely decorative'
diff --git a/package.json b/package.json
@@ -127,6 +127,10 @@
 		{
 			"name": "Wilco Fiers",
 			"url": "https://github.com/wilcofiers"
+		},
+		{
+			"name": "Helen Burge",
+			"url": "https://github.com/HelenBurge"
 		}
 	],
 	"devDependencies": {
diff --git a/pages/glossary/implicit-role.md b/pages/glossary/implicit-role.md
@@ -13,4 +13,4 @@ Implicit roles for HTML and SVG, are documented in the [HTML accessibility API m
 
 #### Accessibility Support
 
-- Images with an empty `alt` attribute should have an implicit role of `presentation`, according to the [HTML Accessibility API Mapping (work in progress)](https://www.w3.org/TR/html-aam-1.0/#html-element-role-mappings). However, there are several popular browsers that do not treat images with empty `alt` attribute as having a role of `presentation`. Instead, they add the `img` element to the accessibility tree with a role of either `img` or `graphic`.
+- Images with an empty `alt` attribute (`alt=""`) should have an implicit role of `presentation`, according to the [HTML Accessibility API Mapping (work in progress)](https://www.w3.org/TR/html-aam-1.0/#html-element-role-mappings). However, there are several popular browsers that do not treat images with empty `alt` attribute as having a role of `presentation`. Instead, they add the `img` element to the accessibility tree with a role of either `img` or `graphic`.

Original file line number	Diff line number	Diff line change
`@@ -127,6 +127,10 @@`
`127`	`127`	`{`
`128`	`128`	`"name": "Wilco Fiers",`
`129`	`129`	`"url": "https://github.com/wilcofiers"`
	`130`	`+ },`
	`131`	`+ {`
	`132`	`+ "name": "Helen Burge",`
	`133`	`+ "url": "https://github.com/HelenBurge"`
`130`	`134`	`}`
`131`	`135`	`],`
`132`	`136`	`"devDependencies": {`
Original file line number	Diff line number	Diff line change
`@@ -13,4 +13,4 @@ Implicit roles for HTML and SVG, are documented in the [HTML accessibility API m`
`13`	`13`
`14`	`14`	`#### Accessibility Support`
`15`	`15`
`16`		-- Images with an empty `alt` attribute should have an implicit role of `presentation`, according to the [HTML Accessibility API Mapping (work in progress)](https://www.w3.org/TR/html-aam-1.0/#html-element-role-mappings). However, there are several popular browsers that do not treat images with empty `alt` attribute as having a role of `presentation`. Instead, they add the `img` element to the accessibility tree with a role of either `img` or `graphic`.
	`16`	+- Images with an empty `alt` attribute (`alt=""`) should have an implicit role of `presentation`, according to the [HTML Accessibility API Mapping (work in progress)](https://www.w3.org/TR/html-aam-1.0/#html-element-role-mappings). However, there are several popular browsers that do not treat images with empty `alt` attribute as having a role of `presentation`. Instead, they add the `img` element to the accessibility tree with a role of either `img` or `graphic`.