From 5ba46d9e5777b96b0f94f4453a26052d1b460677 Mon Sep 17 00:00:00 2001 From: Wilco Fiers Date: Thu, 21 Nov 2024 18:27:31 +0100 Subject: [PATCH] Update to rules format 1.1 (#2220) * Update to rules format 1.1 * Update mention to rules format from 1.0 to 1.1 in rule design * Update pages/design/rule-design.md --------- Co-authored-by: Carlos Duarte --- _rules/__tests__/headings.js | 6 +- _rules/aria-attr-defined-5f99a7.md | 13 +++-- ...aria-hidden-no-focusable-content-6cfa84.md | 17 +++--- _rules/aria-required-context-role-ff89c9.md | 21 +++---- _rules/aria-required-id-references-in6db8.md | 13 +++-- _rules/aria-required-owned-element-bc4a75.md | 21 +++---- ...aria-state-or-property-permitted-5c01ea.md | 17 +++--- ...ia-state-or-property-valid-value-6a7281.md | 15 ++--- _rules/attr-not-duplicated-e6952f.md | 9 +-- _rules/audio-as-media-alternative-afb423.md | 9 +-- ...oids-automatically-playing-audio-80f0bf.md | 13 +++-- _rules/audio-text-alternative-e7aa44.md | 9 +-- _rules/audio-transcript-2eb176.md | 9 +-- ...-audio-does-not-exceed-3-seconds-aaa1bf.md | 9 +-- ...play-audio-has-control-mechanism-4c31df.md | 9 +-- _rules/auto-update-text-efbfc7.md | 17 +++--- _rules/autocomplete-valid-value-73f2c2.md | 29 +++++----- _rules/block-collapsible-3e12e1.md | 9 +-- ...button-non-empty-accessible-name-97a4e1.md | 13 +++-- _rules/bypass-blocks-cf77f2.md | 13 +++-- _rules/css-restrict-orientation-b33eff.md | 9 +-- _rules/device-motion-disabled-c249d5.md | 13 +++-- _rules/device-motion-user-interface-7677a9.md | 13 +++-- ...eadings-for-non-repeated-content-047fe0.md | 17 +++--- ...strument-to-non-repeated-content-ye5d6e.md | 15 ++--- ...ndmark-with-non-repeated-content-b40fd1.md | 15 ++--- ...nt-lang-matches-default-language-off6ek.md | 13 +++-- _rules/element-lang-valid-de46e4.md | 9 +-- ...marked-decorative-is-not-exposed-46ca7f.md | 17 +++--- ...-image-non-empty-accessible-name-7d6734.md | 9 +-- _rules/focusable-no-keyboard-trap-80af7b.md | 13 +++-- ...o-keyboard-trap-non-standard-nav-ebe86a.md | 9 +-- ...le-no-keyboard-trap-standard-nav-a1b64e.md | 13 +++-- _rules/form-field-label-descriptive-cc0f0a.md | 19 +++--- ...-field-non-empty-accessible-name-e086e5.md | 19 +++--- _rules/heading-descriptive-b49b2e.md | 13 +++-- ...eading-non-empty-accessible-name-ffd0e9.md | 13 +++-- _rules/html-page-lang-b5c3f8.md | 9 +-- .../html-page-lang-matches-default-ucwvc8.md | 9 +-- _rules/html-page-lang-valid-bf051a.md | 9 +-- .../html-page-lang-xml-lang-match-5b7ae0.md | 13 +++-- _rules/html-page-non-empty-title-2779a5.md | 23 ++++---- _rules/html-page-title-descriptive-c4a8a4.md | 15 ++--- _rules/id-value-unique-3ea0c8.md | 9 +-- ...dentical-name-equivalent-purpose-4b1c6c.md | 13 +++-- ...iframe-non-empty-accessible-name-cae760.md | 17 +++--- ...interactive-content-in-tab-order-akn7bn.md | 15 ++--- ...mage-accessible-name-descriptive-qt1vmo.md | 9 +-- ...button-non-empty-accessible-name-59796f.md | 13 +++-- ...mage-filename-as-accessible-name-9eb3f6.md | 13 +++-- _rules/image-no-text-0va7u6.md | 13 +++-- .../image-non-empty-accessible-name-23a2a8.md | 9 +-- ...ge-not-in-acc-tree-is-decorative-e88epe.md | 9 +-- ...rtant-letter-spacing-wide-enough-24afc2.md | 17 +++--- ...mportant-line-height-wide-enough-78fd32.md | 21 +++---- ...portant-word-spacing-wide-enough-9e45ec.md | 17 +++--- _rules/invalid-form-field-value-36b590.md | 17 +++--- _rules/link-alone-descriptive-aizyf1.md | 9 +-- _rules/link-in-context-descriptive-5effbb.md | 9 +-- .../link-non-empty-accessible-name-c487ae.md | 9 +-- ...dentical-name-equivalent-purpose-b20e66.md | 9 +-- ...context-serve-equivalent-purpose-fd3a94.md | 48 ++++++++++----- _rules/menuitem-non-empty-name-m6b1q3.md | 9 +-- _rules/meta-refresh-no-delay-bc659a.md | 19 +++--- ...ta-refresh-no-delay-no-exception-bisz58.md | 17 +++--- _rules/meta-viewport-b4f0c3.md | 9 +-- ...non-visual-reference-alternative-9bd38c.md | 17 +++--- _rules/object-has-accessible-name-8fc3b6.md | 21 +++---- ...al-children-no-focusable-content-307n5z.md | 15 ++--- .../printable-characters-shortcut-ffbc54.md | 19 +++--- _rules/role-attribute-valid-value-674b10.md | 17 +++--- ...e-required-states-and-properties-4e8ab6.md | 17 +++--- ...able-element-keyboard-accessible-0ssw9k.md | 17 +++--- ...usable-element-has-visible-focus-oj04fd.md | 17 +++--- ...ummary-non-empty-accessible-name-2t702h.md | 17 +++--- ...e-header-cell-has-assigned-cells-d0f69e.md | 13 +++-- ...rs-attribute-refer-to-data-cells-a25f45.md | 9 +-- _rules/text-contrast-afw4f7.md | 25 ++++---- _rules/text-contrast-enhanced-09o5cg.md | 21 +++---- .../video-alternative-for-auditory-eac66b.md | 9 +-- _rules/video-alternative-for-visual-c5a4ea.md | 11 ++-- _rules/video-as-media-alternative-ab4d13.md | 9 +-- _rules/video-audio-description-1ea59c.md | 9 +-- _rules/video-captions-f51b46.md | 9 +-- _rules/video-description-track-f196ce.md | 9 +-- ...ideo-only-alternative-for-visual-c3232f.md | 9 +-- .../video-only-as-media-alternative-fd26cf.md | 13 +++-- _rules/video-only-audio-track-d7ba54.md | 9 +-- _rules/video-only-description-track-ac7dc6.md | 13 +++-- _rules/video-only-transcript-ee13b5.md | 13 +++-- ...eo-strict-alternative-for-visual-1ec09b.md | 9 +-- _rules/video-transcript-1a02b0.md | 9 +-- ...visible-label-in-accessible-name-2ee8b8.md | 15 ++--- .../zoom-text-no-overflow-clipping-59br37.md | 13 +++-- pages/design/atomic-template-empty.md | 21 +++++-- pages/design/composite-template-empty.md | 21 +++++-- pages/design/manual-template-empty.md | 21 +++++-- pages/design/rule-design.md | 8 +-- pages/design/rule-template.md | 58 ++++++++++++++----- pages/glossary/outcome.md | 19 ++++-- 100 files changed, 812 insertions(+), 628 deletions(-) diff --git a/_rules/__tests__/headings.js b/_rules/__tests__/headings.js index eb3da8f5a30..4c02b35e853 100644 --- a/_rules/__tests__/headings.js +++ b/_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) }) diff --git a/_rules/aria-attr-defined-5f99a7.md b/_rules/aria-attr-defined-5f99a7.md index cc26dc7185a..9a9c7f32416 100755 --- a/_rules/aria-attr-defined-5f99a7.md +++ b/_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 diff --git a/_rules/aria-hidden-no-focusable-content-6cfa84.md b/_rules/aria-hidden-no-focusable-content-6cfa84.md index dbd62d16329..78b31a4167c 100755 --- a/_rules/aria-hidden-no-focusable-content-6cfa84.md +++ b/_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/) diff --git a/_rules/aria-required-context-role-ff89c9.md b/_rules/aria-required-context-role-ff89c9.md index 67461d2e92f..a499eef0395 100755 --- a/_rules/aria-required-context-role-ff89c9.md +++ b/_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) diff --git a/_rules/aria-required-id-references-in6db8.md b/_rules/aria-required-id-references-in6db8.md index de7401e8cb2..9c398df0faf 100644 --- a/_rules/aria-required-id-references-in6db8.md +++ b/_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 diff --git a/_rules/aria-required-owned-element-bc4a75.md b/_rules/aria-required-owned-element-bc4a75.md index 828baa16c26..038a7edd812 100755 --- a/_rules/aria-required-owned-element-bc4a75.md +++ b/_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) diff --git a/_rules/aria-state-or-property-permitted-5c01ea.md b/_rules/aria-state-or-property-permitted-5c01ea.md index e33da0e7dec..e9e49899c4b 100755 --- a/_rules/aria-state-or-property-permitted-5c01ea.md +++ b/_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/) diff --git a/_rules/aria-state-or-property-valid-value-6a7281.md b/_rules/aria-state-or-property-valid-value-6a7281.md index fc0fe1f5307..08d63e83348 100755 --- a/_rules/aria-state-or-property-valid-value-6a7281.md +++ b/_rules/aria-state-or-property-valid-value-6a7281.md @@ -1,6 +1,7 @@ --- id: 6a7281 name: ARIA state or property has valid value +rules_format: 1.1 rule_type: atomic description: | This rule checks that each ARIA state or property has a valid value type. @@ -36,19 +37,19 @@ Each test target has an [attribute value][] that is valid according to its [WAI- **Exception**: For value types `ID Reference` and `ID Reference List` no ID referenced elements are required. -## Assumptions +## Background -There are no assumptions. +Using invalid ARIA attribute values is often the result of a typo or other developer error. These attributes are then either ignored, or a default value is assumed by browsers and assistive technologies. This often means that a state or property which should exist is missing or has an unexpected value. If the default value for invalid attribute values happens to match the author's intention for the value, there will not be an accessibility issue. -## Accessibility Support +This rule does not require the target of an `ID Reference` to exist. This is because referencing an element that does not exist, and not having the reference at all has the same end result. A common use case for using `ID Reference` for a non-existing ID is to use a static `aria-errormessage` on an `input` element, and to only insert the element with the error message if there is an actual error. There are some cases in which ID references are required. These are tested in a separate rule. -Some user agents treat the value of `aria-*` attribute as case-sensitive (even when these are not ID) while some treat them as case-insensitive. +### Assumptions -## Background +There are no assumptions. -Using invalid ARIA attribute values is often the result of a typo or other developer error. These attributes are then either ignored, or a default value is assumed by browsers and assistive technologies. This often means that a state or property which should exist is missing or has an unexpected value. If the default value for invalid attribute values happens to match the author's intention for the value, there will not be an accessibility issue. +### Accessibility Support -This rule does not require the target of an `ID Reference` to exist. This is because referencing an element that does not exist, and not having the reference at all has the same end result. A common use case for using `ID Reference` for a non-existing ID is to use a static `aria-errormessage` on an `input` element, and to only insert the element with the error message if there is an actual error. There are some cases in which ID references are required. These are tested in a separate rule. +Some user agents treat the value of `aria-*` attribute as case-sensitive (even when these are not ID) while some treat them as case-insensitive. ### Related rules diff --git a/_rules/attr-not-duplicated-e6952f.md b/_rules/attr-not-duplicated-e6952f.md index 83e1d194ddf..ead56d70bc7 100755 --- a/_rules/attr-not-duplicated-e6952f.md +++ b/_rules/attr-not-duplicated-e6952f.md @@ -1,6 +1,7 @@ --- id: e6952f name: Attribute is not duplicated +rules_format: 1.1 rule_type: atomic description: | This rule checks that HTML and SVG starting tags do not contain duplicated attributes. @@ -43,16 +44,16 @@ This rule applies to any [starting tag](https://www.w3.org/TR/html5/syntax.html# For each test target, there are no duplicated [attributes](https://www.w3.org/TR/html5/syntax.html#elements-attributes). -## Assumptions +## Background + +### Assumptions There are no assumptions. -## Accessibility Support +### Accessibility Support There are no accessibility support issues known. -## Background - ### Bibliography - [H94: Ensuring that elements do not contain duplicate attributes](https://www.w3.org/WAI/WCAG22/Techniques/html/H94) diff --git a/_rules/audio-as-media-alternative-afb423.md b/_rules/audio-as-media-alternative-afb423.md index 7474f256ef8..4ae5fe56b94 100755 --- a/_rules/audio-as-media-alternative-afb423.md +++ b/_rules/audio-as-media-alternative-afb423.md @@ -1,6 +1,7 @@ --- id: afb423 name: Audio element content is media alternative for text +rules_format: 1.1 rule_type: atomic description: | This rule checks that the `audio` element is a media alternative for text on the page. @@ -35,16 +36,16 @@ The auditory information of each test target is available as text (directly or v Each target element is labeled as an audio alternative for text on the page by content that is [visible][] and [included in the accessibility tree][]. -## Assumptions +## Background + +### Assumptions There are no assumptions. -## Accessibility Support +### Accessibility Support There are no accessibility support issues known. -## Background - ### Bibliography - [Understanding SC 1.2.1: Audio-only and Video-only (Prerecorded)](https://www.w3.org/WAI/WCAG22/Understanding/audio-only-and-video-only-prerecorded) diff --git a/_rules/audio-or-video-avoids-automatically-playing-audio-80f0bf.md b/_rules/audio-or-video-avoids-automatically-playing-audio-80f0bf.md index 47cab004b52..fb014764b01 100755 --- a/_rules/audio-or-video-avoids-automatically-playing-audio-80f0bf.md +++ b/_rules/audio-or-video-avoids-automatically-playing-audio-80f0bf.md @@ -1,6 +1,7 @@ --- id: 80f0bf name: Audio or video element avoids automatically playing audio +rules_format: 1.1 rule_type: composite description: | This rule checks that audio or video that plays automatically does not have audio that lasts for more than 3 seconds or has an audio control mechanism to stop or mute it. @@ -65,22 +66,22 @@ For each test target, the [outcome](#outcome) of at least one of the following r - [Audio Or Video That Plays Automatically Has A Control Mechanism](https://www.w3.org/WAI/standards-guidelines/act/rules/4c31df/) - [Audio Or Video That Plays Automatically Has No Audio That Lasts More Than 3 Seconds](https://www.w3.org/WAI/standards-guidelines/act/rules/aaa1bf/) -## Assumptions +## Background + +The [instruments][instrument] used to pass this rule (if any), must meet all level A Success Criteria in order to fully satisfy [Success Criterion 1.4.2 Audio Control][sc142]. These extra requirements are left out of this rule, and should be tested separately. + +### Assumptions - This rule assumes that it is not possible to satisfy [Success Criterion 1.4.2 Audio Control][sc142] if the total length of the automatically playing audio is more than 3 seconds, even if there are pauses in the sound and no more than 3 seconds in a row with actual sound. - This rule assumes that the [mechanism](https://www.w3.org/TR/WCAG22/#dfn-mechanism) to control the sound must be located in the same [web page][]. Mechanisms located on other pages can still create accessibility issues for users relying on sound to navigate (e.g. screen readers users) since the autoplaying sound will interfere with their ability to find and activate the mechanism. If a [mechanism](https://www.w3.org/TR/WCAG22/#dfn-mechanism) external to the [web page][] is provided, it is possible to fail this rule but still satisfy [Success Criterion 1.4.2 Audio Control][sc142]. - This rule assumes that the [mechanism](https://www.w3.org/TR/WCAG22/#dfn-mechanism) to control the sound must be visible and accessible in order to be effective and usable by all kinds of users. If the mechanism is hidden to some users, it is possible to fail this rule but still satisfy [Success Criterion 1.4.2 Audio Control][sc142]. -## Accessibility Support +### Accessibility Support The native `video` and `audio` controls in several browser and assistive technology combinations are not keyboard accessible and the `video` or `audio` element itself may not be announced. Authors are recommended to use custom controls for keyboard navigation and cross browser accessibility support in general. Some major browsers no longer automatically play the 'video' unless the 'video' is muted. User agents do not always automatically play media, even when an `autoplay` attribute is present. This is done to avoid autoplaying media interrupting the user when they do not want to, especially when the media is likely to contain sound. The decision to respect the `autoplay` attribute or not depends on user settings and previous behavior (interaction with the site). Therefore, some media files may fail this rule but satisfy [Success Criterion 1.4.2 Audio Control][sc142] on some combination of User Agent and user settings. The rule considers that the presence of the `autoplay` attribute is an indication of the author intention to have automatically playing media, and therefore requires the author to provide a mechanism to control the sound. -## Background - -The [instruments][instrument] used to pass this rule (if any), must meet all level A Success Criteria in order to fully satisfy [Success Criterion 1.4.2 Audio Control][sc142]. These extra requirements are left out of this rule, and should be tested separately. - ### Bibliography - [Understanding Success Criterion 1.4.2: Audio Control](https://www.w3.org/WAI/WCAG22/Understanding/audio-control.html) diff --git a/_rules/audio-text-alternative-e7aa44.md b/_rules/audio-text-alternative-e7aa44.md index 20d4af1a8e8..d08d7f5c296 100755 --- a/_rules/audio-text-alternative-e7aa44.md +++ b/_rules/audio-text-alternative-e7aa44.md @@ -1,6 +1,7 @@ --- id: e7aa44 name: Audio element content has text alternative +rules_format: 1.1 rule_type: composite description: | This rule checks that `audio` elements have a text alternative available. @@ -44,16 +45,16 @@ For each test target, the [outcome](#outcome) of at least one of the following r - [`Audio` Element Content Has Transcript](https://www.w3.org/WAI/standards-guidelines/act/rules/2eb176/) - [`Audio` Element Content Is Media Alternative For Text](https://www.w3.org/WAI/standards-guidelines/act/rules/afb423/) -## Assumptions +## Background + +### Assumptions This rule assumes that the language of each test target can be correctly determined (either programmatically or by analyzing the content), and sufficiently understood. -## Accessibility Support +### Accessibility Support There are no accessibility support issues known. -## Background - ### Bibliography - [Understanding SC 1.2.1: Audio-only and Video-only (Prerecorded)](https://www.w3.org/WAI/WCAG22/Understanding/audio-only-and-video-only-prerecorded) diff --git a/_rules/audio-transcript-2eb176.md b/_rules/audio-transcript-2eb176.md index 25a28d92d38..dd50e093274 100755 --- a/_rules/audio-transcript-2eb176.md +++ b/_rules/audio-transcript-2eb176.md @@ -1,6 +1,7 @@ --- id: 2eb176 name: Audio element content has transcript +rules_format: 1.1 rule_type: atomic description: | This rule checks that `audio` elements have a transcript that includes all auditory information. @@ -33,16 +34,16 @@ The auditory information of each test target is available through a text transcr **Note:** A "text transcript" in the context of this rule is defined in WCAG 2 as an [alternative for time based media](https://www.w3.org/TR/WCAG22/#dfn-alternative-for-time-based-media). -## Assumptions +## Background + +### Assumptions There are no assumptions. -## Accessibility Support +### Accessibility Support There are no accessibility support issues known. -## Background - ### Bibliography - [Understanding SC 1.2.1:Audio-only and Video-only (Prerecorded)](https://www.w3.org/WAI/WCAG22/Understanding/audio-only-and-video-only-prerecorded) diff --git a/_rules/auto-play-audio-does-not-exceed-3-seconds-aaa1bf.md b/_rules/auto-play-audio-does-not-exceed-3-seconds-aaa1bf.md index cdad5f0a82e..deb335b81d0 100755 --- a/_rules/auto-play-audio-does-not-exceed-3-seconds-aaa1bf.md +++ b/_rules/auto-play-audio-does-not-exceed-3-seconds-aaa1bf.md @@ -1,6 +1,7 @@ --- id: aaa1bf name: Audio or video element that plays automatically has no audio that lasts more than 3 seconds +rules_format: 1.1 rule_type: atomic description: | `audio` or `video` that plays automatically does not output audio for more than 3 seconds. @@ -41,16 +42,16 @@ For each test target the total audio output does not last more than 3 seconds. **Note:** This rule does not cover single audio instances that play repeatedly for more than three seconds, or multiple audio instances for more than three seconds. The [WCAG Understanding documentation for 1.4.2 Audio Controls](https://www.w3.org/WAI/WCAG22/Understanding/audio-control.html) is ambiguous about how to handle these scenarios. -## Assumptions +## Background + +### Assumptions There are no assumptions. -## Accessibility Support +### Accessibility Support There are no accessibility support issues known. -## Background - ### Bibliography - [Understanding Success Criterion 1.4.2: Audio Control](https://www.w3.org/WAI/WCAG22/Understanding/audio-control.html) diff --git a/_rules/auto-play-audio-has-control-mechanism-4c31df.md b/_rules/auto-play-audio-has-control-mechanism-4c31df.md index b75666df109..3f4fbe9f37f 100755 --- a/_rules/auto-play-audio-has-control-mechanism-4c31df.md +++ b/_rules/auto-play-audio-has-control-mechanism-4c31df.md @@ -1,6 +1,7 @@ --- id: 4c31df name: Audio or video element that plays automatically has a control mechanism +rules_format: 1.1 rule_type: atomic description: | audio or video that plays automatically must have a control mechanism. @@ -47,16 +48,16 @@ For each test target, there is at least one [instrument][] in the same [web page The [instrument][] to pause or stop or turn the audio volume off is [visible](#visible), has an [accessible name](#accessible-name) that is not only [whitespace](#whitespace), and is [included in the accessibility tree](#included-in-the-accessibility-tree). -## Assumptions +## Background + +### Assumptions There are no assumptions. -## Accessibility Support +### Accessibility Support The native `video` and `audio` controls in several browser and assistive technology combinations are not keyboard accessible and the `video` or `audio` element itself may not be announced. Authors are recommended to use custom controls for keyboard navigation and cross browser accessibility support in general. -## Background - ### Bibliography - [Understanding Success Criterion 1.4.2: Audio Control](https://www.w3.org/WAI/WCAG22/Understanding/audio-control.html) diff --git a/_rules/auto-update-text-efbfc7.md b/_rules/auto-update-text-efbfc7.md index 9d9fa658d47..f2aef7b992a 100755 --- a/_rules/auto-update-text-efbfc7.md +++ b/_rules/auto-update-text-efbfc7.md @@ -1,6 +1,7 @@ --- id: efbfc7 name: Text content that changes automatically can be paused, stopped or hidden +rules_format: 1.1 rule_type: atomic description: | This rule checks that for any text content that regularly changes automatically, there are instruments to pause, stop, or hide it or to control its changing frequency. @@ -45,7 +46,13 @@ For each test target there is at least one set of [instruments][instrument], whe **Note:** If there is more than one test target, the same [instrument][] may be used to pause (or stop, or hide or alter the frequency) of several or even all test targets. -## Assumptions +## Background + +The 10 minute time span in the applicability is arbitrary. It is selected so that testing this rule would not become impractical. This 10 minute constraint is not included in WCAG. Content that changes less frequently may fail success criteria 2.2.2 without failing this rule. + +The [instruments][instrument] used to pass this rule (if any), must meet all level A Success Criteria in order to fully satisfy [Success Criterion 2.2.2: Pause, Stop, Hide][sc 2.2.2]. These extra requirements are left out of this rule, and should be tested separately. + +### Assumptions - The auto-updating of the content is not [essential][], which is listed as valid exception to [Success Criterion 2.2.2: Pause, Stop, Hide][sc 2.2.2]. When the auto-updating of content is [essential][] this rule may produce incorrect results. - The content being changed automatically is information. If the automatically changing content is not information (for example, an ASCII rendered spinning icon that does not provide information on what time is left for a process to end or how much progress has been made) the rule might fail but the success criterion might still be satisfied. @@ -55,16 +62,10 @@ For each test target there is at least one set of [instruments][instrument], whe - If there are other ways to control the automatically changing content that do not require the user to interact with the web page, failing this rule might not be a failure of the success criterion. - This rule does not check that the pausing instrument does not tie up the user focus. If that happens, then this rule might pass but the success criterion would not be satisfied. -## Accessibility Support +### Accessibility Support There are no accessibility support issues known. -## Background - -The 10 minute time span in the applicability is arbitrary. It is selected so that testing this rule would not become impractical. This 10 minute constraint is not included in WCAG. Content that changes less frequently may fail success criteria 2.2.2 without failing this rule. - -The [instruments][instrument] used to pass this rule (if any), must meet all level A Success Criteria in order to fully satisfy [Success Criterion 2.2.2: Pause, Stop, Hide][sc 2.2.2]. These extra requirements are left out of this rule, and should be tested separately. - ### Bibliography - [Understanding Success Criterion 2.2.2: Pause, Stop, Hide][sc 2.2.2] diff --git a/_rules/autocomplete-valid-value-73f2c2.md b/_rules/autocomplete-valid-value-73f2c2.md index 44413a68355..f0b4e369f61 100755 --- a/_rules/autocomplete-valid-value-73f2c2.md +++ b/_rules/autocomplete-valid-value-73f2c2.md @@ -1,6 +1,7 @@ --- id: 73f2c2 name: Autocomplete attribute has valid value +rules_format: 1.1 rule_type: atomic description: | This rule checks that the HTML `autocomplete` attribute has a correct value. @@ -42,7 +43,19 @@ Each test target's `autocomplete` [attribute value][] is a [space separated][] l 4. A required token from the [correct autocomplete field][]; then 5. An optional "webauthn" token. -## Assumptions +## Background + +The intent of this rule is to ensure that the `autocomplete` attribute can be used to support personalization. Many users may find it easier to fill out forms if those can be styled or laid out in a way that is familiar to them. Assistive technologies can do this when a form control is marked up in such a way that its purpose can be understood. For instance, assistive technologies could add familiar icons and colors to different fields, making it easier for the user to understand what the form does. + +Many browsers provide auto-filling suggestions even when the control's `type` [attribute value][] is not [appropriate][appropriate field name for the form control] for its `autocomplete` [attribute value][]. The same happens when the `autocomplete` property is queried. However, the `autocomplete` property is not programmatically identifiable if the requirements for the optional tokens are not met. + +The auto-completing feature of the `autocomplete` attribute benefits many users, but it is not required to satisfy success criterion [1.3.5 Identify Input Purpose][sc135]. Setting `autocomplete="off"` on the element's [form owner](https://html.spec.whatwg.org/multipage/form-control-infrastructure.html#form-owner) prevents the user agent from completing it, but it does not prevent the `autocomplete` [attribute value][] from being programmatically identifiable. + +The [fixed value](#73f2c2:fixed-value) condition in the Applicability is excluding `input` elements that do not consider the `autocomplete` attribute, based on their `type` [attribute value][]; `input` elements with a `type` [attribute value][] of `hidden` are excluded by the [hidden](#73f2c2:hidden) condition. + +On an `input` element with a `type` [attribute value][] of `hidden`, the autocomplete attribute wears the [autofill anchor mantle](https://html.spec.whatwg.org/#autofill-anchor-mantle), describing the meaning of the given value. In all other cases, it wears the [autofill expectation mantle](https://html.spec.whatwg.org/#autofill-expectation-mantle). + +### Assumptions The `autocomplete` attribute is used on form fields that correspond to [Input Purposes for User Interface Components](https://www.w3.org/TR/WCAG22/#input-purposes) and collect information about the user. @@ -52,25 +65,13 @@ The `aria-disabled` state is used on `input` elements which are not part of [seq The purpose of a control is programmatically identifiable even when its `autocomplete` [attribute value][] is not an [appropriate field name for the form control][]. -## Accessibility Support +### Accessibility Support - While `autocomplete` is a promising technique for supporting personalization in HTML, support for this in assistive technologies is fairly limited. - 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 fail this rule with some technology but users of other technologies would not experience any accessibility issue. - In some user agents, querying the value of the `autocomplete` property returns an empty string ("") even when the attribute was set according to the rule's expectations. It affects assistive technologies which rely on this property to personalize input fields collecting information about the user. - Authors may assign inappropriate `autocomplete` attribute values. Moreover, HTML specifications restrict certain `autocomplete` attribute values to specific form controls. Mismatches between `autocomplete` attribute values and form control types may or may not lead to a failure of [success criterion 1.3.5 Identify Input Purpose](https://www.w3.org/TR/WCAG22/#identify-input-purpose). However, this rule focuses exclusively on validating valid `autocomplete` attribute values, disregarding their contextual appropriateness. -## Background - -The intent of this rule is to ensure that the `autocomplete` attribute can be used to support personalization. Many users may find it easier to fill out forms if those can be styled or laid out in a way that is familiar to them. Assistive technologies can do this when a form control is marked up in such a way that its purpose can be understood. For instance, assistive technologies could add familiar icons and colors to different fields, making it easier for the user to understand what the form does. - -Many browsers provide auto-filling suggestions even when the control's `type` [attribute value][] is not [appropriate][appropriate field name for the form control] for its `autocomplete` [attribute value][]. The same happens when the `autocomplete` property is queried. However, the `autocomplete` property is not programmatically identifiable if the requirements for the optional tokens are not met. - -The auto-completing feature of the `autocomplete` attribute benefits many users, but it is not required to satisfy success criterion [1.3.5 Identify Input Purpose][sc135]. Setting `autocomplete="off"` on the element's [form owner](https://html.spec.whatwg.org/multipage/form-control-infrastructure.html#form-owner) prevents the user agent from completing it, but it does not prevent the `autocomplete` [attribute value][] from being programmatically identifiable. - -The [fixed value](#73f2c2:fixed-value) condition in the Applicability is excluding `input` elements that do not consider the `autocomplete` attribute, based on their `type` [attribute value][]; `input` elements with a `type` [attribute value][] of `hidden` are excluded by the [hidden](#73f2c2:hidden) condition. - -On an `input` element with a `type` [attribute value][] of `hidden`, the autocomplete attribute wears the [autofill anchor mantle](https://html.spec.whatwg.org/#autofill-anchor-mantle), describing the meaning of the given value. In all other cases, it wears the [autofill expectation mantle](https://html.spec.whatwg.org/#autofill-expectation-mantle). - ### Bibliography - [Understanding Success Criterion 1.3.5: Identify Input Purpose](https://www.w3.org/WAI/WCAG22/Understanding/identify-input-purpose.html) diff --git a/_rules/block-collapsible-3e12e1.md b/_rules/block-collapsible-3e12e1.md index 54d169595c5..56e2dad56be 100755 --- a/_rules/block-collapsible-3e12e1.md +++ b/_rules/block-collapsible-3e12e1.md @@ -1,6 +1,7 @@ --- id: 3e12e1 name: Block of repeated content is collapsible +rules_format: 1.1 rule_type: atomic description: | This rule checks that repeated blocks of content are collapsible @@ -34,16 +35,16 @@ For each [block of repeated content][] in each test target, which is before (in - there exists an [instrument][] to make all nodes in this [block][] not [visible][]; and - there exists an [instrument][] to remove all nodes in this [block][] from the [accessibility tree][included in the accessibility tree]. -## Assumptions +## Background + +### Assumptions There are no assumptions. -## Accessibility Support +### Accessibility Support There are no accessibility support issues known. -## Background - Usually the same [instrument][] removes both [visibility][visible] and [inclusion in the accessibility tree][included in the accessibility tree] of a [block of repeated content][]. That [instrument][] may remove all [blocks of repeated content][block of repeated content]. If there is no [block of repeated content][] before the non-repeated content the rule passes. [Technique SCR28: Using an expandable and collapsible menu to bypass block of content][tech scr28] does not have any requirements concerning the location of the [instruments][instrument] in relation to the [block of repeated content][] they control, hence this rule doesn't. It is likely a good idea to either keep each [instrument][] close to the start of the [block of repeated content][] it controls; or to group them all in one place near the start of the document. Notably, [instruments][instrument] located after (in reading order) the block they collapse are likely not satisfying [Success Criterion 2.4.1 Bypass blocks][sc241], which this rule is designed for. Thus, it is possible to pass this rule without satisfying [Success Criterion 2.4.1 Bypass blocks][sc241]. diff --git a/_rules/button-non-empty-accessible-name-97a4e1.md b/_rules/button-non-empty-accessible-name-97a4e1.md index 253722c4477..f9b0672ecc6 100755 --- a/_rules/button-non-empty-accessible-name-97a4e1.md +++ b/_rules/button-non-empty-accessible-name-97a4e1.md @@ -1,6 +1,7 @@ --- id: 97a4e1 name: Button has non-empty accessible name +rules_format: 1.1 rule_type: atomic description: | This rule checks that each `button` element has a non-empty accessible name. @@ -30,20 +31,20 @@ This rule applies to elements that are [included in the accessibility tree][] an Each target element has an [accessible name][] that is not empty (`""`). -## Assumptions +## Background + +This rule considers an exception for "image buttons" (i.e., `input` elements with a `type` [attribute value] of `image`). Image buttons failing this rule would fail [Success Criterion 4.1.2](https://www.w3.org/WAI/WCAG22/Understanding/name-role-value) and [Success Criterion 1.1.1](https://www.w3.org/WAI/WCAG22/Understanding/non-text-content) which is not part of the accessibility requirements for this rule. + +### Assumptions - The rule assumes that all buttons are [user interface components as defined by WCAG 2](https://www.w3.org/TR/WCAG22/#dfn-user-interface-components). -## Accessibility Support +### 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 `button` and fail this rule with some technology but users of other technologies would not experience any accessibility issue. - Some elements have a role of `button` and a default accessible name defined by the [HTML Accessibility API Mapping][html aam input button], for example `input` elements whose `type` [attribute value][] is either `submit` or `reset`. This rule considers that these default names can be descriptive and therefore does not fail them. -## Background - -This rule considers an exception for "image buttons" (i.e., `input` elements with a `type` [attribute value] of `image`). Image buttons failing this rule would fail [Success Criterion 4.1.2](https://www.w3.org/WAI/WCAG22/Understanding/name-role-value) and [Success Criterion 1.1.1](https://www.w3.org/WAI/WCAG22/Understanding/non-text-content) which is not part of the accessibility requirements for this rule. - ### Related rules - [Image button has non-empty accessible name](https://www.w3.org/WAI/standards-guidelines/act/rules/59796f/) diff --git a/_rules/bypass-blocks-cf77f2.md b/_rules/bypass-blocks-cf77f2.md index 1375bc09411..3297dc71d10 100755 --- a/_rules/bypass-blocks-cf77f2.md +++ b/_rules/bypass-blocks-cf77f2.md @@ -1,6 +1,7 @@ --- id: cf77f2 name: Bypass Blocks of Repeated Content +rules_format: 1.1 rule_type: composite description: | This rule checks that each page has a mechanism to bypass repeated blocks of content. @@ -64,7 +65,11 @@ For each test target, the outcome of at least one of the following rules is pass - [_Document has a landmark with non-repeated content_][document has landmark]; or - [_Document has an instrument to move focus to non-repeated content_][document has instrument to main]. -## Assumptions +## Background + +The [instruments][instrument] used to pass this rule (if any), must meet all level A Success Criteria in order to fully satisfy [Success Criterion 2.4.1 Bypass Block][sc241]. These extra requirements are left out of this rule, and should be tested separately. + +### Assumptions - This rule assumes that the mean to bypass blocks is included in the content of the [HTML web page][]. For example, server-side scripting, or a global "settings" page, can provide a functionality similar to [_Block of repeated content is collapsible_][block collapsible] by serving a modified version of the page; in which case this rule would fail but [Success Criterion 2.4.1 Bypass blocks][sc241] could nonetheless be satisfied. - This rule assumes that `frame` and `frameset` elements are not used, given that they are deprecated in HTML5. They can be used to organize content as per [H70: Using frame elements to group blocks of repeated material](https://www.w3.org/WAI/WCAG22/Techniques/html/H70) and [H64: Using the title attribute of the frame and iframe elements](https://www.w3.org/WAI/WCAG22/Techniques/html/H64), in that case, this rule would fail but [Success Criterion 2.4.1 Bypass blocks][sc241] could nonetheless be satisfied. @@ -72,7 +77,7 @@ For each test target, the outcome of at least one of the following rules is pass - This rule assumes that repeated content that is at the end of the page (and not followed any non-repeated content) can be bypassed by means provided by user agents (such as pressing the "End" key to scroll to the bottom of the page). Therefore, they do not need any other way of being bypassed and are ignored by this rule. If there isn't a way to bypass them, this rule may pass while [Success Criterion 2.4.1 Bypass blocks][sc241] is not satisfied. - This rule assumes that the language of each test target can be correctly determined (either programmatically or by analyzing the content), and sufficiently understood. -## Accessibility Support +### Accessibility Support Techniques and solutions that identify blocks of content are sufficient ways of passing [Success Criterion 2.4.1 Bypass blocks][sc241]. They are, however, only beneficial for users who have ways of navigating with this information. For example, adding headings to a document will only help users who can "jump" from heading to heading (such a possibility can be provided by browsers, browsers plugins, screen readers, or other assistive technologies). Techniques and solutions based on links will benefit all users (for example, sighted keyboard users with no other assistive technology) and are therefore recommended. @@ -80,10 +85,6 @@ If the [instruments][instrument] used to pass some of the atomic rules are not k This rule only checks if there is a way to bypass at least one section of repeated content. On pages with several interleaved repeated and non-repeated content, this is not sufficient to satisfy [Success Criterion 2.4.1 Bypass blocks][sc241]. Checking for more sections to bypass was considered but rejected due to both the added complexity it would create, and the risk of failing on pages that might be correct. -## Background - -The [instruments][instrument] used to pass this rule (if any), must meet all level A Success Criteria in order to fully satisfy [Success Criterion 2.4.1 Bypass Block][sc241]. These extra requirements are left out of this rule, and should be tested separately. - ### Bibliography - [Understanding Success Criterion 2.4.1: Bypass Blocks][usc241] diff --git a/_rules/css-restrict-orientation-b33eff.md b/_rules/css-restrict-orientation-b33eff.md index f1e08b1707b..b1b61bd4d47 100755 --- a/_rules/css-restrict-orientation-b33eff.md +++ b/_rules/css-restrict-orientation-b33eff.md @@ -1,6 +1,7 @@ --- id: b33eff name: Orientation of the page is not restricted using CSS transforms +rules_format: 1.1 rule_type: atomic description: | This rule checks that page content is not restricted to either `landscape` or `portrait` orientation using CSS transforms @@ -45,7 +46,9 @@ The target element is neither rotated clockwise nor counter clockwise around the **Note:** Imagine the display of a smartphone with cartoon figure at its center. With this example, if a user turns the smartphone a quarter turn, that is a partial move from one orientation to the other, the user would expect that the cartoon figure continues to remain facing upwards. The smartphone accomplishes this by rotating the contents of its display a quarter turn to counter the users change in orientation. In effect, the cartoon figure has remained in place and its rotation relative from one orientation to the other is 0 degrees. Now imagine that a developer facilitated this rotation of the cartoon figure by a quarter turn _only_ when the smartphone starts from one orientation and not the other; its rotation relative from one orientation to the other would then be 90 degrees and it would appear stuck, or locked, as the user moves between orientations. What the developer has done is effectively counter the smartphone's attempt at countering the user's change in orientation. -## Assumptions +## Background + +### Assumptions This rule does not consider and may produce incorrect results for: @@ -53,12 +56,10 @@ This rule does not consider and may produce incorrect results for: - The existence of any control on the page that can change the orientation on demand. - Scripts are not used to adjust the CSS orientation lock. -## Accessibility Support +### Accessibility Support There are no accessibility support issues known. -## Background - ### Bibliography - [Understanding Success Criterion 1.3.4: Orientation](https://www.w3.org/WAI/WCAG22/Understanding/orientation.html) diff --git a/_rules/device-motion-disabled-c249d5.md b/_rules/device-motion-disabled-c249d5.md index 6fd8e663e79..1a3d6c9c2e2 100755 --- a/_rules/device-motion-disabled-c249d5.md +++ b/_rules/device-motion-disabled-c249d5.md @@ -1,6 +1,7 @@ --- id: c249d5 name: Device motion based changes to the content can be disabled +rules_format: 1.1 rule_type: atomic description: | This rule checks that it is possible to disable any changes to the content of the web page resulting from device motion based events. @@ -37,7 +38,11 @@ For each registered [device orientation event][device orientation] or [device mo - **no changes:** The registered event does not cause [changes to the content][changes in content] of the [web page][] within a 1 minute time span of the [event firing][event firing]; or - **disabled:** There is at least one [set of clearly labeled instruments][] to [block the event][blocked event][] for at least 1 minute. -## Assumptions +## Background + +The [instruments][instrument] used to pass this rule (if any), must meet all level A Success Criteria in order to fully satisfy [Success Criterion 2.5.4: Motion Actuation][sc2.5.4]. These extra requirements are left out of this rule, and should be tested separately. + +### Assumptions - The motion to operate the device is not used through an [accessibility supported][] interface, which is listed as a valid exception to [Success Criterion 2.5.4: Motion Actuation][sc2.5.4]. - The motion is not [essential][] for the functionality it triggers, which is listed as a valid exception to [Success Criterion 2.5.4: Motion Actuation][sc2.5.4]. @@ -47,14 +52,10 @@ For each registered [device orientation event][device orientation] or [device mo - This rule assumes that the changes happen within a 1 minute time span after the [event][] [firing][] and therefore the comparison between the page before and after the [event][] [firing][] can be made at any time after that time span elapses. If there are changes after this time span, they may not be detected as [changes in content][] and the rule may pass but [Success Criterion 2.5.4: Motion Actuation][sc2.5.4] is not satisfied. The arbitrary 1 minute time span, selected so that testing this rule would not be impractical, is not included in WCAG. - After being disabled, the event remains disabled until being re-enabled again. If the event is re-enabled through other non-user controlled means (e.g. a timeout) then this rule may pass while [Success Criterion 2.5.4: Motion Actuation][sc2.5.4] is not satisfied. -## Accessibility Support +### Accessibility Support There are no accessibility support issues known. -## Background - -The [instruments][instrument] used to pass this rule (if any), must meet all level A Success Criteria in order to fully satisfy [Success Criterion 2.5.4: Motion Actuation][sc2.5.4]. These extra requirements are left out of this rule, and should be tested separately. - ### Bibliography - [Understanding Success Criterion 2.5.4: Motion Actuation][sc2.5.4] diff --git a/_rules/device-motion-user-interface-7677a9.md b/_rules/device-motion-user-interface-7677a9.md index e3bea3a8deb..9b6d137b8d0 100755 --- a/_rules/device-motion-user-interface-7677a9.md +++ b/_rules/device-motion-user-interface-7677a9.md @@ -1,6 +1,7 @@ --- id: 7677a9 name: Device motion based changes to the content can also be created from the user interface +rules_format: 1.1 rule_type: atomic description: | This rule checks that changes to the content of a web page that result from device motion events can also be caused by user interface components. @@ -37,21 +38,21 @@ For each registered [device orientation event][device orientation] or [device mo - **no changes:** The registered event does not cause [changes to the content][changes in content] of the [web page][]; or - **same result:** There is at least one set of [instruments][instrument], where each [instrument][] is in the same [web page][] of the registered event or can be found in a [clearly labeled location][] from that [web page][], causing the same [changes in content][] as the event. -## Assumptions +## Background + +The [instruments][instrument] used to pass this rule (if any), must meet all level A Success Criteria in order to fully satisfy [Success Criterion 2.5.4: Motion Actuation][sc2.5.4]. These extra requirements are left out of this rule, and should be tested separately. + +### Assumptions - The motion to operate the device is not used through an [accessibility supported][] interface, which is listed as a valid exception to [Success Criterion 2.5.4: Motion Actuation][sc2.5.4]. - The motion is not [essential][] for the functionality it triggers, which is listed as a valid exception to [Success Criterion 2.5.4: Motion Actuation][sc2.5.4]. - This rule assumes that there are no changes in the content of the [web page][] caused by another [event][]. If this is not the case, changes may be attributed to the wrong [event][] and the rule may fail while [Success Criterion 2.5.4: Motion Actuation][sc2.5.4] is still satisfied. - This rule assumes that the changes happen within a 1 minute time span after the [event][] [firing][] and therefore the comparison between the page before and after the [event][] [firing][] can be made at any time after that time span elapses. If there are changes after this time span, they may not be detected as [changes in content][] and the rule may pass but [Success Criterion 2.5.4: Motion Actuation][sc2.5.4] is not satisfied. The arbitrary 1 minute time span, selected so that testing this rule would not be impractical, is not included in WCAG. -## Accessibility Support +### Accessibility Support There are no accessibility support issues known. -## Background - -The [instruments][instrument] used to pass this rule (if any), must meet all level A Success Criteria in order to fully satisfy [Success Criterion 2.5.4: Motion Actuation][sc2.5.4]. These extra requirements are left out of this rule, and should be tested separately. - ### Bibliography - [Understanding Success Criterion 2.5.4: Motion Actuation][sc2.5.4] diff --git a/_rules/document-has-headings-for-non-repeated-content-047fe0.md b/_rules/document-has-headings-for-non-repeated-content-047fe0.md index 32ccdeea247..abf74b7152f 100755 --- a/_rules/document-has-headings-for-non-repeated-content-047fe0.md +++ b/_rules/document-has-headings-for-non-repeated-content-047fe0.md @@ -1,6 +1,7 @@ --- id: 047fe0 name: Document has heading for non-repeated content +rules_format: 1.1 rule_type: atomic description: | This rule checks that the non-repeated content contains a heading @@ -37,22 +38,22 @@ In each test target, either there is no [non-repeated content after repeated con - the element is [visible][]; and - the element is [included in the accessibility tree][]. -## Assumptions +## Background + +The intention of this rule is that the heading is at (or near) the start of the main area of content of a document. However, defining the main area of content in a non-ambiguous way is not really doable. Therefore, the rule takes a more lenient position and only requires the heading to be some non-repeated content. Additional conditions on this heading were considered and rejected when writing the rule since it might be acceptable, for example, to have non-repeated content such as breadcrumb before any heading. Therefore, it is possible to pass this rule but still fail [H69: Providing heading elements at the beginning of each section of content][h69] and violate [Success Criterion 2.4.1 Bypass blocks][sc241]. + +Neither this rule, nor technique [H69: Providing heading elements at the beginning of each section of content][h69], expects the heading to accurately describe its corresponding section. However, having non descriptive headings fails [Success Criterion 2.4.6: Headings and Labels](https://www.w3.org/TR/WCAG22/#headings-and-labels) + +### Assumptions - This rule assumes that headings used to pass [Technique H69: Providing heading elements at the beginning of each section of content][h69] have to be [included in the accessibility tree][] in order to be beneficial to users of assistive technologies. - This rule assumes that the first non-repeated content is starting a new section of content. If this is not the case, it is possible to fail the rule while still passing [Technique H69: Providing heading elements at the beginning of each section of content][h69]. -## Accessibility Support +### Accessibility Support - Having a heading for the non-repeated content is sufficient to pass [Success Criterion 2.4.1 Bypass blocks][sc241]. However, if headings are used for that goal, they will only benefit users who can actually navigate from heading to heading (such a functionality can be provided by browsers, browsers plugins, screen readers or other assistive technologies). Users without any possibility for headings navigation will be left without way of bypassing blocks of repeated content and will still experience accessibility issues. Therefore, it is recommended to provide other ways of bypassing blocks. - When headings are rendered without sufficient visual cues, they are not perceived as headings by sighted users. In this case, passing this rule might still fail [Technique H69: Providing heading elements at the beginning of each section of content][h69] and [Success Criterion 2.4.1 Bypass blocks][sc241]. Additionally, this is likely a failure of [Success Criterion 1.3.1 Info and Relationships][sc131]. -## Background - -The intention of this rule is that the heading is at (or near) the start of the main area of content of a document. However, defining the main area of content in a non-ambiguous way is not really doable. Therefore, the rule takes a more lenient position and only requires the heading to be some non-repeated content. Additional conditions on this heading were considered and rejected when writing the rule since it might be acceptable, for example, to have non-repeated content such as breadcrumb before any heading. Therefore, it is possible to pass this rule but still fail [H69: Providing heading elements at the beginning of each section of content][h69] and violate [Success Criterion 2.4.1 Bypass blocks][sc241]. - -Neither this rule, nor technique [H69: Providing heading elements at the beginning of each section of content][h69], expects the heading to accurately describe its corresponding section. However, having non descriptive headings fails [Success Criterion 2.4.6: Headings and Labels](https://www.w3.org/TR/WCAG22/#headings-and-labels) - ### Bibliography - [Understanding Success Criterion 2.4.1: Bypass Blocks][usc241] diff --git a/_rules/document-has-instrument-to-non-repeated-content-ye5d6e.md b/_rules/document-has-instrument-to-non-repeated-content-ye5d6e.md index 40e7d86d605..f43fd80daa1 100755 --- a/_rules/document-has-instrument-to-non-repeated-content-ye5d6e.md +++ b/_rules/document-has-instrument-to-non-repeated-content-ye5d6e.md @@ -1,6 +1,7 @@ --- id: ye5d6e name: Document has an instrument to move focus to non-repeated content +rules_format: 1.1 rule_type: atomic description: | This rule checks that there is an instrument to move focus to non-repeated content in the page @@ -42,19 +43,19 @@ This rule applies to any [HTML web page][]. For each test target, there exists at least one [instrument][] inside it to move focus [just before][] a node of [non-repeated content after repeated content][]. -## Assumptions +## Background -This rule assumes that there is at least one [block of repeated content][] before the non-repeated content, and therefore [Technique G123: Adding a link at the beginning of a block of repeated content to go to the end of the block][tech g123] will require a link to the non-repeated content in order to skip this [block of repeated content][]. If there is no [block of repeated content][] before the non-repeated content, then it is possible to fail this rule but still pass [Technique G123: Adding a link at the beginning of a block of repeated content to go to the end of the block][tech g123]. +The intention of this rule is that focus is moved to the main area of content of a document. However, defining the main area of content in a non-ambiguous way is not really doable. Therefore, the rule takes a more lenient position and only requires to move focus to some non-repeated content. Additional conditions on this destination were considered and rejected when writing the rule since it might be acceptable, for example, to skip the first heading of the main area of content if it has the exact same content as the `title` element of the document. Therefore, it is possible to pass this rule but still fail the related techniques and violate [Success Criterion 2.4.1 Bypass blocks][sc241]. -## Accessibility Support +While it is clear that a "skip link" is a valid way to satisfy [Success Criterion 2.4.1 Bypass blocks][sc241], it is less clear how "deep" in the page such a skip link could be. Notably, [Technique G124: Adding links at the top of the page to each area of the content][tech g124] is listing valid cases where it could be fairly "deep" if the page has many areas of the content. Rather than trying to fix an arbitrary value (e.g. "the skip link must be among the first 5 focusable elements"), or trying to figure out some condition on what precedes it, this rule only checks its existence. It is clear that if no "skip link" is provided, then another way to bypass blocks of repeated content must be found. However, it is possible to pass this rule without satisfying [Success Criterion 2.4.1 Bypass blocks][sc241] if the skip link is too far away from the start of the page. -There are no accessibility support issues known. +### Assumptions -## Background +This rule assumes that there is at least one [block of repeated content][] before the non-repeated content, and therefore [Technique G123: Adding a link at the beginning of a block of repeated content to go to the end of the block][tech g123] will require a link to the non-repeated content in order to skip this [block of repeated content][]. If there is no [block of repeated content][] before the non-repeated content, then it is possible to fail this rule but still pass [Technique G123: Adding a link at the beginning of a block of repeated content to go to the end of the block][tech g123]. -The intention of this rule is that focus is moved to the main area of content of a document. However, defining the main area of content in a non-ambiguous way is not really doable. Therefore, the rule takes a more lenient position and only requires to move focus to some non-repeated content. Additional conditions on this destination were considered and rejected when writing the rule since it might be acceptable, for example, to skip the first heading of the main area of content if it has the exact same content as the `title` element of the document. Therefore, it is possible to pass this rule but still fail the related techniques and violate [Success Criterion 2.4.1 Bypass blocks][sc241]. +### Accessibility Support -While it is clear that a "skip link" is a valid way to satisfy [Success Criterion 2.4.1 Bypass blocks][sc241], it is less clear how "deep" in the page such a skip link could be. Notably, [Technique G124: Adding links at the top of the page to each area of the content][tech g124] is listing valid cases where it could be fairly "deep" if the page has many areas of the content. Rather than trying to fix an arbitrary value (e.g. "the skip link must be among the first 5 focusable elements"), or trying to figure out some condition on what precedes it, this rule only checks its existence. It is clear that if no "skip link" is provided, then another way to bypass blocks of repeated content must be found. However, it is possible to pass this rule without satisfying [Success Criterion 2.4.1 Bypass blocks][sc241] if the skip link is too far away from the start of the page. +There are no accessibility support issues known. ### Bibliography diff --git a/_rules/document-has-landmark-with-non-repeated-content-b40fd1.md b/_rules/document-has-landmark-with-non-repeated-content-b40fd1.md index 51f64e77d02..225e33db8c9 100755 --- a/_rules/document-has-landmark-with-non-repeated-content-b40fd1.md +++ b/_rules/document-has-landmark-with-non-repeated-content-b40fd1.md @@ -1,6 +1,7 @@ --- id: b40fd1 name: Document has a landmark with non-repeated content +rules_format: 1.1 rule_type: atomic description: | This rule checks that each page has an element with a landmark semantic role starting with non-repeated content @@ -32,19 +33,19 @@ Within each test target, either there is no [non-repeated content after repeated - the first [perceivable content][] (in [tree order][] in the [flat tree][]) which is an [inclusive descendant][] of the element is [non-repeated content after repeated content][]; and - the element is [included in the accessibility tree][]. -## Assumptions +## Background -- This rule assumes that [landmarks][landmark] are intended to users of Assistive Technologies and are not necessarily rendered in a visible way. Therefore, it does not require the main landmark to be [visible][]. Similarly, technique [ARIA11: Using ARIA landmarks to identify regions of a page][tech aria11] does not require landmarks to be [visible][] or have [visible][] content. +Most of the time, this rule passes by enclosing the primary content of the page in a `main` landmark. -## Accessibility Support +[Technique ARIA11: Using ARIA landmarks to identify regions of a page][tech aria11] only checks that landmarks are correctly used, but does not check whether landmarks could have been used and were omitted. Therefore, failing this rule (not having enough landmarks) does not necessarily fail that technique, and it is not listed as an accessibility mapping. -Marking content with landmarks is sufficient to pass [Success Criterion 2.4.1 Bypass blocks][sc241]. However, this will only benefit users who can actually navigate using landmark roles (such a functionality is usually provided by assistive technologies, but could also be provided by browsers or browsers plugins). Users without any possibility for landmarks navigation will be left without way of bypassing blocks of repeated content and will still experience accessibility issues. Therefore, it is recommended to provide other ways of bypassing blocks. +### Assumptions -## Background +- This rule assumes that [landmarks][landmark] are intended to users of Assistive Technologies and are not necessarily rendered in a visible way. Therefore, it does not require the main landmark to be [visible][]. Similarly, technique [ARIA11: Using ARIA landmarks to identify regions of a page][tech aria11] does not require landmarks to be [visible][] or have [visible][] content. -Most of the time, this rule passes by enclosing the primary content of the page in a `main` landmark. +### Accessibility Support -[Technique ARIA11: Using ARIA landmarks to identify regions of a page][tech aria11] only checks that landmarks are correctly used, but does not check whether landmarks could have been used and were omitted. Therefore, failing this rule (not having enough landmarks) does not necessarily fail that technique, and it is not listed as an accessibility mapping. +Marking content with landmarks is sufficient to pass [Success Criterion 2.4.1 Bypass blocks][sc241]. However, this will only benefit users who can actually navigate using landmark roles (such a functionality is usually provided by assistive technologies, but could also be provided by browsers or browsers plugins). Users without any possibility for landmarks navigation will be left without way of bypassing blocks of repeated content and will still experience accessibility issues. Therefore, it is recommended to provide other ways of bypassing blocks. ### Bibliography diff --git a/_rules/element-lang-matches-default-language-off6ek.md b/_rules/element-lang-matches-default-language-off6ek.md index 193a6717220..19ce1f21faf 100644 --- a/_rules/element-lang-matches-default-language-off6ek.md +++ b/_rules/element-lang-matches-default-language-off6ek.md @@ -1,6 +1,7 @@ --- id: off6ek name: HTML element language subtag matches language +rules_format: 1.1 rule_type: atomic description: | This rule checks that the primary language subtag of an element matches its default language @@ -44,7 +45,11 @@ This rule applies to any [HTML element][] with a `lang` attribute for which all For each test target, the [primary language][] of its `lang` [attribute value][] is a [most common language][] of the test target. -## Assumptions +## Background + +This rule checks that, if a `lang` attribute is used, its value is correct with respect to the content. This rule does not check whether a `lang` attribute should have been used or not. Especially, this rule does not check when `lang` attributes are missing. This must be tested separately and it is therefore possible to pass this rule without satisfying [Success Criterion 3.1.2 Language of Parts](https://www.w3.org/TR/WCAG22/#language-of-parts). + +### Assumptions - This rule assumes that user agents and assistive technologies can programmatically determine [known primary language tags][known primary language tag] even on [language tags][rfc 5646] that do not conform to the [RFC 5646][] syntax. @@ -52,14 +57,10 @@ For each test target, the [primary language][] of its `lang` [attribute value][] - This rule assumes that the text nodes contain text that express something in [human language][] and therefore need a correct programmatic language. -## Accessibility Support +### Accessibility Support There are no accessibility support issues known. -## Background - -This rule checks that, if a `lang` attribute is used, its value is correct with respect to the content. This rule does not check whether a `lang` attribute should have been used or not. Especially, this rule does not check when `lang` attributes are missing. This must be tested separately and it is therefore possible to pass this rule without satisfying [Success Criterion 3.1.2 Language of Parts](https://www.w3.org/TR/WCAG22/#language-of-parts). - ### Related rules - [_Element with `lang` Attribute Has Valid Language Tag_](https://www.w3.org/WAI/standards-guidelines/act/rules/de46e4/) diff --git a/_rules/element-lang-valid-de46e4.md b/_rules/element-lang-valid-de46e4.md index 18baddbac22..d44d157c07b 100755 --- a/_rules/element-lang-valid-de46e4.md +++ b/_rules/element-lang-valid-de46e4.md @@ -1,6 +1,7 @@ --- id: de46e4 name: Element with lang attribute has valid language tag +rules_format: 1.1 rule_type: atomic description: | This rule checks that a non-empty `lang` attribute of an element in the page has a language tag with a known primary language subtag. @@ -39,7 +40,9 @@ This rule applies to any [HTML element][] with a `lang` [attribute value][] that For each test target, the `lang` [attribute value][] has a [known primary language tag][]. -## Assumptions +## Background + +### Assumptions - This rule assumes that the `lang` [attribute value][] is used to indicate the language of a section of the content. If the `lang` [attribute value][] is used for something else (for example to indicate the programming language of a `code` element), the content may still conform to WCAG despite failing this rule. @@ -49,12 +52,10 @@ For each test target, the `lang` [attribute value][] has a [known primary langua - This rule assumes that the text nodes contain text that express something in [human language][] and therefore need a correct programmatic language. -## Accessibility Support +### Accessibility Support There are differences in how assistive technologies handle unknown and invalid language tags. Some will default to the language of the page, whereas others will default to the closest ancestor with a valid lang attribute. -## Background - ### Bibliography - [CSS Scoping Module Level 1 (editor's draft)](https://drafts.csswg.org/css-scoping/) diff --git a/_rules/element-marked-decorative-is-not-exposed-46ca7f.md b/_rules/element-marked-decorative-is-not-exposed-46ca7f.md index 3153f81e41b..1b51b592b13 100755 --- a/_rules/element-marked-decorative-is-not-exposed-46ca7f.md +++ b/_rules/element-marked-decorative-is-not-exposed-46ca7f.md @@ -1,6 +1,7 @@ --- id: 46ca7f name: Element marked as decorative is not exposed +rules_format: 1.1 rule_type: atomic description: | This rule checks that elements marked as decorative either are not included in the accessibility tree, or have a presentational role. @@ -28,14 +29,6 @@ This rule applies to any element which is [marked as decorative][]. Each target element either is not [included in the accessibility tree][] or has a [semantic role][] of `none` or `presentation`. -## Assumptions - -There are no assumptions. - -## Accessibility Support - -Implementation of the [Presentational Roles Conflict Resolution][] differs slightly from one user agent to the other. Hence, some elements might be exposed by one user agent and not by another, and consequently might create accessibility issues only for some users. Nevertheless, triggering the conflict is a bad practice. - ## Background Elements are normally [marked as decorative][] to convey the intention of the author that they are [pure decoration][decorative] and thus shouldn't be exposed to assistive technologies. On the other hand, elements that are [focusable][] are important to know for anybody and should be exposed to assistive technologies; and elements that are defining any [global ARIA attribute][] indicate an intention to communicate something to the assistive technologies (through the `aria-*` attribute). When an element is both [marked as decorative][] and either [focusable][] or defining a [global ARIA attribute][], a conflict arises between these two intentions. The [conflict is resolved][presentational roles conflict resolution] by exposing the element. @@ -44,6 +37,14 @@ Whenever such a conflict occurs, this indicates at the very least mismatching in When these conflicts arise on [decorative][] [non-text content][], this is also a failure of [Success Criterion 1.1.1: Non-text Content][sc111] because [decorative][] [non-text content][] must be implemented in a way that allows assistive technologies to ignore it. When these conflicts arise on text content, or on content which is not [decorative][], this is not a failure of WCAG. Therefore this rule is not mapping to any specific WCAG Success Criterion, and is not an accessibility requirement for WCAG. +### Assumptions + +There are no assumptions. + +### Accessibility Support + +Implementation of the [Presentational Roles Conflict Resolution][] differs slightly from one user agent to the other. Hence, some elements might be exposed by one user agent and not by another, and consequently might create accessibility issues only for some users. Nevertheless, triggering the conflict is a bad practice. + ## Test Cases ### Passed diff --git a/_rules/explicit-SVG-image-non-empty-accessible-name-7d6734.md b/_rules/explicit-SVG-image-non-empty-accessible-name-7d6734.md index b1be180463d..b857fdf098c 100755 --- a/_rules/explicit-SVG-image-non-empty-accessible-name-7d6734.md +++ b/_rules/explicit-SVG-image-non-empty-accessible-name-7d6734.md @@ -1,6 +1,7 @@ --- id: 7d6734 name: SVG element with explicit role has non-empty accessible name +rules_format: 1.1 rule_type: atomic description: | This rule checks that each SVG image element that is explicitly included in the accessibility tree has a non-empty accessible name. @@ -28,11 +29,13 @@ This rule applies to any [SVG element][] with an [explicit semantic role][explic Each target element has an [accessible name][] that is not empty. -## Assumptions +## Background + +### Assumptions This rule assumes that the presence of one of the roles outlined in the applicability indicates the author's intent to include the element in the accessibility tree and thus convey information to the user about that element. -## Accessibility Support +### Accessibility Support The [HTML Accessibility API Mappings](https://www.w3.org/TR/html-aam-1.0/#html-element-role-mappings) specify that the `` element has an implicit role of `graphics-document`. However browser support for the `graphics-document` role and the [SVG Accessibility API Mappings][] is inconsistent. @@ -42,8 +45,6 @@ Browser and assistive technology support for SVG `` and `` elements Until browser support for the [SVG Accessibility API Mappings][] is more consistent it is recommended to explicitly remove decorative `` elements from the accessibility tree. -## Background - ### Bibliography - [Understanding Success Criterion 1.1.1: Non-text Content](https://www.w3.org/WAI/WCAG22/Understanding/non-text-content.html) diff --git a/_rules/focusable-no-keyboard-trap-80af7b.md b/_rules/focusable-no-keyboard-trap-80af7b.md index 135bd432df4..1872cb5e8d3 100755 --- a/_rules/focusable-no-keyboard-trap-80af7b.md +++ b/_rules/focusable-no-keyboard-trap-80af7b.md @@ -1,6 +1,7 @@ --- id: 80af7b name: Focusable element has no keyboard trap +rules_format: 1.1 rule_type: composite description: | This rule checks for keyboard traps. This includes use of both standard and non-standard keyboard navigation to navigate through all content without becoming trapped. @@ -44,17 +45,17 @@ For each test target, the [outcome](#outcome) of at least one of the following r - [Focusable Element Has No Keyboard Trap Via Standard Navigation](https://www.w3.org/WAI/standards-guidelines/act/rules/a1b64e/) - [Focusable Element Has No Keyboard Trap Via Non-Standard Navigation](https://www.w3.org/WAI/standards-guidelines/act/rules/ebe86a/) -## Assumptions +## Background -There are no assumptions. +This rule only requires navigation in one direction (either forward or backward), not both, and not a specific one. It is clear that not being able to escape a focus trap in any direction is a failure of [Success Criterion 2.1.2 No keyboard trap][sc212]. However, it is less clear that being able to escape in only one direction is enough to satisfy it. If [Success Criterion 2.1.2 No keyboard trap][sc212] requires the possibility to escape the trap in a specific way (e.g. forward [standard keyboard navigation](#standard-keyboard-navigation)) or in both directions, this rule may pass while the criterion is not satisfied. -## Accessibility Support +### Assumptions -There are no accessibility support issues known. +There are no assumptions. -## Background +### Accessibility Support -This rule only requires navigation in one direction (either forward or backward), not both, and not a specific one. It is clear that not being able to escape a focus trap in any direction is a failure of [Success Criterion 2.1.2 No keyboard trap][sc212]. However, it is less clear that being able to escape in only one direction is enough to satisfy it. If [Success Criterion 2.1.2 No keyboard trap][sc212] requires the possibility to escape the trap in a specific way (e.g. forward [standard keyboard navigation](#standard-keyboard-navigation)) or in both directions, this rule may pass while the criterion is not satisfied. +There are no accessibility support issues known. ### Bibliography diff --git a/_rules/focusable-no-keyboard-trap-non-standard-nav-ebe86a.md b/_rules/focusable-no-keyboard-trap-non-standard-nav-ebe86a.md index f457c14ab06..af0037814a2 100755 --- a/_rules/focusable-no-keyboard-trap-non-standard-nav-ebe86a.md +++ b/_rules/focusable-no-keyboard-trap-non-standard-nav-ebe86a.md @@ -1,6 +1,7 @@ --- id: ebe86a name: Focusable element has no keyboard trap via non-standard navigation +rules_format: 1.1 rule_type: atomic description: | This rule checks if it is possible to use non-standard keyboard navigation to navigate through content where focus is trapped when using standard ways of keyboard navigation. @@ -41,17 +42,17 @@ For each target element focus can cycle to the browser UI by using the method ad **Note:** Cycling back to the browser UI can be done both by moving forward through the tab order and by moving backwards. It is not possible to fulfill this expectation by using browser specific shortcuts to return to the browser UI. -## Assumptions +## Background + +### Assumptions - It is not possible to use unmodified arrow or tab keys, or other standard exit methods to move focus away. - The focus order in keyboard navigation is cyclical, not linear, meaning that the focus order will cycle to the first/last element when it moves away from the last/first element. -## Accessibility Support +### Accessibility Support There are no accessibility support issues known. -## Background - ### Bibliography - [Understanding Success Criterion 2.1.2: No Keyboard Trap](https://www.w3.org/WAI/WCAG22/Understanding/no-keyboard-trap.html) diff --git a/_rules/focusable-no-keyboard-trap-standard-nav-a1b64e.md b/_rules/focusable-no-keyboard-trap-standard-nav-a1b64e.md index d48dba0605a..63dbb1ea998 100755 --- a/_rules/focusable-no-keyboard-trap-standard-nav-a1b64e.md +++ b/_rules/focusable-no-keyboard-trap-standard-nav-a1b64e.md @@ -1,6 +1,7 @@ --- id: a1b64e name: Focusable element has no keyboard trap via standard navigation +rules_format: 1.1 rule_type: atomic description: | This rule checks if it is possible to use standard keyboard navigation to navigate through all content on a web page without becoming trapped in any element. @@ -31,19 +32,19 @@ For each target element, focus can cycle to the browser UI by using [standard ke **Note:** It is not possible to fulfill this expectation by using browser specific shortcuts to return to the browser UI. -## Assumptions +## Background + +This rule only requires navigation in one direction (either forward or backward), not both, and not a specific one. It is clear that not being able to escape a focus trap in any direction is a failure of [Success Criterion 2.1.2 No keyboard trap][sc212]. However, it is less clear that being able to escape in only one direction is enough to satisfy it. If [Success Criterion 2.1.2 No keyboard trap][sc212] requires the possibility to escape the trap in a specific way (e.g. forward [standard keyboard navigation](#standard-keyboard-navigation)) or in both directions, this rule may pass while the criterion is not satisfied. + +### Assumptions - The focus order in keyboard navigation is cyclical, not linear, meaning that the focus order will cycle to the first/last element when it moves away from the last/first element. - The Browser UI is part of the focus navigation cycle of the page. -## Accessibility Support +### Accessibility Support There are no accessibility support issues known. -## Background - -This rule only requires navigation in one direction (either forward or backward), not both, and not a specific one. It is clear that not being able to escape a focus trap in any direction is a failure of [Success Criterion 2.1.2 No keyboard trap][sc212]. However, it is less clear that being able to escape in only one direction is enough to satisfy it. If [Success Criterion 2.1.2 No keyboard trap][sc212] requires the possibility to escape the trap in a specific way (e.g. forward [standard keyboard navigation](#standard-keyboard-navigation)) or in both directions, this rule may pass while the criterion is not satisfied. - ### Bibliography - [Understanding Success Criterion 2.1.2: No Keyboard Trap](https://www.w3.org/WAI/WCAG22/Understanding/no-keyboard-trap.html) diff --git a/_rules/form-field-label-descriptive-cc0f0a.md b/_rules/form-field-label-descriptive-cc0f0a.md index dfbbf37bd89..6487aab98e2 100755 --- a/_rules/form-field-label-descriptive-cc0f0a.md +++ b/_rules/form-field-label-descriptive-cc0f0a.md @@ -1,6 +1,7 @@ --- id: cc0f0a name: Form field label is descriptive +rules_format: 1.1 rule_type: atomic description: | This rule checks that labels describe the purpose of form field elements. @@ -53,15 +54,6 @@ and where both the element and the [programmatic label][] are [visible][]. Each test target, together with its [visual context][], describes the purpose of the associated element. -## Assumptions - -- This rule assumes that [labels][label] are intended for sighted users, and that hiding a [visible][] [label][] from assistive technologies, is a failure of [Success Criterion 4.1.2: Name, Role and Value][sc412], but not of [Success Criterion 2.4.6: Headings and Labels][sc246]. -- This rule assumes that the [programmatic labels][programmatic label] of an element are also part of its [visual context][]. - -## Accessibility Support - -- Implementation of [Presentational Roles Conflict Resolution][] varies from one browser or assistive technology to another. Depending on this, some elements can have one of the applicable [semantic roles][semantic role] and fail this rule with some technology but users of other technologies would not experience any accessibility issue. - ## Background The list of applicable [semantic roles][semantic role] is derived by taking all the [ARIA 1.2][aria12] roles that: @@ -75,6 +67,15 @@ It is possible for an element to have an [accessible name][] but still have a no Having a [label][] which is not included in the [accessible name][] is a violation of [Success Criterion 2.5.3: Label in Name][sc253] but not of this rule nor of [Success Criterion 2.4.6: Headings and Labels][sc246]. +### Assumptions + +- This rule assumes that [labels][label] are intended for sighted users, and that hiding a [visible][] [label][] from assistive technologies, is a failure of [Success Criterion 4.1.2: Name, Role and Value][sc412], but not of [Success Criterion 2.4.6: Headings and Labels][sc246]. +- This rule assumes that the [programmatic labels][programmatic label] of an element are also part of its [visual context][]. + +### Accessibility Support + +- Implementation of [Presentational Roles Conflict Resolution][] varies from one browser or assistive technology to another. Depending on this, some elements can have one of the applicable [semantic roles][semantic role] and fail this rule with some technology but users of other technologies would not experience any accessibility issue. + ### Bibliography - [Accessible Rich Internet Applications (WAI-ARIA) 1.2][aria12] diff --git a/_rules/form-field-non-empty-accessible-name-e086e5.md b/_rules/form-field-non-empty-accessible-name-e086e5.md index 6882f012e50..3f7d311a031 100755 --- a/_rules/form-field-non-empty-accessible-name-e086e5.md +++ b/_rules/form-field-non-empty-accessible-name-e086e5.md @@ -1,6 +1,7 @@ --- id: e086e5 name: Form field has non-empty accessible name +rules_format: 1.1 rule_type: atomic description: | This rule checks that each form field element has a non-empty accessible name. @@ -34,15 +35,6 @@ This rule applies to any element that is [included in the accessibility tree](#i Each target element has an [accessible name][] that is not empty (`""`). -## Assumptions - -There are no assumptions. - -## Accessibility Support - -- Several assistive technologies have a functionality to list all form fields on a page, including the `disabled` ones. Therefore this rule is still applicable to `disabled` form fields. If an assistive technology consistently ignores `disabled` form fields in all its interactions, then it is possible to have a `disabled` form field with no accessible name without creating accessibility issues for the user. -- Implementation of [Presentational Roles Conflict Resolution][] varies from one browser or assistive technology to another. Depending on this, some elements can have one of the applicable [semantic roles][] and fail this rule with some technology but users of other technologies would not experience any accessibility issue. - ## Background The list of roles in the applicability is derived by taking all the roles from [WAI-ARIA Specifications](#wai-aria-specifications) that: @@ -54,6 +46,15 @@ This rule does not test other control-like roles such as `button` and `menuitem` This rule does not map to [3.3.2 Labels or Instructions](https://www.w3.org/TR/WCAG22/#labels-or-instructions) as there are sufficient techniques within 3.3.2 that don't need the elements to have an [accessible name][]. For example "[G131: Providing descriptive labels](https://www.w3.org/WAI/WCAG22/Techniques/general/G131)" **AND** "[G162: Positioning labels to maximize predictability of relationships](https://www.w3.org/WAI/WCAG22/Techniques/general/G162)" would be sufficient. +### Assumptions + +There are no assumptions. + +### Accessibility Support + +- Several assistive technologies have a functionality to list all form fields on a page, including the `disabled` ones. Therefore this rule is still applicable to `disabled` form fields. If an assistive technology consistently ignores `disabled` form fields in all its interactions, then it is possible to have a `disabled` form field with no accessible name without creating accessibility issues for the user. +- Implementation of [Presentational Roles Conflict Resolution][] varies from one browser or assistive technology to another. Depending on this, some elements can have one of the applicable [semantic roles][] and fail this rule with some technology but users of other technologies would not experience any accessibility issue. + ### Bibliography - [Understanding Success Criterion 4.1.2: Name, Role, Value](https://www.w3.org/WAI/WCAG22/Understanding/name-role-value) diff --git a/_rules/heading-descriptive-b49b2e.md b/_rules/heading-descriptive-b49b2e.md index c7ed03f9d17..ab7f69a2a45 100755 --- a/_rules/heading-descriptive-b49b2e.md +++ b/_rules/heading-descriptive-b49b2e.md @@ -1,6 +1,7 @@ --- id: b49b2e name: Heading is descriptive +rules_format: 1.1 rule_type: atomic description: | This rule checks that headings describe the topic or purpose of the content. @@ -35,20 +36,20 @@ Each target element describes the topic or purpose of the first [perceivable con **Note:** Headings do not need to be lengthy. A word, or even a single character, may be sufficient. -## Assumptions +## Background + +Headings that are visible but not in the accessibility tree are a failure of [Success Criterion 1.3.1 Info and Relationships][sc131]. These are not tested by this rule but they can still fail [Success Criterion 2.4.6 Headings and Labels][sc246]. + +### Assumptions This rule assumes that the [flat tree][] order is close to the reading order as elements are rendered on the page. Due to positioning, it is possible to render a document in an order that greatly differs from the tree order, in which case the content which is visually associated with a heading might not be the content following it in tree order and this rule might fail while [Success Criterion 2.4.6 Headings and Label][sc246] is still satisfied. This rule also assumes that the content the heading is intended to describe is [visible][] and not hidden from assistive technologies. Otherwise, cases such as expandable content using a heading might fail this rule while [Success Criterion 2.4.6 Headings and Label][sc246] is still satisfied. -## Accessibility Support +### Accessibility Support Implementation of [Presentational Roles Conflict Resolution][] varies from one browser or assistive technology to another. Depending on this, some [semantic][semantic role] `heading` elements can fail this rule with some technology but users of other technologies would not experience any accessibility issue. -## Background - -Headings that are visible but not in the accessibility tree are a failure of [Success Criterion 1.3.1 Info and Relationships][sc131]. These are not tested by this rule but they can still fail [Success Criterion 2.4.6 Headings and Labels][sc246]. - ### Bibliography - [Understanding Success Criterion 1.3.1: Info and Relationships](https://www.w3.org/WAI/WCAG22/Understanding/info-and-relationships.html) diff --git a/_rules/heading-non-empty-accessible-name-ffd0e9.md b/_rules/heading-non-empty-accessible-name-ffd0e9.md index 6431cb0b893..309f8ac9f70 100755 --- a/_rules/heading-non-empty-accessible-name-ffd0e9.md +++ b/_rules/heading-non-empty-accessible-name-ffd0e9.md @@ -1,6 +1,7 @@ --- id: ffd0e9 name: Heading has non-empty accessible name +rules_format: 1.1 rule_type: atomic description: | This rule checks that each heading has a non-empty accessible name. @@ -31,11 +32,15 @@ This rule applies to any [HTML element][] that is a [semantic][semantic role] `h Each test target has a non-empty (`""`) [accessible name][]. -## Assumptions +## Background + +Completely empty headings (e.g., `

`) seem to be consistently ignored by assistive technologies. However, they fail [Technique H42: Using h1-h6 to identify headings][tech h42] (by using heading markup for content which is not heading). Moreover, they may be rendered on screen (by breaking flow content, or because of custom styling), thus causing concerns for sighted users. Therefore, this rule also fails on these. + +### Assumptions There are no assumptions. -## Accessibility Support +### Accessibility Support - Some assistive technologies may hide headings with empty [accessible name][] from the users. This depends on the user agent, on how the [accessible name][] was computed (the [accessible name and description computation][] is not clear concerning which characters should be trimmed), and on the assistive technology itself. Hence, there are cases where the outcome of this rule is _failed_, but users of certain assistive technology and browser combinations will not experience an issue. @@ -43,10 +48,6 @@ There are no assumptions. - The [accessible name and description computation][] suggests that if an `aria-labelledby` attribute refers to an existing but empty element, the computation should stop and return an empty name without defaulting to the next steps. Several user agents and assistive technologies chose to use the next step in the computation in this case (ultimately defaulting to the content). -## Background - -Completely empty headings (e.g., `

`) seem to be consistently ignored by assistive technologies. However, they fail [Technique H42: Using h1-h6 to identify headings][tech h42] (by using heading markup for content which is not heading). Moreover, they may be rendered on screen (by breaking flow content, or because of custom styling), thus causing concerns for sighted users. Therefore, this rule also fails on these. - ### Bibliography - [Understanding Success Criterion 1.3.1: Info and Relationships][usc131] diff --git a/_rules/html-page-lang-b5c3f8.md b/_rules/html-page-lang-b5c3f8.md index 1156ef12007..80b14f8a540 100755 --- a/_rules/html-page-lang-b5c3f8.md +++ b/_rules/html-page-lang-b5c3f8.md @@ -1,6 +1,7 @@ --- id: b5c3f8 name: HTML page has lang attribute +rules_format: 1.1 rule_type: atomic description: | This rule checks that an HTML page has a non-empty `lang` attribute. @@ -39,16 +40,16 @@ This rule applies to any [document element](https://dom.spec.whatwg.org/#documen Each test target has a `lang` [attribute value][] that is neither empty (`""`) nor only [ASCII whitespace](https://infra.spec.whatwg.org/#ascii-whitespace). -## Assumptions +## Background + +### Assumptions The language of the page can be set by other methods than the `lang` attribute, for example using HTTP headers or the `meta` element. These methods are not supported by all assistive technologies. This rule assumes that these other methods are insufficient to satisfying [Success Criterion 3.1.1: Language of Page](https://www.w3.org/TR/WCAG22/#language-of-page). -## Accessibility Support +### Accessibility Support There are no accessibility support issues known. -## Background - ### Related rules - [HTML page `lang` attribute has valid language tag](https://www.w3.org/WAI/standards-guidelines/act/rules/bf051a/) diff --git a/_rules/html-page-lang-matches-default-ucwvc8.md b/_rules/html-page-lang-matches-default-ucwvc8.md index 9500634216b..816fe70393d 100755 --- a/_rules/html-page-lang-matches-default-ucwvc8.md +++ b/_rules/html-page-lang-matches-default-ucwvc8.md @@ -1,6 +1,7 @@ --- id: ucwvc8 name: HTML page language subtag matches default language +rules_format: 1.1 rule_type: atomic description: | This rule checks that the primary language subtag of the page language matches the default language of the page @@ -44,7 +45,9 @@ This rule applies to any [document element][] if it is an `html` element for whi For each test target, the [known primary language tag][] of its `lang` attribute matches the [default page language][] of the test target. -## Assumptions +## Background + +### Assumptions - This rule assumes that the default human language of a page, as described in WCAG 2, can be determined by counting the number of words used in each language. If the default language needs to be derived in some other way (such as frequency analysis, mutual information based distance, …), this rule may fail while [Success Criterion 3.1.1: Language of Page](https://www.w3.org/TR/WCAG22/#language-of-page) is still satisfied. @@ -56,12 +59,10 @@ For each test target, the [known primary language tag][] of its `lang` attribute - This rule assumes that `iframe` title elements are not exposed to assistive technologies and so does not consider them as part of the [default page language][]. -## Accessibility Support +### Accessibility Support There are no accessibility support issues known. -## Background - ### Related rules - [HTML page has `lang` attribute](https://www.w3.org/WAI/standards-guidelines/act/rules/b5c3f8/) diff --git a/_rules/html-page-lang-valid-bf051a.md b/_rules/html-page-lang-valid-bf051a.md index 03e1244548c..5dc68688b2d 100755 --- a/_rules/html-page-lang-valid-bf051a.md +++ b/_rules/html-page-lang-valid-bf051a.md @@ -1,6 +1,7 @@ --- id: bf051a name: HTML page lang attribute has valid language tag +rules_format: 1.1 rule_type: atomic description: | This rule checks that the `lang` attribute of the root element of a non-embedded HTML page has a language tag with a known primary language subtag. @@ -38,7 +39,9 @@ This rule applies to any [document element](https://dom.spec.whatwg.org/#documen For each test target, the `lang` attribute has a [known primary language tag][]. -## Assumptions +## Background + +### Assumptions - The language of the page can be set by other methods than the `lang` attribute, for example using HTTP headers or the `meta` element. These methods are not supported by all assistive technologies. This rule assumes that these other methods are insufficient to satisfying [Success Criterion 3.1.1: Language of Page](https://www.w3.org/TR/WCAG22/#language-of-page). @@ -46,12 +49,10 @@ For each test target, the `lang` attribute has a [known primary language tag][]. - This rule assumes that only [known primary language tags][known primary language tag] are enough to satisfy [Success Criterion 3.1.1 Language of Page][sc311]; this notably excludes [grandfathered tags][] and [ISO 639.2][] three-letters codes, both having poor support in assistive technologies. -## Accessibility Support +### Accessibility Support There are no accessibility support issues known. -## Background - This rule is only applicable to non-embedded HTML pages. HTML pages embedded into other documents, such as through `iframe` or `object` elements are not applicable because they are not [web pages](https://www.w3.org/TR/WCAG22/#dfn-web-page-s) according to the definition in WCAG. ### Related rules diff --git a/_rules/html-page-lang-xml-lang-match-5b7ae0.md b/_rules/html-page-lang-xml-lang-match-5b7ae0.md index 7f81e1f0d9b..c62bf1e79dd 100755 --- a/_rules/html-page-lang-xml-lang-match-5b7ae0.md +++ b/_rules/html-page-lang-xml-lang-match-5b7ae0.md @@ -1,6 +1,7 @@ --- id: 5b7ae0 name: HTML page lang and xml:lang attributes have matching values +rules_format: 1.1 rule_type: atomic description: | This rule checks that both `lang` and `xml:lang` attributes on the root element of a non-embedded HTML page, have the same primary language subtag. @@ -36,7 +37,11 @@ This rule applies to any [document element](https://dom.spec.whatwg.org/#documen For each test target, the values of the [primary language subtags][], if any exist, for the `lang` and `xml:lang` attributes are the same. -## Assumptions +## Background + +This rule is only applicable to non-embedded HTML pages. HTML pages embedded into other documents, such as through `iframe` or `object` elements are not applicable because they are not [web pages](https://www.w3.org/TR/WCAG22/#dfn-web-page-s) according to the definition in WCAG. + +### Assumptions - The language of the page can be set by other methods than the `lang` attribute, for example using HTTP headers or the `meta` element. These methods are not supported by all assistive technologies. This rule assumes that these other methods are insufficient to satisfying [Success Criterion 3.1.1: Language of Page](https://www.w3.org/TR/WCAG22/#language-of-page). @@ -46,14 +51,10 @@ For each test target, the values of the [primary language subtags][], if any exi - The rule assumes that having `lang` and `xml:lang` attributes with matching [primary language subtags][] but non-matching [language tags](https://www.rfc-editor.org/rfc/rfc5646.html#section-2) overall, will not cause accessibility issues. This is not necessarily the case for all languages. One notable case is the [language tags](https://www.rfc-editor.org/rfc/rfc5646.html#section-2) for Cantonese (`zh-yue`) and Mandarin (`zh-cmn`) where the [primary language subtags][] match, but the [extended language subtags][] don't. Such a case would not fail this rule, but could lead to accessibility issues. -## Accessibility Support +### Accessibility Support Since most assistive technologies will consistently use `lang` over `xml:lang` when both are used, violation of this rule may not necessarily be a violation of WCAG 2. Only when there are inconsistencies between assistive technologies as to which attribute is used to determine the language does this lead to a violation of SC 3.1.1. -## Background - -This rule is only applicable to non-embedded HTML pages. HTML pages embedded into other documents, such as through `iframe` or `object` elements are not applicable because they are not [web pages](https://www.w3.org/TR/WCAG22/#dfn-web-page-s) according to the definition in WCAG. - ### Bibliography - [H57: Using language attributes on the html element](https://www.w3.org/WAI/WCAG22/Techniques/html/H57) diff --git a/_rules/html-page-non-empty-title-2779a5.md b/_rules/html-page-non-empty-title-2779a5.md index e8380db5677..5bff5770ec1 100755 --- a/_rules/html-page-non-empty-title-2779a5.md +++ b/_rules/html-page-non-empty-title-2779a5.md @@ -1,6 +1,7 @@ --- id: 2779a5 name: HTML page has non-empty title +rules_format: 1.1 rule_type: atomic description: | This rule checks that a non-embedded HTML page has a non-empty title. @@ -49,20 +50,20 @@ Each target element has at least one [descendant](https://dom.spec.whatwg.org/#c For each target element, the first [HTML][] `title` element that is a [descendant](https://dom.spec.whatwg.org/#concept-tree-descendant) of the [document element](https://dom.spec.whatwg.org/#document-element) has [children](https://dom.spec.whatwg.org/#concept-tree-child) that are [text nodes](https://dom.spec.whatwg.org/#text) that are not only [whitespace](#whitespace). -## Assumptions +## Background + +This rule is only applicable to non-embedded HTML pages. HTML pages embedded into other documents, such as through `iframe` or `object` elements are not applicable because they are not [web pages](https://www.w3.org/TR/WCAG22/#dfn-web-page-s) according to the definition in WCAG. + +### Assumptions This rule assumes that [Success Criterion 2.4.2 Page Titled](https://www.w3.org/TR/WCAG22/#page-titled) does not require that a document only has one `title` element, nor that it is a child of the `head` element of a document. While this is invalid in HTML, the [HTML specification](https://html.spec.whatwg.org/multipage/dom.html#the-title-element-2) describes what should happen in case of multiple titles, and titles outside the `head` element. Because of this, neither of these validation issues causes a conformance problem for WCAG. Regardless of whether this is required by 2.4.2 Page Titled, failing this rule means the success criterion is not satisfied. This rule assumes that the title of the page is not provided by a higher-level protocol. For example, the subject field of an email authored in HTML can provide a title without requiring a `title` element. In such a case, this rule will fail while [Success Criterion 2.4.2 Page Titled](https://www.w3.org/TR/WCAG22/#page-titled) may still be satisfied. -## Accessibility Support +### Accessibility Support There are no accessibility support issues known. -## Background - -This rule is only applicable to non-embedded HTML pages. HTML pages embedded into other documents, such as through `iframe` or `object` elements are not applicable because they are not [web pages](https://www.w3.org/TR/WCAG22/#dfn-web-page-s) according to the definition in WCAG. - ### Related rules - [HTML page title is descriptive](https://www.w3.org/WAI/standards-guidelines/act/rules/c4a8a4/) @@ -213,12 +214,12 @@ This page does not have a title because the shadow root is not a [descendant](ht This is the page title + shadow.appendChild(template.content) + ``` diff --git a/_rules/html-page-title-descriptive-c4a8a4.md b/_rules/html-page-title-descriptive-c4a8a4.md index acec5e9e8bc..6f77d30ae64 100755 --- a/_rules/html-page-title-descriptive-c4a8a4.md +++ b/_rules/html-page-title-descriptive-c4a8a4.md @@ -1,6 +1,7 @@ --- id: c4a8a4 name: HTML page title is descriptive +rules_format: 1.1 rule_type: atomic description: | This rule checks that the first title in an HTML web page describes the topic or purpose of that page. @@ -46,19 +47,19 @@ This rule applies to the [document title][] of each [html web page][], except if The target element describes the topic or purpose of the overall content of the [document](https://dom.spec.whatwg.org/#concept-document). -## Assumptions +## Background -There are currently no assumptions. +The `title` elements of embedded documents, such as those in `iframe`, `object`, or `svg` elements, are not applicable because those are not web pages according to the definition in WCAG. -## Accessibility Support +The [HTML specification - The `title` element](https://html.spec.whatwg.org/#the-title-element) requires documents to only have one `title` element; and `title` elements to be children of the `head` element of a document. However, current HTML specification also describes what should happen in case of multiple titles, and titles outside the `head` element. Because of this, neither of these validation issues causes a conformance problem for WCAG. -- This rule assumes that browsers only recognize the first `title` element if multiple `title` elements are present in the [document](https://dom.spec.whatwg.org/#concept-document). Testing shows that this in general is the case. Therefore the scope of this rule is limited to only checking the first `title` element in a document. +### Assumptions -## Background +There are currently no assumptions. -The `title` elements of embedded documents, such as those in `iframe`, `object`, or `svg` elements, are not applicable because those are not web pages according to the definition in WCAG. +### Accessibility Support -The [HTML specification - The `title` element](https://html.spec.whatwg.org/#the-title-element) requires documents to only have one `title` element; and `title` elements to be children of the `head` element of a document. However, current HTML specification also describes what should happen in case of multiple titles, and titles outside the `head` element. Because of this, neither of these validation issues causes a conformance problem for WCAG. +- This rule assumes that browsers only recognize the first `title` element if multiple `title` elements are present in the [document](https://dom.spec.whatwg.org/#concept-document). Testing shows that this in general is the case. Therefore the scope of this rule is limited to only checking the first `title` element in a document. ### Related rules diff --git a/_rules/id-value-unique-3ea0c8.md b/_rules/id-value-unique-3ea0c8.md index c994931eb5f..4e50202bfe8 100755 --- a/_rules/id-value-unique-3ea0c8.md +++ b/_rules/id-value-unique-3ea0c8.md @@ -1,6 +1,7 @@ --- id: 3ea0c8 name: Id attribute value is unique +rules_format: 1.1 rule_type: atomic description: | This rule checks that all `id` attribute values on a single page are unique. @@ -43,16 +44,16 @@ This rule applies to any `id` attribute whose value is not an empty string (`""` The value of the attribute is unique across all other `id` attributes specified on [HTML or SVG elements][html or svg element] that exist within the same [document tree](https://dom.spec.whatwg.org/#document-trees) or [shadow tree](https://dom.spec.whatwg.org/#shadow-trees) as the element on which the applicable `id` attribute is specified. -## Assumptions +## Background + +### Assumptions There are no assumptions. -## Accessibility Support +### Accessibility Support There are no accessibility support issues known. -## Background - ### Bibliography - [Understanding Success Criterion 4.1.1: Parsing](https://www.w3.org/WAI/WCAG22/Understanding/parsing) diff --git a/_rules/iframe-identical-name-equivalent-purpose-4b1c6c.md b/_rules/iframe-identical-name-equivalent-purpose-4b1c6c.md index edaa19a5c71..d66bb91c329 100755 --- a/_rules/iframe-identical-name-equivalent-purpose-4b1c6c.md +++ b/_rules/iframe-identical-name-equivalent-purpose-4b1c6c.md @@ -1,6 +1,7 @@ --- id: 4b1c6c name: Iframe elements with identical accessible names have equivalent purpose +rules_format: 1.1 rule_type: atomic description: | This rule checks that `iframe` elements with identical accessible names embed the same resource or equivalent resources. @@ -35,17 +36,17 @@ This rule applies to any set of any two or more `iframe` elements which: The `iframe` elements in each set of target elements embed the [same resource][] or [equivalent resources](#equivalent-resource). -## Assumptions +## Background -This rule assumes that, within the context of the test subject, the description provided by the [accessible name][] of an `iframe` can only accurately describe one resource (notably, homonyms alone are not used as `iframe` names). Thus, if two or more `iframe` elements have the same [accessible name][] but embed different resources, at least one of them does not describe its purpose. +When determining if target elements embed the same resource, resolving the embedded resource includes any redirects that are instant. -## Accessibility Support +### Assumptions -This rule assumes that assistive technologies are exposing all `iframe` elements on the page in the same way no matter which [document tree](https://dom.spec.whatwg.org/#document-trees) they are in. If an assistive technology requires the user to "enter" an `iframe` or a [shadow tree][] before exposing its content (notably nested `iframe`), then it is possible for two `iframe` to have identical name but embed different resources without failing [Success Criterion 4.1.2: Name, Role, Value][sc412] (if said `iframe` are in separate [documents][document] or [shadow trees][shadow tree]) +This rule assumes that, within the context of the test subject, the description provided by the [accessible name][] of an `iframe` can only accurately describe one resource (notably, homonyms alone are not used as `iframe` names). Thus, if two or more `iframe` elements have the same [accessible name][] but embed different resources, at least one of them does not describe its purpose. -## Background +### Accessibility Support -When determining if target elements embed the same resource, resolving the embedded resource includes any redirects that are instant. +This rule assumes that assistive technologies are exposing all `iframe` elements on the page in the same way no matter which [document tree](https://dom.spec.whatwg.org/#document-trees) they are in. If an assistive technology requires the user to "enter" an `iframe` or a [shadow tree][] before exposing its content (notably nested `iframe`), then it is possible for two `iframe` to have identical name but embed different resources without failing [Success Criterion 4.1.2: Name, Role, Value][sc412] (if said `iframe` are in separate [documents][document] or [shadow trees][shadow tree]) ### Bibliography diff --git a/_rules/iframe-non-empty-accessible-name-cae760.md b/_rules/iframe-non-empty-accessible-name-cae760.md index 4c72f047bd2..878f83cff6f 100755 --- a/_rules/iframe-non-empty-accessible-name-cae760.md +++ b/_rules/iframe-non-empty-accessible-name-cae760.md @@ -1,6 +1,7 @@ --- id: cae760 name: Iframe element has non-empty accessible name +rules_format: 1.1 rule_type: atomic description: | This rule checks that each `iframe` element has a non-empty accessible name. @@ -33,11 +34,17 @@ This rule applies to `iframe` elements that are [included in the accessibility t Each target element has an [accessible name][] that is not empty (`""`). -## Assumptions +## 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. + +### Assumptions If an `iframe` is not perceived by the user as a single control, it does not qualify as a [user interface component][] under WCAG 2. In such a scenario, failing this rule would not fail [success criterion 4.1.2](https://www.w3.org/TR/WCAG22/#name-role-value). Unless the `iframe` is both removed from the accessibility tree and removed from [sequential focus navigation][], they usually are considered to be [user interface components][user interface component]. -## Accessibility Support +### Accessibility Support - 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][] @@ -45,12 +52,6 @@ If an `iframe` is not perceived by the user as a single control, it does not qua - 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/WCAG22/Techniques/html/H64) diff --git a/_rules/iframe-with-interactive-content-in-tab-order-akn7bn.md b/_rules/iframe-with-interactive-content-in-tab-order-akn7bn.md index ad9a6233eae..804b8a25363 100644 --- a/_rules/iframe-with-interactive-content-in-tab-order-akn7bn.md +++ b/_rules/iframe-with-interactive-content-in-tab-order-akn7bn.md @@ -1,6 +1,7 @@ --- id: akn7bn name: Iframe with interactive elements is not excluded from tab-order +rules_format: 1.1 rule_type: atomic description: | This rule checks that `iframe` elements which contain an interactive (tabbable) element are not excluded from sequential focus navigation. @@ -39,19 +40,19 @@ An element is contained in a [nested browsing con The test target does not have a negative number as a `tabindex` [attribute value][]. -## Assumptions +## Background -This rule assumes that interactive content inside `iframe` elements is used to provide functionality. If the interactive content does not provide functionality, for example a button that does nothing when clicked, [success criterion 2.1.1][sc211] may be satisfied, even if the rule is failed. +Setting the `tabindex` attribute of an `iframe` element to a negative value effectively excludes its content from the tab-order of the page. A `button` may be in the tab-order of an `iframe`, but if the `iframe` itself is taken from the tab-order, the `button` is effectively keyboard inaccessible. -## Accessibility Support +Each document, including documents inside an `iframe`, has its own [sequential focus navigation order][]. These focus orders are combined to get the page's global tab-order (called the [flattened tabindex-ordered focus navigation scope][]). For an `iframe` with a negative tabindex, its sequential focus navigation order is not included in the page's global tab-order (as a consequence for the rules to build the [tabindex-ordered focus navigation scope][]). -There are no accessibility support issues known. +### Assumptions -## Background +This rule assumes that interactive content inside `iframe` elements is used to provide functionality. If the interactive content does not provide functionality, for example a button that does nothing when clicked, [success criterion 2.1.1][sc211] may be satisfied, even if the rule is failed. -Setting the `tabindex` attribute of an `iframe` element to a negative value effectively excludes its content from the tab-order of the page. A `button` may be in the tab-order of an `iframe`, but if the `iframe` itself is taken from the tab-order, the `button` is effectively keyboard inaccessible. +### Accessibility Support -Each document, including documents inside an `iframe`, has its own [sequential focus navigation order][]. These focus orders are combined to get the page's global tab-order (called the [flattened tabindex-ordered focus navigation scope][]). For an `iframe` with a negative tabindex, its sequential focus navigation order is not included in the page's global tab-order (as a consequence for the rules to build the [tabindex-ordered focus navigation scope][]). +There are no accessibility support issues known. ### Bibliography diff --git a/_rules/image-accessible-name-descriptive-qt1vmo.md b/_rules/image-accessible-name-descriptive-qt1vmo.md index aa304ce6c8b..d73c90fb867 100755 --- a/_rules/image-accessible-name-descriptive-qt1vmo.md +++ b/_rules/image-accessible-name-descriptive-qt1vmo.md @@ -1,6 +1,7 @@ --- id: qt1vmo name: Image accessible name is descriptive +rules_format: 1.1 rule_type: atomic description: | This rule checks that the accessible names of images serve an equivalent purpose to the image. @@ -52,16 +53,16 @@ This rule applies to any `img`, `canvas` or `svg` element that is [visible][] an Each test target has an [accessible name][] that serves an equivalent purpose to the [non-text content][] of that test target. -## Assumptions +## Background + +### Assumptions There are no assumptions. -## Accessibility Support +### Accessibility Support Some popular browser / screen reader combinations do not pronounce the accessible names of `svg` elements. This can be resolved by adding an [explicit semantic role][] of `img` to the `svg` element. -## Background - ### Bibliography - [Understanding Success Criterion 1.1.1: Non-text Content](https://www.w3.org/WAI/WCAG22/Understanding/non-text-content.html) diff --git a/_rules/image-button-non-empty-accessible-name-59796f.md b/_rules/image-button-non-empty-accessible-name-59796f.md index 9347034657e..50444bfc08f 100755 --- a/_rules/image-button-non-empty-accessible-name-59796f.md +++ b/_rules/image-button-non-empty-accessible-name-59796f.md @@ -1,6 +1,7 @@ --- id: 59796f name: Image button has non-empty accessible name +rules_format: 1.1 rule_type: atomic description: | This rule checks that each image button element has a non-empty accessible name. @@ -47,19 +48,19 @@ This rule applies to any `input` element with a `type` [attribute value][] of `i Each target element has an [accessible name][] that is neither empty (`""`), nor the default name for this element (localized version of "Submit Query"). -## Assumptions +## Background + +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). + +### Assumptions - This rule assumes that all image buttons are [user interface components as defined by WCAG 2](https://www.w3.org/TR/WCAG22/#dfn-user-interface-components). - This rule assumes that the default name for image buttons ("Submit Query"), as defined by the [HTML Accessibility API Mapping][html aam image button], is never descriptive. -## Accessibility Support +### Accessibility Support The [input type="image" Accessible Name Computation algorithm](https://www.w3.org/TR/html-aam/#input-type-image-accessible-name-computation) uses the first non-empty name, but some user agents and assistive technologies combinations stop at the first existing one, even if empty. -## Background - -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 - [Button has non-empty accessible name](https://www.w3.org/WAI/standards-guidelines/act/rules/97a4e1/) diff --git a/_rules/image-filename-as-accessible-name-9eb3f6.md b/_rules/image-filename-as-accessible-name-9eb3f6.md index 5fd7bcdfa47..2f9c3fcc0d8 100755 --- a/_rules/image-filename-as-accessible-name-9eb3f6.md +++ b/_rules/image-filename-as-accessible-name-9eb3f6.md @@ -1,6 +1,7 @@ --- id: 9eb3f6 name: Image filename is accessible name for image +rules_format: 1.1 rule_type: atomic description: | This rule checks that image elements that use their source filename as their accessible name do so without loss of information to the user. @@ -56,17 +57,17 @@ When comparing [accessible name][] and [filename][], difference in letter casing Each test target has an [accessible name][] that serves an equivalent purpose to the [non-text content][]. If there are several [image sources][], then the [accessible name][] must accurately describe all of them. -## Assumptions +## Background -There are no assumptions. +It is fairly common for content management systems (CMS) or other tools to default the alt-text of an image to its filename if no alt-text is provided. However, these names are usually not descriptive (often due to the presence of the file extension). This rule uses this heuristic to pinpoint cases where the [accessible name][] should be looked at by human testers. This rule does not automatically decide in which case a filename is correct (notably, it does not automatically decide whether adding the file extension is acceptable). -## Accessibility Support +### Assumptions -There are no accessibility support issues known. +There are no assumptions. -## Background +### Accessibility Support -It is fairly common for content management systems (CMS) or other tools to default the alt-text of an image to its filename if no alt-text is provided. However, these names are usually not descriptive (often due to the presence of the file extension). This rule uses this heuristic to pinpoint cases where the [accessible name][] should be looked at by human testers. This rule does not automatically decide in which case a filename is correct (notably, it does not automatically decide whether adding the file extension is acceptable). +There are no accessibility support issues known. ### Bibliography diff --git a/_rules/image-no-text-0va7u6.md b/_rules/image-no-text-0va7u6.md index 0fd210c74b5..8ab32d578bd 100644 --- a/_rules/image-no-text-0va7u6.md +++ b/_rules/image-no-text-0va7u6.md @@ -1,6 +1,7 @@ --- id: 0va7u6 name: HTML images contain no text +rules_format: 1.1 rule_type: atomic description: | This rule checks that images of text are not used @@ -43,19 +44,19 @@ Each test target has no [visible][] [text][human language], except if at least o - incidental: The text is not a [significant][insignificant] part of the image; or - essential: The presentation of the text is [essential][]. -## Assumptions +## Background + +This rule is designed specifically for [SC 1.4.5 Images of Text][sc1.4.5]. There are however only minimal differences between this criterion and [SC 1.4.9 Images of Text (No Exception)][sc1.4.9]. The two differences are that customizable images of text are allowed, and that images of text are allowed when the presentation cannot otherwise be achieved. These scenarios are so rare the rule ignores them as part of the assumptions, and so the [accessibility requirements mapping](#accessibility-requirements-mapping) of these two criteria is the same. + +### Assumptions - This rule assumes that there is no mechanism to change the rendering of text within image resources on the page. For pages that _do_ provide such a mechanism, this rule might fail even if [SC 1.4.5 Images of Text][sc1.4.5] is satisfied. - When used in HTML, the SVG `` element is not considered to be an image of text. This is because like any other element in HTML, SVG `` can be adjusted through custom style sheets. This does not apply for SVG text that is in a separate file, and displayed through, for example, the `img` element. -## Accessibility Support +### Accessibility Support There are no accessibility support issues known. -## Background - -This rule is designed specifically for [SC 1.4.5 Images of Text][sc1.4.5]. There are however only minimal differences between this criterion and [SC 1.4.9 Images of Text (No Exception)][sc1.4.9]. The two differences are that customizable images of text are allowed, and that images of text are allowed when the presentation cannot otherwise be achieved. These scenarios are so rare the rule ignores them as part of the assumptions, and so the [accessibility requirements mapping](#accessibility-requirements-mapping) of these two criteria is the same. - ### Bibliography - [Understanding Success Criterion 1.4.5: Images of Text][sc1.4.5] diff --git a/_rules/image-non-empty-accessible-name-23a2a8.md b/_rules/image-non-empty-accessible-name-23a2a8.md index e4c27e4562b..7157699d317 100755 --- a/_rules/image-non-empty-accessible-name-23a2a8.md +++ b/_rules/image-non-empty-accessible-name-23a2a8.md @@ -1,6 +1,7 @@ --- id: 23a2a8 name: Image has non-empty accessible name +rules_format: 1.1 rule_type: atomic description: | This rule checks that each image either has a non-empty accessible name or is marked up as decorative. @@ -46,18 +47,18 @@ This rule applies to [HTML][] `img` elements and [HTML elements][html] that are Each target element has an [accessible name][] that is not empty (`""`), or has a [semantic role][] of `none` or `presentation`. -## Assumptions +## Background + +### Assumptions There are no assumptions. -## Accessibility Support +### Accessibility Support - 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. -## Background - ### Bibliography - [Understanding Success Criterion 1.1.1: Non-text Content](https://www.w3.org/WAI/WCAG22/Understanding/non-text-content.html) diff --git a/_rules/image-not-in-acc-tree-is-decorative-e88epe.md b/_rules/image-not-in-acc-tree-is-decorative-e88epe.md index bae30ea4335..330674f8c70 100755 --- a/_rules/image-not-in-acc-tree-is-decorative-e88epe.md +++ b/_rules/image-not-in-acc-tree-is-decorative-e88epe.md @@ -1,6 +1,7 @@ --- id: e88epe name: Image not in the accessibility tree is decorative +rules_format: 1.1 rule_type: atomic description: | This rule checks that visible `img`, `svg` and `canvas` elements that are ignored by assistive technologies are decorative. @@ -51,18 +52,18 @@ Each test target is [purely decorative][]. **Note**: It is relatively common for an informative image such as an icon to be marked up as decorative, if the text alternative is adjacent to the image. This is a [conforming alternative version][] for the image. This fails the rule but meets [conformance requirement 1 of WCAG 2.2](https://www.w3.org/TR/WCAG22/#cc1). -## Assumptions +## Background + +### Assumptions - `svg` elements with a [semantic role][] of `graphics-document` and with an empty (`""`) [accessible name][] are ignored by assistive technologies tested for this rule. If some assistive technology does not ignore these elements, and that assistive technology is required for conformance, passing this rule does not ensure all decorative `svg` elements can be ignored, and the [success criterion 1.1.1 Non-text content][] may still not be satisfied. The same is true for `canvas` elements with no [semantic role][] and an empty (`""`) [accessible name][]. - A web page with informative images without an [accessible name][] may conform to WCAG 2.2 Level A when the information provided by that image is available elsewhere on the web page itself. For example if an equivalent text is adjacent to the image, or if the text alternative is included in the [accessible name][] of a parent element. -## Accessibility Support +### Accessibility Support There are no accessibility support issues known. -## Background - ### Bibliography - [H67: Using null alt text and no title attribute on img elements for images that AT should ignore](https://www.w3.org/WAI/WCAG22/Techniques/html/H67.html) diff --git a/_rules/important-letter-spacing-wide-enough-24afc2.md b/_rules/important-letter-spacing-wide-enough-24afc2.md index f30f2846ac5..8542380d9d3 100755 --- a/_rules/important-letter-spacing-wide-enough-24afc2.md +++ b/_rules/important-letter-spacing-wide-enough-24afc2.md @@ -1,6 +1,7 @@ --- id: 24afc2 name: Important letter spacing in style attributes is wide enough +rules_format: 1.1 rule_type: atomic description: | This rule checks that the `style` attribute is not used to prevent adjusting `letter-spacing` by using `!important`, except if it's at least 0.12 times the font size. @@ -33,7 +34,13 @@ This rule applies to any [HTML element][] with one or more [visible][] [text nod For each test target, the [computed][] value of its `letter-spacing` property is at least 0.12 times the [computed][] value of its `font-size` property. -## Assumptions +## Background + +Styles [declared][] in a `style` attribute have higher [cascade specificity][] than any selector; therefore, they "win" the [cascade sort] over any other style from [author origin][], i.e. it cannot be overridden by any of these. On the other hand, if such a style is [declared][] in a style sheet, it can still "lose" the [cascade sort][] to declarations with higher [specificity][] or simply coming from a later style sheet (such as ones injected by assistive technologies). This rule ensures that the element is not in the first case and that the style can be overridden by users, unless it is already at least the minimum required threshold. [Important][] styles that are declared with the [user][user origin] or [user agent][user agent origin] can win the [cascade sort][] over styles with the [author origin][]. + +CSS specifications define each declaration as being either [important][] (if it has the `!important` annotation) or [normal][]. Given that `normal` is also a keyword for some properties, and that `!important` is wider known than this distinction, this rule rather uses "[important][]"/"not [important][]" to avoid confusion. + +### Assumptions - There is no mechanism available on the page to adjust `letter-spacing`. If there is such a mechanism, it is possible to fail this rule while [Success Criterion 1.4.12 Text Spacing][sc1412] is still satisfied. @@ -45,16 +52,10 @@ For each test target, the [computed][] value of its `letter-spacing` property is - The target text node expresses something in a human language written in a script that uses the `letter-spacing` property. -## Accessibility Support +### Accessibility Support While some assistive technologies are able to set [user origin][] or [user agent origin][] styles, others, such as browser extensions, are only able to set styles with the [author origin][]. Such assistive technologies cannot create styles "winning" the [cascade sort][] over a `style` attribute with an [important][] declaration. -## Background - -Styles [declared][] in a `style` attribute have higher [cascade specificity][] than any selector; therefore, they "win" the [cascade sort] over any other style from [author origin][], i.e. it cannot be overridden by any of these. On the other hand, if such a style is [declared][] in a style sheet, it can still "lose" the [cascade sort][] to declarations with higher [specificity][] or simply coming from a later style sheet (such as ones injected by assistive technologies). This rule ensures that the element is not in the first case and that the style can be overridden by users, unless it is already at least the minimum required threshold. [Important][] styles that are declared with the [user][user origin] or [user agent][user agent origin] can win the [cascade sort][] over styles with the [author origin][]. - -CSS specifications define each declaration as being either [important][] (if it has the `!important` annotation) or [normal][]. Given that `normal` is also a keyword for some properties, and that `!important` is wider known than this distinction, this rule rather uses "[important][]"/"not [important][]" to avoid confusion. - ### Bibliography - [Understanding Success Criterion 1.4.12: Text Spacing](https://www.w3.org/WAI/WCAG22/Understanding/text-spacing.html) diff --git a/_rules/important-line-height-wide-enough-78fd32.md b/_rules/important-line-height-wide-enough-78fd32.md index 72021975b5e..4f91c4b9189 100755 --- a/_rules/important-line-height-wide-enough-78fd32.md +++ b/_rules/important-line-height-wide-enough-78fd32.md @@ -1,6 +1,7 @@ --- id: 78fd32 name: Important line height in style attributes is wide enough +rules_format: 1.1 rule_type: atomic description: | This rule checks that the `style` attribute is not used to prevent adjusting `line-height` by using `!important`, except if it's at least 1.5 times the font size. @@ -33,7 +34,15 @@ This rule applies to any [HTML element][] with one or more [visible][] [text nod For each test target, the [used][] value of its `line-height` property is at least 1.5 times the [computed][] value of its `font-size` property. -## Assumptions +## Background + +Styles [declared][] in a `style` attribute have higher [cascade specificity][] than any selector; therefore, they "win" the [cascade sort] over any other style from [author origin][], i.e. it cannot be overridden by any of these. On the other hand, if such a style is [declared][] in a style sheet, it can still "lose" the [cascade sort][] to declarations with higher [specificity][] or simply coming from a later style sheet (such as ones injected by assistive technologies). This rule ensures that the element is not in the first case and that the style can be overridden by users, unless it is already at least the minimum required threshold. [Important][] styles that are declared with the [user][user origin] or [user agent][user agent origin] can win the [cascade sort][] over styles with the [author origin][]. + +CSS specifications define each declaration as being either [important][] (if it has the `!important` annotation) or [normal][]. Given that `normal` is also a keyword for some properties, and that `!important` is wider known than this distinction, this rule rather uses "[important][]"/"not [important][]" to avoid confusion. + +This rule evaluates the [used][] value of the `line-height` property instead of its [computed][] value because the [used][] value is guaranteed to use absolute units (i.e., pixels). This streamlines comparison with the [computed][] `font-size` which is also absolute. The [computed][] `line-height` may be a unitless number that is harder to compare. + +### Assumptions - There is no mechanism available on the page to adjust `line-height`. If there is such a mechanism, it is possible to fail this rule while [Success Criterion 1.4.12 Text Spacing][sc1412] is still satisfied. @@ -43,18 +52,10 @@ For each test target, the [used][] value of its `line-height` property is at lea - The text in the element express something in a human language written in a script that uses the `line-height` property. -## Accessibility Support +### Accessibility Support While some assistive technologies are able to set [user origin][] or [user agent origin][] styles, others, such as browser extensions, are only able to set styles with the [author origin][]. Such assistive technologies cannot create styles "winning" the [cascade sort][] over a `style` attribute with an [important][] declaration. -## Background - -Styles [declared][] in a `style` attribute have higher [cascade specificity][] than any selector; therefore, they "win" the [cascade sort] over any other style from [author origin][], i.e. it cannot be overridden by any of these. On the other hand, if such a style is [declared][] in a style sheet, it can still "lose" the [cascade sort][] to declarations with higher [specificity][] or simply coming from a later style sheet (such as ones injected by assistive technologies). This rule ensures that the element is not in the first case and that the style can be overridden by users, unless it is already at least the minimum required threshold. [Important][] styles that are declared with the [user][user origin] or [user agent][user agent origin] can win the [cascade sort][] over styles with the [author origin][]. - -CSS specifications define each declaration as being either [important][] (if it has the `!important` annotation) or [normal][]. Given that `normal` is also a keyword for some properties, and that `!important` is wider known than this distinction, this rule rather uses "[important][]"/"not [important][]" to avoid confusion. - -This rule evaluates the [used][] value of the `line-height` property instead of its [computed][] value because the [used][] value is guaranteed to use absolute units (i.e., pixels). This streamlines comparison with the [computed][] `font-size` which is also absolute. The [computed][] `line-height` may be a unitless number that is harder to compare. - ### Bibliography - [Understanding Success Criterion 1.4.12: Text Spacing](https://www.w3.org/WAI/WCAG22/Understanding/text-spacing.html) diff --git a/_rules/important-word-spacing-wide-enough-9e45ec.md b/_rules/important-word-spacing-wide-enough-9e45ec.md index 1ba764bb530..2746a515be0 100755 --- a/_rules/important-word-spacing-wide-enough-9e45ec.md +++ b/_rules/important-word-spacing-wide-enough-9e45ec.md @@ -1,6 +1,7 @@ --- id: 9e45ec name: Important word spacing in style attributes is wide enough +rules_format: 1.1 rule_type: atomic description: | This rule checks that the `style` attribute is not used to prevent adjusting `word-spacing` by using `!important`, except if it's at least `0.16` times the font size. @@ -33,7 +34,13 @@ This rule applies to any [HTML element][] with one or more [visible][] [text nod For each test target, the [computed][] value of its `word-spacing` property is at least 0.16 times the [computed][] value of its `font-size` property. -## Assumptions +## Background + +Styles [declared][] in a `style` attribute have higher [cascade specificity][] than any selector; therefore, they "win" the [cascade sort] over any other style from [author origin][], i.e. it cannot be overridden by any of these. On the other hand, if such a style is [declared][] in a style sheet, it can still "lose" the [cascade sort][] to declarations with higher [specificity][] or simply coming from a later style sheet (such as ones injected by assistive technologies). This rule ensures that the element is not in the first case and that the style can be overridden by users, unless it is already at least the minimum required threshold. [Important][] styles that are declared with the [user][user origin] or [user agent][user agent origin] can win the [cascade sort][] over styles with the [author origin][]. + +CSS specifications define each declaration as being either [important][] (if it has the `!important` annotation) or [normal][]. Given that `normal` is also a keyword for some properties, and that `!important` is wider known than this distinction, this rule rather uses "[important][]"/"not [important][]" to avoid confusion. + +### Assumptions - There is no mechanism available on the page to adjust `word-spacing`. If there is such a mechanism, it is possible to fail this rule while [Success Criterion 1.4.12 Text Spacing][sc1412] is still satisfied. @@ -45,16 +52,10 @@ For each test target, the [computed][] value of its `word-spacing` property is a - At least one text node child of the element express something in a human language written in a script that uses the `word-spacing` property. -## Accessibility Support +### Accessibility Support While some assistive technologies are able to set [user origin][] or [user agent origin][] styles, others, such as browser extensions, are only able to set styles with the [author origin][]. Such assistive technologies cannot create styles "winning" the [cascade sort][] over a `style` attribute with an [important][] declaration. -## Background - -Styles [declared][] in a `style` attribute have higher [cascade specificity][] than any selector; therefore, they "win" the [cascade sort] over any other style from [author origin][], i.e. it cannot be overridden by any of these. On the other hand, if such a style is [declared][] in a style sheet, it can still "lose" the [cascade sort][] to declarations with higher [specificity][] or simply coming from a later style sheet (such as ones injected by assistive technologies). This rule ensures that the element is not in the first case and that the style can be overridden by users, unless it is already at least the minimum required threshold. [Important][] styles that are declared with the [user][user origin] or [user agent][user agent origin] can win the [cascade sort][] over styles with the [author origin][]. - -CSS specifications define each declaration as being either [important][] (if it has the `!important` annotation) or [normal][]. Given that `normal` is also a keyword for some properties, and that `!important` is wider known than this distinction, this rule rather uses "[important][]"/"not [important][]" to avoid confusion. - ### Bibliography - [Understanding Success Criterion 1.4.12: Text Spacing](https://www.w3.org/WAI/WCAG22/Understanding/text-spacing.html) diff --git a/_rules/invalid-form-field-value-36b590.md b/_rules/invalid-form-field-value-36b590.md index dbe5dbfc22c..f6f35eadcdc 100644 --- a/_rules/invalid-form-field-value-36b590.md +++ b/_rules/invalid-form-field-value-36b590.md @@ -1,6 +1,7 @@ --- id: 36b590 name: Error message describes invalid form field value +rules_format: 1.1 rule_type: atomic description: | This rule checks that text error messages provided when the user completes a form field with invalid values or using an invalid format, identify the cause of the error or how to fix the error. @@ -61,14 +62,6 @@ Each test target either has no [form field error indicators][form field error in in [text][] that is [included in the accessibility tree][] or included in the [accessible name][] or [accessible description][] of the test target. -## Assumptions - -There are no assumptions. - -## Accessibility Support - -There are no accessibility support issues known. - ## Background The list of applicable [semantic roles][semantic role] is derived by taking all the [ARIA 1.2][] roles that: @@ -82,6 +75,14 @@ A single [form field error indicator][] can be related to multiple test targets. A single test target can be related to multiple [form field error indicators][form field error indicator]. For example, a text field can have a red border around it, an error icon adjacent to it, an error message below it, and another error message at the top of the form. All of these are error indicators for the same form field. +### Assumptions + +There are no assumptions. + +### Accessibility Support + +There are no accessibility support issues known. + ### Bibliography - [Understanding Success Criterion 3.3.1: Error Identification](https://www.w3.org/WAI/WCAG22/Understanding/error-identification) diff --git a/_rules/link-alone-descriptive-aizyf1.md b/_rules/link-alone-descriptive-aizyf1.md index b4d5299adf7..1f0c3af3be2 100755 --- a/_rules/link-alone-descriptive-aizyf1.md +++ b/_rules/link-alone-descriptive-aizyf1.md @@ -1,6 +1,7 @@ --- id: aizyf1 name: Link is descriptive +rules_format: 1.1 rule_type: atomic description: | This rule checks that the accessible name of a link describes its purpose. @@ -33,17 +34,17 @@ This rule applies to any [inheriting semantic][] `link` for which all the follow Each test target has an [accessible name][] which describes its purpose. -## Assumptions +## Background + +### Assumptions - This rule assumes that the purpose of the link is not ambiguous to users in general when seen in context on the web page, which is the exception mentioned in [Success Criterion 2.4.9 Link Purpose (Link Only)][sc249]. If the link is ambiguous to users in general, users of assistive technologies are not at a disadvantage when viewing the link out of context. - This rule assumes that all [semantic][semantic role] `link` elements are used as links. An element marked up as a link, but that does not behave as a link would not fail [Success Criterion 2.4.9 Link Purpose (Link Only)][sc249]. -## Accessibility Support +### Accessibility Support - Implementation of [Presentational Roles Conflict Resolution][] varies from one browser or assistive technology to another. Depending on this, some [semantic][semantic role] `link` elements can fail this rule with some technology but users of other technologies would not experience any accessibility issue. -## Background - ### Related rules - [Link has non-empty accessible name](https://www.w3.org/WAI/standards-guidelines/act/rules/c487ae/) diff --git a/_rules/link-in-context-descriptive-5effbb.md b/_rules/link-in-context-descriptive-5effbb.md index 58685819197..95070ef88c1 100755 --- a/_rules/link-in-context-descriptive-5effbb.md +++ b/_rules/link-in-context-descriptive-5effbb.md @@ -1,6 +1,7 @@ --- id: 5effbb name: Link in context is descriptive +rules_format: 1.1 rule_type: atomic description: | This rule checks that the accessible name of a link together with its context describes its purpose. @@ -37,18 +38,18 @@ This rule applies to any [inheriting semantic][] `link` for which all the follow The [accessible name][] of each target element together with its [programmatically determined link context][] describes the purpose of the link. -## Assumptions +## Background + +### Assumptions - This rule assumes that the purpose of the link is not ambiguous to users in general when seen in context on the web page, which is the exception mentioned in success criteria [2.4.4 Link Purpose (In Context)][sc244] or [2.4.9 Link Purpose (Link only)][sc249]. If the link is ambiguous to users in general, users of assistive technologies are not at a disadvantage when viewing the link out of context. - This rule assumes that all [semantic][semantic role] `link` elements are used as links. An element marked up as a link, but that does not behave as a link would not fail success criteria [2.4.4 Link Purpose (In Context)][sc244] or [2.4.9 Link Purpose (Link only)][sc249]. -## Accessibility Support +### Accessibility Support - Implementation of [Presentational Roles Conflict Resolution][] varies from one browser or assistive technology to another. Depending on this, some [semantic][semantic role] `link` elements can fail this rule with some technology but users of other technologies would not experience any accessibility issue. -## Background - ### Related rules - [Link has non-empty accessible name](https://www.w3.org/WAI/standards-guidelines/act/rules/c487ae/) diff --git a/_rules/link-non-empty-accessible-name-c487ae.md b/_rules/link-non-empty-accessible-name-c487ae.md index 9c1fd537c24..57c4ae23556 100755 --- a/_rules/link-non-empty-accessible-name-c487ae.md +++ b/_rules/link-non-empty-accessible-name-c487ae.md @@ -1,6 +1,7 @@ --- id: c487ae name: Link has non-empty accessible name +rules_format: 1.1 rule_type: atomic description: | This rule checks that each link has a non-empty accessible name. @@ -53,18 +54,18 @@ This rule applies to any [HTML element][] that is an [inheriting semantic][] `li Each target element has an [accessible name][] that is not empty (`""`). -## Assumptions +## Background + +### Assumptions The rule assumes that all links are [user interface components](https://www.w3.org/TR/WCAG22/#dfn-user-interface-components) as defined by WCAG 2. When the link role is used on elements that do not behave as links, failing this rule might not mean that the success criteria are failed. -## Accessibility Support +### Accessibility Support - For `area` elements that have an `href` attribute, but are not nested inside a `map` element, there are differences between browsers and assistive technology on if the `area` is [included in the accessibility tree][]. - Implementation of [Presentational Roles Conflict Resolution][] varies from one browser or assistive technology to another. Depending on this, some [semantic][semantic role] `link` elements can fail this rule with some technology but users of other technologies would not experience any accessibility issue. - Accessibility support for some elements inheriting the semantic role of `link` (e.g. elements with `doc-*` attributes) may vary depending on the assistive technology in use. -## Background - ### Related rules - [Link in context is descriptive](https://www.w3.org/WAI/standards-guidelines/act/rules/5effbb/) diff --git a/_rules/links-identical-name-equivalent-purpose-b20e66.md b/_rules/links-identical-name-equivalent-purpose-b20e66.md index 9ee15e68a7f..ef2411872fd 100755 --- a/_rules/links-identical-name-equivalent-purpose-b20e66.md +++ b/_rules/links-identical-name-equivalent-purpose-b20e66.md @@ -1,6 +1,7 @@ --- id: b20e66 name: Links with identical accessible names have equivalent purpose +rules_format: 1.1 rule_type: atomic description: | This rule checks that links with identical accessible names resolve to the same resource or equivalent resources. @@ -45,18 +46,18 @@ This rule applies to any set of any two or more [HTML or SVG elements][] for whi When followed, the links in each set of target elements resolve to the [same resource][] or to [equivalent resources](#equivalent-resource). Resolving the links includes potential redirects, if the redirects happen instantly. -## Assumptions +## Background + +### Assumptions - This rule assumes that the purpose of the links with identical [accessible names][accessible name] would not be ambiguous to users in general when seen in context on the web page, which is the exception mentioned in [Success Criterion 2.4.9 Link Purpose (Link Only)][sc249]. If the links are ambiguous to users in general, users of assistive technologies are not at a disadvantage when viewing the links out of context, e.g. on a list of links in a screen reader, which makes it more of a general user experience concern than an accessibility issue. - This rule assumes that, within the context of the test subject, the description provided by the [accessible name][] of a link can only accurately describe one resource (notably, homonyms alone are not used as link names). Thus, if two or more links have the same [accessible name][] but resolve to different resources, at least one of them does not describe its purpose. -## Accessibility Support +### Accessibility Support - This rule assumes that assistive technologies are exposing all links on the page in the same way no matter which [document tree](https://dom.spec.whatwg.org/#document-trees) they are in. If an assistive technology requires the user to "enter" an `iframe` or a [shadow tree][] before exposing its links, then it is possible for two links to have identical name but resolve to different resources without failing [Success Criterion 2.4.9 Link Purpose (Link Only)][sc249] (if said links are in separate [documents][document] or [shadow trees][shadow tree]). - Implementation of [Presentational Roles Conflict Resolution][] varies from one browser or assistive technology to another. Depending on this, some [inheriting semantic][] `link` elements can fail this rule with some technology but users of other technologies would not experience any accessibility issue. -## Background - ### Bibliography - [CSS Scoping Module Level 1 (editor's draft)](https://drafts.csswg.org/css-scoping/) diff --git a/_rules/links-with-identical-names-and-context-serve-equivalent-purpose-fd3a94.md b/_rules/links-with-identical-names-and-context-serve-equivalent-purpose-fd3a94.md index 162a8ca9450..7874f41f371 100755 --- a/_rules/links-with-identical-names-and-context-serve-equivalent-purpose-fd3a94.md +++ b/_rules/links-with-identical-names-and-context-serve-equivalent-purpose-fd3a94.md @@ -1,6 +1,7 @@ --- id: fd3a94 name: Links with identical accessible names and same context serve equivalent purpose +rules_format: 1.1 rule_type: atomic description: | This rule checks that links with identical accessible names in the same context resolve to the same or equivalent resources. @@ -53,16 +54,6 @@ For each pair of links in each target set, one of the following is true: **Note**: Resolving the links includes potential redirects, if the redirects happen instantly. -## Assumptions - -- This rule assumes that, within the context of the test subject, the description provided by the [accessible name][] of a link can only accurately describe one resource (notably, homonyms alone are not used as link names). Thus, if two or more links have the same [accessible name][] but resolve to different resources, at least one of them does not accurately describe its purpose. -- This rule assumes that assistive technologies are exposing all links on the page in the same way no matter which [document tree](https://dom.spec.whatwg.org/#document-trees) they are in. If an assistive technology requires the user to "enter" an `iframe` or a [shadow tree][] before exposing its links, then it is possible for two links to have identical name and context but resolve to different resources without failing [Success Criterion 2.4.4 Link Purpose (In Context)][sc244] (if said links are in separate [documents][document] or [shadow trees][shadow tree]). -- This rule assumes that reading the URL, such as from the status bar when the link is focused, is not considered part of the context, and therefore, it does not disambiguate links. - -## Accessibility Support - -There are no accessibility support issues known. - ## Background There is a difference between two contexts being the _same_ and being _identical_. This rule specifically targets links within the _same_ context. The same context means exactly the same set of DOM nodes. Identical (but not the same) contexts might have a different set of DOM nodes, but those DOM nodes have equivalent content - such as text content, attribute values, and so on. This difference is similar to the difference in some programming languages between pointer equivalence and deep object equivalence. Links with identical name that are in identical (but not the same) contexts also fail [2.4.4 Link Purpose (In Context)][sc244]. However, defining "identical context" unambiguously has been deemed infeasible at this time, and so has been left out of this rule. @@ -71,6 +62,16 @@ Links that are [ambiguous to users in general](https://www.w3.org/TR/WCAG22/#dfn Pages with links that are not [ambiguous to users in general][], but are ambiguous to some users are likely to fail [success criterion 1.3.1 Info and Relationships][sc131] if the disambiguation information is conveyed through presentation, but not semantically. Moreover, when this information is non-text content, such a page is likely to fail [success criterion 1.1.1 Non-text Content][sc111]. +### Assumptions + +- This rule assumes that, within the context of the test subject, the description provided by the [accessible name][] of a link can only accurately describe one resource (notably, homonyms alone are not used as link names). Thus, if two or more links have the same [accessible name][] but resolve to different resources, at least one of them does not accurately describe its purpose. +- This rule assumes that assistive technologies are exposing all links on the page in the same way no matter which [document tree](https://dom.spec.whatwg.org/#document-trees) they are in. If an assistive technology requires the user to "enter" an `iframe` or a [shadow tree][] before exposing its links, then it is possible for two links to have identical name and context but resolve to different resources without failing [Success Criterion 2.4.4 Link Purpose (In Context)][sc244] (if said links are in separate [documents][document] or [shadow trees][shadow tree]). +- This rule assumes that reading the URL, such as from the status bar when the link is focused, is not considered part of the context, and therefore, it does not disambiguate links. + +### Accessibility Support + +There are no accessibility support issues known. + ### Bibliography - [Understanding Success Criterion 2.4.4: Link Purpose (In Context)](https://www.w3.org/WAI/WCAG22/Understanding/link-purpose-in-context.html) @@ -367,13 +368,30 @@ These two SVG `a` elements have the same [accessible name][] and [context][progr ```html

- + Contact us - - + + - - + +

diff --git a/_rules/menuitem-non-empty-name-m6b1q3.md b/_rules/menuitem-non-empty-name-m6b1q3.md index cf73f3bfdb6..a9ef3573293 100755 --- a/_rules/menuitem-non-empty-name-m6b1q3.md +++ b/_rules/menuitem-non-empty-name-m6b1q3.md @@ -1,6 +1,7 @@ --- id: m6b1q3 name: Menuitem has non-empty accessible name +rules_format: 1.1 rule_type: atomic description: | This rule checks that each element with a `menuitem` role has a non-empty accessible name. @@ -31,16 +32,16 @@ This rule applies to [HTML elements][] that is a [semantic][semantic role] `menu Each target element has an [accessible name][] that is not empty (`""`). -## Assumptions +## Background + +### Assumptions This rule assumes that all menuitems are [user interface components as defined by WCAG 2](https://www.w3.org/TR/WCAG22/#dfn-user-interface-components). If an element has a role of `menuitem` that would not be perceived as a single control by users, [4.1.2 Name, Role, Value](https://www.w3.org/TR/WCAG22/#name-role-value) would not apply and so failing this rule would not result in a conformance issue. -## Accessibility Support +### Accessibility Support Implementation of [Presentational Roles Conflict Resolution][] varies from one browser or assistive technology to another. Depending on this, some [semantic][semantic role] `menuitem` elements can fail this rule with some technology but users of other technologies would not experience any accessibility issue. -## Background - ### Bibliography - [Understanding Success Criterion 4.1.2: Name, Role, Value](https://www.w3.org/WAI/WCAG22/Understanding/name-role-value) diff --git a/_rules/meta-refresh-no-delay-bc659a.md b/_rules/meta-refresh-no-delay-bc659a.md index b28b47dbab3..fc0cb43d9a5 100755 --- a/_rules/meta-refresh-no-delay-bc659a.md +++ b/_rules/meta-refresh-no-delay-bc659a.md @@ -1,6 +1,7 @@ --- id: bc659a name: Meta element has no refresh delay +rules_format: 1.1 rule_type: atomic description: | This rule checks that the `meta` element is not used for delayed redirecting or refreshing. @@ -50,15 +51,6 @@ This rule applies to the first `meta` element in a document for which all the fo For each target, the _time_ from the content [attribute value][] is either 0 or more than 72000 (20 hours). To determine the _time_, run the [shared declarative refresh steps][] on the `meta` element as described in the [HTML refresh state](https://html.spec.whatwg.org/multipage/semantics.html#attr-meta-http-equiv-refresh). -## Assumptions - -- This rule assumes no functionality was provided by the website for the user to adjust the timer. -- This rule assumes that the refresh was not [essential](https://www.w3.org/TR/WCAG22/#dfn-essential), which is listed as a valid exception to [2.2.1 Time Adjustable][sc221]. - -## Accessibility Support - -Not all major web browsers parse the value of the `content` attribute in the same way. Some major browsers, when they are unable to parse the value, default to a 0 seconds delay, whereas others will not redirect at all. This can cause some pages to be inapplicable for this rule, while still having a redirect in a minority of web browsers. - ## Background The `meta http-equiv="refresh"` directive is an HTML tag used to instruct browsers to automatically refresh or reload a web page after a specified time interval. This can be useful for updating content dynamically or redirecting users to another page. @@ -67,6 +59,15 @@ The `content` attribute in the `meta http-equiv="refresh"` directive is used to Because a refresh with a timing of 0 is a redirect, it is exempt from this rule. Since this can cause rapid screen flashes it is strongly recommended to avoid this. +### Assumptions + +- This rule assumes no functionality was provided by the website for the user to adjust the timer. +- This rule assumes that the refresh was not [essential](https://www.w3.org/TR/WCAG22/#dfn-essential), which is listed as a valid exception to [2.2.1 Time Adjustable][sc221]. + +### Accessibility Support + +Not all major web browsers parse the value of the `content` attribute in the same way. Some major browsers, when they are unable to parse the value, default to a 0 seconds delay, whereas others will not redirect at all. This can cause some pages to be inapplicable for this rule, while still having a redirect in a minority of web browsers. + ### Bibliography - [Understanding Success Criterion 2.2.1: Timing Adjustable](https://www.w3.org/WAI/WCAG22/Understanding/timing-adjustable.html) diff --git a/_rules/meta-refresh-no-delay-no-exception-bisz58.md b/_rules/meta-refresh-no-delay-no-exception-bisz58.md index e8111ec362e..36cde6d509a 100755 --- a/_rules/meta-refresh-no-delay-no-exception-bisz58.md +++ b/_rules/meta-refresh-no-delay-no-exception-bisz58.md @@ -1,6 +1,7 @@ --- id: bisz58 name: Meta element has no refresh delay (no exception) +rules_format: 1.1 rule_type: atomic description: | This rule checks that the `meta` element is not used for delayed redirecting or refreshing. @@ -51,14 +52,6 @@ This rule applies to the first `meta` element in a document for which all the fo For each target, the _time_ from the content [attribute value][] is 0. To determine the _time_, run the [shared declarative refresh steps][] on the `meta` element as described in the [HTML refresh state](https://html.spec.whatwg.org/multipage/semantics.html#attr-meta-http-equiv-refresh). -## Assumptions - -- This rule assumes that no functionality was provided by the website for the user to adjust the timer. - -## Accessibility Support - -Not all major web browsers parse the value of the `content` attribute in the same way. Some major browsers, when they are unable to parse the value, default to a 0 seconds delay, whereas others will not redirect at all. This can cause some pages to be inapplicable for this rule, while still having a redirect in a minority of web browsers. - ## Background The `meta http-equiv="refresh"` directive is an HTML tag used to instruct browsers to automatically refresh or reload a web page after a specified time interval. This can be useful for updating content dynamically or redirecting users to another page. @@ -67,6 +60,14 @@ The `content` attribute in the `meta http-equiv="refresh"` directive is used to Because a refresh with a timing of 0 is effectively a redirect, it is exempt from this rule. Since refreshing the same page with a time of 0 can cause rapid screen flashes it is strongly recommended to avoid this. +### Assumptions + +- This rule assumes that no functionality was provided by the website for the user to adjust the timer. + +### Accessibility Support + +Not all major web browsers parse the value of the `content` attribute in the same way. Some major browsers, when they are unable to parse the value, default to a 0 seconds delay, whereas others will not redirect at all. This can cause some pages to be inapplicable for this rule, while still having a redirect in a minority of web browsers. + ### Bibliography - [Understanding Success Criterion 2.2.1: Timing Adjustable](https://www.w3.org/WAI/WCAG22/Understanding/timing-adjustable.html) diff --git a/_rules/meta-viewport-b4f0c3.md b/_rules/meta-viewport-b4f0c3.md index 16a64c6974e..ccb47989344 100755 --- a/_rules/meta-viewport-b4f0c3.md +++ b/_rules/meta-viewport-b4f0c3.md @@ -1,6 +1,7 @@ --- id: b4f0c3 name: Meta viewport allows for zoom +rules_format: 1.1 rule_type: atomic description: | This rule checks that the `meta` element retains the user agent ability to zoom. @@ -54,7 +55,9 @@ For each test target's [attribute value][], at least one of the following is tru **Note:** This is equivalent to applying the [translations into a `@viewport` descriptors][descriptor translation] and not obtaining a value smaller than 2 for the `max-zoom` descriptor from [the translation for `maximum-scale`](https://www.w3.org/TR/css-device-adapt-1/#min-scale-max-scale). -## Assumptions +## Background + +### Assumptions Pages for which any of the following is true may satisfy Success Criteria [1.4.4 Resize text][sc144] and [1.4.10 Reflow][sc1410], even if the rule results in a failed outcome. @@ -62,14 +65,12 @@ Pages for which any of the following is true may satisfy Success Criteria [1.4.4 - There is another [mechanism](https://www.w3.org/TR/WCAG22/#dfn-mechanism) available to resize the text content; or - The [content][] does not need to reflow in order to fit in an area of 320 by 256 [CSS pixels][]. -## Accessibility Support +### Accessibility Support Desktop browsers ignore the viewport `meta` element, and most modern mobile browsers either ignore it by default or have an accessibility option which will allow zooming. This rule is not relevant for desktop browsers, nor for most modern mobile browsers. Only users with older mobile browsers can experience issues tested by this rule. The exact way the `content` attribute should be parsed (notably, for error handling) is not fully specified. CSS specification includes a [non-normative parsing algorithm](https://www.w3.org/TR/css-device-adapt-1/#parsing-algorithm). Different user agents may behave differently in some cases. -## Background - ### Bibliography - [Understanding Success Criterion 1.4.4: Resize text](https://www.w3.org/WAI/WCAG22/Understanding/resize-text) diff --git a/_rules/non-visual-reference-alternative-9bd38c.md b/_rules/non-visual-reference-alternative-9bd38c.md index f054381ad0e..1404d48ba7c 100755 --- a/_rules/non-visual-reference-alternative-9bd38c.md +++ b/_rules/non-visual-reference-alternative-9bd38c.md @@ -1,6 +1,7 @@ --- id: 9bd38c name: Content has alternative for visual reference +rules_format: 1.1 rule_type: atomic description: | This rule checks that when content is identified through a visual reference, there are also non-visual references identifying the same content. @@ -44,14 +45,6 @@ For each test target, either it contains none of the [visual reference words][], - **accessible words**: each [visual reference word][] in the test target is included in the [accessible name][] of the identified content; or - **no instruction**: the test target does not give instructions about it through the use of any of the [visual reference words][]. -## Assumptions - -This rule assumes that [visual reference words][] are forms of information conveyed through visual presentation. Therefore, failing this rule fails [Success Criterion 1.3.3 Sensory Characteristics][sc133]. Visual presentation is not limited to CSS and includes images such as the image of a circle with text. - -## Accessibility Support - -There are no accessibility support issues known. - ## Background [Visual reference words][] that can be interpreted with the non-sensory meaning include, in English, expressions like "right after this" where "right" is a [visual reference word][] used with the meaning "immediately"; or words like "below" that is often used with the meaning "further in reading order". @@ -60,6 +53,14 @@ The rule doesn't require the non-visual characteristic description to be include The identified web content does not have to be positioned on the same web page and doesn't need to be linked to from the tested web page. +### Assumptions + +This rule assumes that [visual reference words][] are forms of information conveyed through visual presentation. Therefore, failing this rule fails [Success Criterion 1.3.3 Sensory Characteristics][sc133]. Visual presentation is not limited to CSS and includes images such as the image of a circle with text. + +### Accessibility Support + +There are no accessibility support issues known. + ### Bibliography - [WCAG 2.2 - Understanding Success Criterion 1.3.3: Sensory Characteristics](https://www.w3.org/WAI/WCAG22/Understanding/sensory-characteristics.html) diff --git a/_rules/object-has-accessible-name-8fc3b6.md b/_rules/object-has-accessible-name-8fc3b6.md index f5e7cdb189f..56cdeb30e2e 100644 --- a/_rules/object-has-accessible-name-8fc3b6.md +++ b/_rules/object-has-accessible-name-8fc3b6.md @@ -1,6 +1,7 @@ --- id: 8fc3b6 name: Object element rendering non-text content has non-empty accessible name +rules_format: 1.1 rule_type: atomic description: | This rule checks that each `object` element rendering non-text content has a non-empty accessible name. @@ -36,16 +37,6 @@ This rule applies to any `object` element for which all the following are true: Each target element has an [accessible name][] that is not empty (`""`). -## Assumptions - -_There are currently no assumptions_ - -## Accessibility Support - -Some screen readers announce `object` elements even if they do not have an accessible name, while other skip the element. If an `object` is used to render decorative content, to ensure it is [marked as decorative][] and can be ignored by all major screen readers a presentational role is necessary. - -The [MIME type][] of the resource embedded in the `data` attribute impacts how the [accessible name][] of the `object` is computed. For example, `object` embedding [image MIME type][] may use their `alt` attribute to compute their [accessible name][], but `object` embedding [audio or video MIME types][] may not. An `object` does not officially support the use of an `alt` so this may behave differently according to the browser used. - ## Background Testing that the [accessible name][] describes the purpose of the `object` element is not part of this rule and must be tested separately. @@ -56,6 +47,16 @@ Non-supported media formats make screen readers render the text content of the e When the object resource is not loaded, the fallback content is rendered as shown in the Inapplicable Example: "This `object` element does not need an accessible name because it loads no image, audio, or video." +### Assumptions + +_There are currently no assumptions_ + +### Accessibility Support + +Some screen readers announce `object` elements even if they do not have an accessible name, while other skip the element. If an `object` is used to render decorative content, to ensure it is [marked as decorative][] and can be ignored by all major screen readers a presentational role is necessary. + +The [MIME type][] of the resource embedded in the `data` attribute impacts how the [accessible name][] of the `object` is computed. For example, `object` embedding [image MIME type][] may use their `alt` attribute to compute their [accessible name][], but `object` embedding [audio or video MIME types][] may not. An `object` does not officially support the use of an `alt` so this may behave differently according to the browser used. + ### Bibliography - [Understanding Success Criterion 1.1.1: Non-text Content](https://www.w3.org/WAI/WCAG22/Understanding/non-text-content.html) diff --git a/_rules/presentational-children-no-focusable-content-307n5z.md b/_rules/presentational-children-no-focusable-content-307n5z.md index a5e541cbbd7..e4d78d0b870 100755 --- a/_rules/presentational-children-no-focusable-content-307n5z.md +++ b/_rules/presentational-children-no-focusable-content-307n5z.md @@ -1,6 +1,7 @@ --- id: 307n5z name: Element with presentational children has no focusable content +rules_format: 1.1 rule_type: atomic description: | This rule checks that elements with a role that makes its children presentational do not contain focusable elements. @@ -28,19 +29,19 @@ This rule applies to any [HTML or SVG element][] with a [semantic role][] that d None of the target elements have [descendants][] in the [flat tree][] that are part of [sequential focus navigation][]. -## Assumptions +## Background -This rule assumes that elements that are part of [sequential focus navigation][] do not immediately blur, or move focus to another element. Such elements will fail this rule, but may still satisfy success criterion 4.1.2. +This rule applies to elements with a [semantic role][] that defines its [children][child] to be [presentational children][], which are all of the following: `button`, `checkbox`, `img`, `meter`, `menuitemcheckbox`, `menuitemradio`, `option`, `progressbar`, `radio`, `scrollbar`, `separator`, `slider`, `switch`, and `tab`. -## Accessibility Support +Elements with a [semantic role][] that has [presentational children][] will not have any descendants in the accessibility tree. If any of those descendants are included in [sequential focus navigation][], this causes the focus to land on an element that has no corresponding node in the [accessibility tree][]. The result is that there is no programmatic name or role available for assistive technologies. There are other problems that can come from [presentational children][] too. These must be tested separately. -Several major browsers ignore the WAI-ARIA requirements on [presentational children][] for most or sometimes all roles, or in presence of focusable content. Since some browsers implement presentational children while others do not, pages failing this rule may only be problematic with some browsers. +### Assumptions -## Background +This rule assumes that elements that are part of [sequential focus navigation][] do not immediately blur, or move focus to another element. Such elements will fail this rule, but may still satisfy success criterion 4.1.2. -This rule applies to elements with a [semantic role][] that defines its [children][child] to be [presentational children][], which are all of the following: `button`, `checkbox`, `img`, `meter`, `menuitemcheckbox`, `menuitemradio`, `option`, `progressbar`, `radio`, `scrollbar`, `separator`, `slider`, `switch`, and `tab`. +### Accessibility Support -Elements with a [semantic role][] that has [presentational children][] will not have any descendants in the accessibility tree. If any of those descendants are included in [sequential focus navigation][], this causes the focus to land on an element that has no corresponding node in the [accessibility tree][]. The result is that there is no programmatic name or role available for assistive technologies. There are other problems that can come from [presentational children][] too. These must be tested separately. +Several major browsers ignore the WAI-ARIA requirements on [presentational children][] for most or sometimes all roles, or in presence of focusable content. Since some browsers implement presentational children while others do not, pages failing this rule may only be problematic with some browsers. ### Related rules diff --git a/_rules/printable-characters-shortcut-ffbc54.md b/_rules/printable-characters-shortcut-ffbc54.md index d5fe63d00bf..410d184aa94 100644 --- a/_rules/printable-characters-shortcut-ffbc54.md +++ b/_rules/printable-characters-shortcut-ffbc54.md @@ -1,6 +1,7 @@ --- id: ffbc54 name: No keyboard shortcut uses only printable characters +rules_format: 1.1 rule_type: atomic description: | This rule checks that if keyboard shortcuts are implemented using only printable characters, then there is a mechanism to disable the shortcut, or to remap the shortcut to use one or more non-printable character keys, or the shortcut for a user interface component is only available when that component has focus. @@ -35,15 +36,6 @@ For each test target at least one of the following is true: - **disable/remap**: there is at least one [set of clearly labeled instruments][] to [block events][blocked event] that use the [same key][same key events] as the test target and whose `getModifierState` method returns `false` for each of the [valid modifier keys][]; or - **focus**: the [event target][] is an [inheriting semantic][] `widget`. -## Assumptions - -- If there are ways to disable the result of [keyboard events][keyboard event] that do not require the user to interact with the web page (e.g. a setting at the operating system level), failing this rule might not be a failure of the success criterion. -- After being disabled, the event remains disabled until being re-enabled again. If the event is re-enabled through other non-user controlled means (e.g. a timeout) then this rule may pass while [Success Criterion 2.1.4: Character Key Shortcuts][sc2.1.4] is not satisfied. - -## Accessibility Support - -Currently [keyboard events][keyboard event] only support the types `keydown` and `keyup`. [Keyboard events][keyboard event] of type `keypressed` are considered [legacy keyboard events][] and are thus ignored by this rule. - ## Background The [instruments][instrument] used to pass this rule (if any), must meet all level A Success Criteria in order to fully satisfy [Success Criterion 2.1.4: Character Key Shortcuts][sc2.1.4]. These extra requirements are left out of this rule, and should be tested separately. @@ -51,6 +43,15 @@ This rule allows [changes to the content][changes in content] when a [user inter The "Turn off" and "Remap" requirements from [Success Criterion 2.1.4][sc2.1.4] are combined in the **disable/remap** item of the Expectation section. For the disable requirement, [changes in content][] that are made through [keyboard events][keyboard event] with a [printable character][] value for the `key` attribute and a `getModifierState` return value of `false` for each of the [valid modifier keys][] effectively need to be [blocked][blocked event] (in other words, turned off or disabled). The remap requirement unblocks the events if the `getModifierState` query returns `true` for at least one of the [valid modifier keys][]. Once the `getModifierState` returns `true` for at least one of the [valid modifier keys][] of a [keyboard event][], such [keyboard event][] is no longer applicable for the rule and it passes the "Remap" requirement from [Success Criterion 2.1.4][sc2.1.4]. +### Assumptions + +- If there are ways to disable the result of [keyboard events][keyboard event] that do not require the user to interact with the web page (e.g. a setting at the operating system level), failing this rule might not be a failure of the success criterion. +- After being disabled, the event remains disabled until being re-enabled again. If the event is re-enabled through other non-user controlled means (e.g. a timeout) then this rule may pass while [Success Criterion 2.1.4: Character Key Shortcuts][sc2.1.4] is not satisfied. + +### Accessibility Support + +Currently [keyboard events][keyboard event] only support the types `keydown` and `keyup`. [Keyboard events][keyboard event] of type `keypressed` are considered [legacy keyboard events][] and are thus ignored by this rule. + ### Bibliography - [Understanding Success Criterion 2.1.4: Character Key Shortcuts][sc2.1.4] diff --git a/_rules/role-attribute-valid-value-674b10.md b/_rules/role-attribute-valid-value-674b10.md index 82119941db5..4e0faad1c30 100755 --- a/_rules/role-attribute-valid-value-674b10.md +++ b/_rules/role-attribute-valid-value-674b10.md @@ -1,6 +1,7 @@ --- id: 674b10 name: Role attribute has valid value +rules_format: 1.1 rule_type: atomic description: | This rule checks that each `role` attribute has a valid value. @@ -40,14 +41,6 @@ This rule applies to any `role` attribute for which all the following are true: Each test target has at least one token which is a valid value corresponding to a non-abstract role from [WAI-ARIA Specifications][]. -## Assumptions - -There are no assumptions. - -## Accessibility Support - -Older browsers do not support more than one token in the value for a role attribute. If multiple values are used in the role attribute, the attribute is ignored in these browsers. - ## Background Using an invalid role is often the result of a typo or other developer error. Unknown roles are ignored by browsers and assistive technologies, and the element's [implicit role][] is used. This often means that a role that should exist is missing. @@ -56,6 +49,14 @@ The `role` attribute is a set of [space separated tokens][]. Having a [whitespac Not every role can be used on every element. Which ARIA roles may be used on which HTML elements is defined in [ARIA in HTML](https://www.w3.org/TR/html-aria/). Testing this is not part of this rule. +### Assumptions + +There are no assumptions. + +### Accessibility Support + +Older browsers do not support more than one token in the value for a role attribute. If multiple values are used in the role attribute, the attribute is ignored in these browsers. + ### Bibliography - [List of WAI-ARIA Roles][wai-aria role] diff --git a/_rules/role-required-states-and-properties-4e8ab6.md b/_rules/role-required-states-and-properties-4e8ab6.md index 5aed259c61a..8d4336e1c8c 100755 --- a/_rules/role-required-states-and-properties-4e8ab6.md +++ b/_rules/role-required-states-and-properties-4e8ab6.md @@ -1,6 +1,7 @@ --- id: 4e8ab6 name: Element with role attribute has required states and properties +rules_format: 1.1 rule_type: atomic description: | This rule checks that elements that have an explicit role also specify all required states and properties. @@ -37,21 +38,21 @@ This rule applies to any [HTML or SVG element][] that is [included in the access For each test target, the [WAI-ARIA required states and properties][] for the role are set and not empty (`""`), unless the state or property has a default value listed under [WAI-ARIA implicit value for role][]. -## Assumptions +## Background -- The ARIA `role` is being used to conform to WCAG. +Omitting [WAI-ARIA required states and properties][] is often the result of a developer error. When required properties are missing and a default value is not specified by [WAI-ARIA Specifications][], the behavior is not defined. For [WAI-ARIA 1.2][], the only [explicit semantic roles][explicit semantic role] with a required property with a default value are the `option` and `tabs roles` for the `aria-selected` property. -## Accessibility Support +This rule is testing author built components that specify [explicit semantic roles][explicit semantic role] and not components that keep their [implicit semantic role][]. For components that keep their [implicit semantic role][], all native HTML and SVG elements have native attributes that are mapped to all of the [WAI-ARIA required states and properties](https://www.w3.org/TR/wai-aria/#requiredState). Most of these mappings are defined in the [HTML Accessibility API Mappings, Attribute State and Property Mappings][html aam]. -This rule relies on browsers and assistive technologies to support leaving out [WAI-ARIA required states and properties][] when a [WAI-ARIA implicit value for role][] is specified in [WAI-ARIA Specifications][]. +### Assumptions -**Note:** The required states and properties with implicit values can be found in the Core Accessibility API Mappings 1.1 [Overview of default values for missing required attributes](https://www.w3.org/TR/core-aam-1.1/#authorErrorDefaultValuesTable). +- The ARIA `role` is being used to conform to WCAG. -## Background +### Accessibility Support -Omitting [WAI-ARIA required states and properties][] is often the result of a developer error. When required properties are missing and a default value is not specified by [WAI-ARIA Specifications][], the behavior is not defined. For [WAI-ARIA 1.2][], the only [explicit semantic roles][explicit semantic role] with a required property with a default value are the `option` and `tabs roles` for the `aria-selected` property. +This rule relies on browsers and assistive technologies to support leaving out [WAI-ARIA required states and properties][] when a [WAI-ARIA implicit value for role][] is specified in [WAI-ARIA Specifications][]. -This rule is testing author built components that specify [explicit semantic roles][explicit semantic role] and not components that keep their [implicit semantic role][]. For components that keep their [implicit semantic role][], all native HTML and SVG elements have native attributes that are mapped to all of the [WAI-ARIA required states and properties](https://www.w3.org/TR/wai-aria/#requiredState). Most of these mappings are defined in the [HTML Accessibility API Mappings, Attribute State and Property Mappings][html aam]. +**Note:** The required states and properties with implicit values can be found in the Core Accessibility API Mappings 1.1 [Overview of default values for missing required attributes](https://www.w3.org/TR/core-aam-1.1/#authorErrorDefaultValuesTable). ### Bibliography diff --git a/_rules/scrollable-element-keyboard-accessible-0ssw9k.md b/_rules/scrollable-element-keyboard-accessible-0ssw9k.md index 045624b1712..87b9e0c65ad 100755 --- a/_rules/scrollable-element-keyboard-accessible-0ssw9k.md +++ b/_rules/scrollable-element-keyboard-accessible-0ssw9k.md @@ -1,6 +1,7 @@ --- id: 0ssw9k name: Scrollable content can be reached with sequential focus navigation +rules_format: 1.1 rule_type: atomic description: | This rule checks that scrollable elements or their descendants can be reached with sequential focus navigation so that they can be scrolled by keyboard @@ -44,21 +45,21 @@ For each target element, at least one of the following is true: - the element has a [descendant][] in the [flat tree][] that is included in [sequential focus navigation][]; or - the element is [inert][]. -## Assumptions +## Background -This rule assumes that all [scrollable elements][scrollable] with visible content need to be keyboard accessible. [Scrollable elements][scrollable] that do not need to be keyboard accessible, perhaps because their content is [purely decorative][], the scroll area is whitespace, or because scroll can be controlled in some other keyboard accessible way such as through a button or custom scrollbar, may fail this rule but still satisfy [success criterion 2.1.1 Keyboard][]. +To ensure there is some element from which arrow keys can be used to control the scroll position, focus must be on or in a scrollable region. If scripts are used to prevent the keyboard events from reaching the scrollable region, this could still cause a keyboard accessibility issue. This must be tested separately. -## Accessibility Support +This rule only applies to elements who scroll content in the same document. Elements such as iframes that embed other documents may also be scrollable, but for them it is the embedded document that scrolls, not the content in the same document. Such scenarios are tested separately with rules such as [Iframe with negative tabindex has no interactive elements](https://www.w3.org/WAI/standards-guidelines/act/rules/akn7bn/). -Some browsers will automatically make any [scrollable element][scrollable] focusable to ensure keyboard accessibility. However, the browser does not include these elements in [sequential focus navigation][] when it has a negative number as a tabindex [attribute value][]. +### Assumptions -Some browsers restrict scrolling to the [content box](https://drafts.csswg.org/css-box-4/#content-box) of elements; while others allow to scroll the full [border box](https://drafts.csswg.org/css-box-4/#border-box), hence including the element's padding. This results in some elements being scrollable with a browser but not with another. +This rule assumes that all [scrollable elements][scrollable] with visible content need to be keyboard accessible. [Scrollable elements][scrollable] that do not need to be keyboard accessible, perhaps because their content is [purely decorative][], the scroll area is whitespace, or because scroll can be controlled in some other keyboard accessible way such as through a button or custom scrollbar, may fail this rule but still satisfy [success criterion 2.1.1 Keyboard][]. -## Background +### Accessibility Support -To ensure there is some element from which arrow keys can be used to control the scroll position, focus must be on or in a scrollable region. If scripts are used to prevent the keyboard events from reaching the scrollable region, this could still cause a keyboard accessibility issue. This must be tested separately. +Some browsers will automatically make any [scrollable element][scrollable] focusable to ensure keyboard accessibility. However, the browser does not include these elements in [sequential focus navigation][] when it has a negative number as a tabindex [attribute value][]. -This rule only applies to elements who scroll content in the same document. Elements such as iframes that embed other documents may also be scrollable, but for them it is the embedded document that scrolls, not the content in the same document. Such scenarios are tested separately with rules such as [Iframe with negative tabindex has no interactive elements](https://www.w3.org/WAI/standards-guidelines/act/rules/akn7bn/). +Some browsers restrict scrolling to the [content box](https://drafts.csswg.org/css-box-4/#content-box) of elements; while others allow to scroll the full [border box](https://drafts.csswg.org/css-box-4/#border-box), hence including the element's padding. This results in some elements being scrollable with a browser but not with another. ### Bibliography diff --git a/_rules/sequentially-focusable-element-has-visible-focus-oj04fd.md b/_rules/sequentially-focusable-element-has-visible-focus-oj04fd.md index e9bb08cddeb..cbf9a88ff11 100755 --- a/_rules/sequentially-focusable-element-has-visible-focus-oj04fd.md +++ b/_rules/sequentially-focusable-element-has-visible-focus-oj04fd.md @@ -1,6 +1,7 @@ --- id: oj04fd name: Element in sequential focus order has visible focus +rules_format: 1.1 rule_type: atomic description: | This rule checks that each element in sequential focus order has some visible focus indication. @@ -28,14 +29,6 @@ The rule applies to any element which is part of [sequential focus navigation][] For each target element, there is at least one device pixel inside the [scrolling area][] of the [viewport][] whose [HSL color value](https://www.w3.org/TR/css-color-3/#hsl-color) is different when the element is [focused][] from when it is not. -## Assumptions - -There are no assumptions. - -## Accessibility Support - -There are no accessibility support issues known. - ## Background 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. @@ -44,6 +37,14 @@ WCAG 2.0 and 2.1 do not have any requirement of how big or small focus indicator 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. +### Assumptions + +There are no assumptions. + +### Accessibility Support + +There are no accessibility support issues known. + ### Bibliography - [Success Criterion 2.4.7 Focus Visible][sc247] diff --git a/_rules/summary-non-empty-accessible-name-2t702h.md b/_rules/summary-non-empty-accessible-name-2t702h.md index f3703a7d577..b103f993c66 100755 --- a/_rules/summary-non-empty-accessible-name-2t702h.md +++ b/_rules/summary-non-empty-accessible-name-2t702h.md @@ -1,6 +1,7 @@ --- id: 2t702h name: Summary element has non-empty accessible name +rules_format: 1.1 rule_type: atomic description: | This rule checks that each `summary` element has a non-empty accessible name. @@ -31,14 +32,6 @@ This rule applies to HTML `summary` elements for which all the following are tru Each target element has an [accessible name][] that is not empty (`""`), nor just the name of the `::marker` pseudo element. -## Assumptions - -The rule assumes that all `summary` elements are [user interface components as defined by WCAG 2](https://www.w3.org/TR/WCAG22/#dfn-user-interface-components). - -## Accessibility Support - -There is a difference in how user agents expose the triangle indicating the control's expand state. As a result, some user agents include the triangle in the accessible name of the summary element. - ## Background This rule is only applicable to `summary` elements that the browser will use as controls for a `details` element. While this rule is not applicable to `summary` elements with an [explicit semantic role][], most of the time these likely do still require an [accessible name][]. This is covered by other rules, such as the [Button has non-empty accessible name][97a4e1]. @@ -47,6 +40,14 @@ If the `summary` element is not included in the accessibility tree, but is still Note that some user agents expose the `summary` element with a `button` role. This deviates from the implicit ARIA semantics described in [ARIA in HTML](https://www.w3.org/TR/html-aria/#el-summary). Because some browsers do not give `summary` elements a button role, these elements need to be tested separately from the [Button has non-empty accessible name](https://www.w3.org/WAI/standards-guidelines/act/rules/97a4e1/) ACT rule. +### Assumptions + +The rule assumes that all `summary` elements are [user interface components as defined by WCAG 2](https://www.w3.org/TR/WCAG22/#dfn-user-interface-components). + +### Accessibility Support + +There is a difference in how user agents expose the triangle indicating the control's expand state. As a result, some user agents include the triangle in the accessible name of the summary element. + ### Bibliography - [Understanding Success Criterion 4.1.2: Name, Role, Value](https://www.w3.org/WAI/WCAG22/Understanding/name-role-value) diff --git a/_rules/table-header-cell-has-assigned-cells-d0f69e.md b/_rules/table-header-cell-has-assigned-cells-d0f69e.md index ac2beeef340..317ac998937 100755 --- a/_rules/table-header-cell-has-assigned-cells-d0f69e.md +++ b/_rules/table-header-cell-has-assigned-cells-d0f69e.md @@ -1,6 +1,7 @@ --- id: d0f69e name: Table header cell has assigned cells +rules_format: 1.1 rule_type: atomic description: | This rule checks that each table header has assigned cells in a table element. @@ -36,19 +37,19 @@ This rule applies to any [HTML element][] with a [semantic][semantic role] [rowh Each target element is [assigned][] to at least one element with an [inheriting semantic][] [cell][]. -## Assumptions +## Background + +The roles inheriting from `cell` are `columnheader`, `gridcell`, and `rowheader`. + +### Assumptions This rule assumes that table header cells have a relationship conveyed through presentation with other cells within the same table. This excludes edge cases such as a table definition where there is only one header cell, or a table definition where there are multiple headers and no other cells. In such scenarios the rule fails, but [success criterion 1.3.1 Info and Relationships][sc1.3.1] could still be satisfied. -## Accessibility Support +### Accessibility Support - Table markup and header cell association is not well supported by some popular assistive technologies. Passing this rule can still cause issues for users of those assistive technologies. - Implementation of [Presentational Roles Conflict Resolution][] varies from one browser or assistive technology to another. Depending on this, some elements can have one of the applicable [semantic roles][semantic role] and fail this rule with some technology but users of other technologies would not experience any accessibility issue. -## Background - -The roles inheriting from `cell` are `columnheader`, `gridcell`, and `rowheader`. - ### Bibliography - [Understanding Success Criterion 1.3.1: Information and relationships][sc1.3.1] diff --git a/_rules/table-headers-attribute-refer-to-data-cells-a25f45.md b/_rules/table-headers-attribute-refer-to-data-cells-a25f45.md index 4827ce44796..1452c36891e 100755 --- a/_rules/table-headers-attribute-refer-to-data-cells-a25f45.md +++ b/_rules/table-headers-attribute-refer-to-data-cells-a25f45.md @@ -1,6 +1,7 @@ --- id: a25f45 name: Headers attribute specified on a cell refers to cells in the same table element +rules_format: 1.1 rule_type: atomic description: | This rule checks that the `headers` attribute on a cell refer to other cells in the same `table` element. @@ -42,18 +43,18 @@ Each target's [attribute value][] is a [set of space separated tokens][]. Each t Each target's [attribute value][] is a [set of space separated tokens][], and none of these tokens is the `id` of the element on which the test target is specified. -## Assumptions +## Background + +### Assumptions - This rule assumes that the `headers` attribute is only used to identify table headers. If other information is included in the `headers` attribute, the rule may fail on issues that are not accessibility concerns. For example, if `headers` is used to include information for scripts, this rule may not be accurate. - This rule assumes that the `headers` attribute is required to express the relationship between data and table header cells in the same `table`. If the browser [computes an adequate fallback header][] for cells that have the `headers` [attribute value][] that does not correspond to the `id` of any one cell in the same `table`, success Criterion [1.3.1 Info and Relationships][sc131] may be satisfied even if this rule failed. - This rule assumes that the id values on the `headers` attribute are unique. -## Accessibility Support +### Accessibility Support There are no accessibility support issues known. -## Background - ### Bibliography - [Understanding Success Criterion 1.3.1: Info and Relationships](https://www.w3.org/WAI/WCAG22/Understanding/info-and-relationships.html) diff --git a/_rules/text-contrast-afw4f7.md b/_rules/text-contrast-afw4f7.md index b9cf8b8d60d..0ea41ac67b3 100755 --- a/_rules/text-contrast-afw4f7.md +++ b/_rules/text-contrast-afw4f7.md @@ -1,6 +1,7 @@ --- id: afw4f7 name: Text has minimum contrast +rules_format: 1.1 rule_type: atomic description: | This rule checks that the highest possible contrast of every text character with its background meets the minimal contrast requirement. @@ -36,7 +37,13 @@ This rule applies to any [visible][] character in a [text node][] that is a [chi 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 +## Background + +Passing this rule does not mean that the text has sufficient color contrast. If all background pixels have a low contrast with all foreground pixels, the success criterion is guaranteed to not be satisfied. When some pixels have sufficient contrast, and others do not, legibility should be considered. There is no clear method for determining legibility when some but not all pixels have sufficient contrast, which is why passing this rule does not necessarily mean the corresponding success criterion is met. + +When the text color or background color is not specified in the web page, colors from other [origins][] will be used. Testers must ensure colors are not affected by styles from a [user origin][], such as a custom style sheet. Contrast issues caused by specifying the text color but not the background or vice versa, must be tested separately from this rule. + +### Assumptions - [Success criterion 1.4.3: Contrast (Minimum)][sc143] has exceptions for "incidental" text, which includes inactive user interface components and decorative texts. The rule assumes that [text nodes][text node] that should be ignored are [disabled][] or hidden from assistive technologies. If this isn't the case, the text node could fail this rule while the success criterion could still be satisfied. @@ -46,17 +53,11 @@ For each test target, the [highest possible contrast][] between the [foreground - The definition of [disabled element][disabled] assumes that when the `aria-disabled` attribute is specified on an element, this element has also been disabled for users that do not rely on [assistive technology][]. If this is not the case, that definition may produce incorrect results and in consequence this rule might be Inapplicable to some text nodes that still require a good contrast ratio. -## Accessibility Support +### Accessibility Support - Different browsers have different levels of support for CSS. This can cause contrast issues in one browser that do not appear in another. Because of that, this rule can produce different results depending on the browser that is used. For example, a text that is positioned using CSS transform may be on a different background in a browser that does not support CSS transform. - 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 fail this rule with some technology but users of other technologies would not experience any accessibility issue. -## Background - -Passing this rule does not mean that the text has sufficient color contrast. If all background pixels have a low contrast with all foreground pixels, the success criterion is guaranteed to not be satisfied. When some pixels have sufficient contrast, and others do not, legibility should be considered. There is no clear method for determining legibility when some but not all pixels have sufficient contrast, which is why passing this rule does not necessarily mean the corresponding success criterion is met. - -When the text color or background color is not specified in the web page, colors from other [origins][] will be used. Testers must ensure colors are not affected by styles from a [user origin][], such as a custom style sheet. Contrast issues caused by specifying the text color but not the background or vice versa, must be tested separately from this rule. - ### Bibliography - [Understanding Success Criterion 1.4.3: Contrast (Minimum)](https://www.w3.org/WAI/WCAG22/Understanding/contrast-minimum.html) @@ -301,9 +302,11 @@ This text in a [semantic button][semantic role] has a contrast ratio of 3.85:1. The grey text has a contrast between 2.7:1 and 2.9:1 against the grey text shadow. ```html -

- Some text in a human language -

+

+ Some text in a human language +

``` ### Inapplicable diff --git a/_rules/text-contrast-enhanced-09o5cg.md b/_rules/text-contrast-enhanced-09o5cg.md index 6771d7f287d..96cf62774b8 100644 --- a/_rules/text-contrast-enhanced-09o5cg.md +++ b/_rules/text-contrast-enhanced-09o5cg.md @@ -1,6 +1,7 @@ --- id: 09o5cg name: Text has enhanced contrast +rules_format: 1.1 rule_type: atomic description: | This rule checks that the highest possible contrast of every text character with its background meets the enhanced contrast requirement. @@ -45,7 +46,15 @@ This rule applies to any [visible][] character in a [text node][] that is a [chi 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 +## Background + +Passing this rule does not mean that the text has sufficient color contrast. If all background pixels have a low contrast with all foreground pixels, the success criterion is guaranteed to not be satisfied. When some pixels have sufficient contrast, and others do not, legibility should be considered. There is no clear method for determining legibility when some but not all pixels have sufficient contrast, which is why passing this rule does not necessarily mean the corresponding success criterion is met. + +When the text color or background color is not specified in the web page, colors from other [origins][] will be used. Testers must ensure colors are not affected by styles from a [user origin][], such as a custom style sheet. Contrast issues caused by specifying the text color but not the background or vice versa, must be tested separately from this rule. + +This rule is closely related to [success criterion 1.4.3 Contrast (Minimum)][sc143]. Because this rule is stricter, text that passes this rule will likely satisfy 1.4.3 Contrast (Minimum). + +### Assumptions - [Success criterion 1.4.6 Contrast (Enhanced)][sc146] has exceptions for "incidental" text, which includes inactive user interface components and decorative texts. The rule assumes that [text nodes][text node] that should be ignored are [disabled][] or hidden from assistive technologies. If this isn't the case, the text node could fail this rule while the success criterion could still be satisfied. @@ -55,19 +64,11 @@ For each test target, the [highest possible contrast][] between the [foreground - The definition of [disabled element][disabled] assumes that when the `aria-disabled` attribute is specified on an element, this element has also been disabled for users that do not rely on [assistive technology][]. If this is not the case, that definition may produce incorrect results and in consequence this rule might be Inapplicable to some text nodes that still require a good contrast ratio. -## Accessibility Support +### Accessibility Support - Different browsers have different levels of support for CSS. This can cause contrast issues in one browser that do not appear in another. Because of that, this rule can produce different results depending on the browser that is used. For example, a text that is positioned using CSS transform may be on a different background in a browser that does not support CSS transform. - 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 fail this rule with some technology but users of other technologies would not experience any accessibility issue. -## Background - -Passing this rule does not mean that the text has sufficient color contrast. If all background pixels have a low contrast with all foreground pixels, the success criterion is guaranteed to not be satisfied. When some pixels have sufficient contrast, and others do not, legibility should be considered. There is no clear method for determining legibility when some but not all pixels have sufficient contrast, which is why passing this rule does not necessarily mean the corresponding success criterion is met. - -When the text color or background color is not specified in the web page, colors from other [origins][] will be used. Testers must ensure colors are not affected by styles from a [user origin][], such as a custom style sheet. Contrast issues caused by specifying the text color but not the background or vice versa, must be tested separately from this rule. - -This rule is closely related to [success criterion 1.4.3 Contrast (Minimum)][sc143]. Because this rule is stricter, text that passes this rule will likely satisfy 1.4.3 Contrast (Minimum). - ### Bibliography - [Understanding Success Criterion 1.4.6: Contrast (Enhanced)](https://www.w3.org/WAI/WCAG22/Understanding/contrast-enhanced.html) diff --git a/_rules/video-alternative-for-auditory-eac66b.md b/_rules/video-alternative-for-auditory-eac66b.md index 20de5710d73..08a7a5bc902 100755 --- a/_rules/video-alternative-for-auditory-eac66b.md +++ b/_rules/video-alternative-for-auditory-eac66b.md @@ -1,6 +1,7 @@ --- id: eac66b name: Video element auditory content has accessible alternative +rules_format: 1.1 rule_type: composite description: | This rule checks that `video` elements have an alternative for information conveyed through audio. @@ -49,17 +50,17 @@ For each test target, the [outcome](#outcome) of at least one of the following r - [`Video` Element Content Is Media Alternative For Text](https://www.w3.org/WAI/standards-guidelines/act/rules/ab4d13/) - [`Video` Element Auditory Content Has Captions](https://www.w3.org/WAI/standards-guidelines/act/rules/f51b46/) -## Assumptions +## Background + +### Assumptions - This rule assumes that the video element is used to play synchronized media (video with audio), and that there is a mechanism to start the media. - This rule assumes that the language of each test target can be correctly determined (either programmatically or by analyzing the content), and sufficiently understood. -## Accessibility Support +### Accessibility Support There are no accessibility support issues known. -## Background - ### Bibliography - [Understanding Success Criterion 1.2.2: Captions (Prerecorded)](https://www.w3.org/WAI/WCAG22/Understanding/captions-prerecorded) diff --git a/_rules/video-alternative-for-visual-c5a4ea.md b/_rules/video-alternative-for-visual-c5a4ea.md index 8da247c9a1d..3383977e495 100755 --- a/_rules/video-alternative-for-visual-c5a4ea.md +++ b/_rules/video-alternative-for-visual-c5a4ea.md @@ -1,6 +1,7 @@ --- id: c5a4ea name: Video element visual content has accessible alternative +rules_format: 1.1 rule_type: composite description: | This rule checks that `video` elements with audio have an alternative for the video content as audio or as text. @@ -49,8 +50,6 @@ acknowledgments: - Web Accessibility Perspective videos by W3C WAI. --- -## Test Procedure - ## Applicability This rule applies to every [non-streaming](#non-streaming-media-element) `video` element that is [visible][], where the video contains audio. @@ -63,17 +62,17 @@ For each test target, the [outcome](#outcome) of at least one of the following r - [`Video` Element Visual Content Has Transcript](https://www.w3.org/WAI/standards-guidelines/act/rules/1a02b0/) - [`Video` Element Content Is Media Alternative For Text](https://www.w3.org/WAI/standards-guidelines/act/rules/ab4d13/) -## Assumptions +## Background + +### Assumptions - This rule assumes that a mechanism is available to start the video and that the video element is not simply used to display the [poster](https://www.w3.org/TR/html5/semantics-embedded-content.html#element-attrdef-video-poster). - This rule assumes that the language of each test target can be correctly determined (either programmatically or by analyzing the content), and sufficiently understood. -## Accessibility Support +### Accessibility Support The HTML `video` element can also have a `track` element that provides an audio description. This should provide assistive technologies with a timed text description of visual information in a video. However, there is no native support in any major browser for this technique. Technique [H96: Using the track element to provide audio descriptions](https://www.w3.org/WAI/WCAG22/Techniques/html/H96) can not be relied upon to conform to [1.2.3: Audio Description or Media Alternative (Prerecorded)][sc123]. -## Background - ### Bibliography - [Understanding Success Criterion 1.2.5: Audio Description (Prerecorded)](https://www.w3.org/WAI/WCAG22/Understanding/audio-description-prerecorded.html) diff --git a/_rules/video-as-media-alternative-ab4d13.md b/_rules/video-as-media-alternative-ab4d13.md index d6b4e34cc5e..94a4df17927 100755 --- a/_rules/video-as-media-alternative-ab4d13.md +++ b/_rules/video-as-media-alternative-ab4d13.md @@ -1,6 +1,7 @@ --- id: ab4d13 name: Video element content is media alternative for text +rules_format: 1.1 rule_type: atomic description: | This rule checks non-streaming `video` is a media alternative for text on the page. @@ -32,16 +33,16 @@ All the information contained in each test target is available as text that is [ Each target element is labeled as a video alternative for text on the page by content that is [visible][] and [included in the accessibility tree][]. -## Assumptions +## Background + +### Assumptions This rule assumes that a mechanism is available to start the video and that the video element is not simply used to display the [poster](https://www.w3.org/TR/html5/semantics-embedded-content.html#element-attrdef-video-poster). -## Accessibility Support +### Accessibility Support There are no accessibility support issues known. -## Background - ### Bibliography - [Understanding Success Criterion 1.2.3: Audio Description or Media Alternative (Prerecorded)](https://www.w3.org/WAI/WCAG22/Understanding/audio-description-or-media-alternative-prerecorded) diff --git a/_rules/video-audio-description-1ea59c.md b/_rules/video-audio-description-1ea59c.md index bef49f87699..82507626f52 100755 --- a/_rules/video-audio-description-1ea59c.md +++ b/_rules/video-audio-description-1ea59c.md @@ -1,6 +1,7 @@ --- id: 1ea59c name: Video element visual content has audio description +rules_format: 1.1 rule_type: atomic description: | This rule checks that non-streaming `video` elements have all visual information also contained in the audio. @@ -44,16 +45,16 @@ This rule applies to every [non-streaming](#non-streaming-media-element) `video` The visual information of each test target is available through its audio, or through an audio description track. -## Assumptions +## Background + +### Assumptions This rule assumes that a mechanism is available to start the video and that the video element is not simply used to display the [poster](https://www.w3.org/TR/html5/semantics-embedded-content.html#element-attrdef-video-poster). -## Accessibility Support +### Accessibility Support There are only a few implementations of video players (without third party technologies) that support audio description tracks at the time of writing. -## Background - ### Bibliography - [Understanding Success Criterion 1.2.3: Audio Description or Media Alternative (Prerecorded)](https://www.w3.org/WAI/WCAG22/Understanding/audio-description-or-media-alternative-prerecorded) diff --git a/_rules/video-captions-f51b46.md b/_rules/video-captions-f51b46.md index fe969269b0e..da050232b8f 100755 --- a/_rules/video-captions-f51b46.md +++ b/_rules/video-captions-f51b46.md @@ -1,6 +1,7 @@ --- id: f51b46 name: Video element auditory content has captions +rules_format: 1.1 rule_type: atomic description: | This rule checks that captions are available for audio information in non-streaming `video` elements. @@ -47,16 +48,16 @@ For each test target, audio information that is not conveyed visually in the vid **Note:** Captions can be either embedded in the video file itself or can be made available trough a separate track. -## Assumptions +## Background + +### Assumptions This rule assumes that the video element is used to play a video (for example, not only used to display an image), and that there is a mechanism to start the video. -## Accessibility Support +### Accessibility Support There are no accessibility support issues known. -## Background - ### Bibliography - [Understanding Success Criterion 1.2.2: Captions (Prerecorded)](https://www.w3.org/WAI/WCAG22/Understanding/captions-prerecorded) diff --git a/_rules/video-description-track-f196ce.md b/_rules/video-description-track-f196ce.md index 228577925a5..3fb36cd4c6e 100755 --- a/_rules/video-description-track-f196ce.md +++ b/_rules/video-description-track-f196ce.md @@ -1,6 +1,7 @@ --- id: f196ce name: Video element visual content has description track +rules_format: 1.1 rule_type: atomic description: | This rule checks that description tracks that come with non-streaming `video` elements are descriptive. @@ -43,18 +44,18 @@ The visual information of each test target not available through its audio is de _Note_: Multiple description `track` elements may be useful for different languages, but at least one must match the language of the video. -## Assumptions +## Background + +### Assumptions This rule assumes that a mechanism is available to start the video and that the video element is not simply used to display the [poster](https://www.w3.org/TR/html5/semantics-embedded-content.html#element-attrdef-video-poster). -## Accessibility Support +### Accessibility Support Currently the description track is not supported by most assistive technology. Accessibility support for the description track attribute is relatively low to non-existent. Video players may be able to work around the lack of support for the description track by using aria-live but few do this today. This means that the rule can only provide a pass for these success criteria if assistive technology support the description track or if the video player that is used has implemented such a work around. -## Background - ### Bibliography - [Understanding Success Criterion 1.2.3: Audio Description or Media Alternative (Prerecorded)](https://www.w3.org/WAI/WCAG22/Understanding/audio-description-or-media-alternative-prerecorded) diff --git a/_rules/video-only-alternative-for-visual-c3232f.md b/_rules/video-only-alternative-for-visual-c3232f.md index 7be3b45db54..919dc497070 100755 --- a/_rules/video-only-alternative-for-visual-c3232f.md +++ b/_rules/video-only-alternative-for-visual-c3232f.md @@ -1,6 +1,7 @@ --- id: c3232f name: Video element visual-only content has accessible alternative +rules_format: 1.1 rule_type: composite description: | This rule checks that `video` elements without audio have an alternative available. @@ -53,17 +54,17 @@ For each test target, the [outcome](#outcome) of at least one of the following r - [`Video` Element Visual-Only Content Has Transcript](https://www.w3.org/WAI/standards-guidelines/act/rules/ee13b5/) - [`Video` Element Visual-Only Content Has Audio Track Alternative](https://www.w3.org/WAI/standards-guidelines/act/rules/d7ba54/) -## Assumptions +## Background + +### Assumptions - A mechanism is available to start the video and the video element is not simply used to display the [poster](https://html.spec.whatwg.org/multipage/media.html#attr-video-poster). - The language of each test target can be correctly determined (either programmatically or by analyzing the content), and sufficiently understood. -## Accessibility Support +### Accessibility Support The HTML `video` element can also have a `track` element that provides an audio description. This should provide assistive technologies with a timed text description of visual information in a video. However, there is no native support in any major browser for this technique. Technique [H96: Using the track element to provide audio descriptions](https://www.w3.org/WAI/WCAG22/Techniques/html/H96) can not be relied upon to conform to [1.2.1: Audio-only and Video-only (Prerecorded)](https://www.w3.org/TR/WCAG22/#audio-only-and-video-only-prerecorded). -## Background - ### Bibliography - [Understanding Success Criterion 1.2.1: Audio-only and Video-only (Prerecorded)](https://www.w3.org/WAI/WCAG22/Understanding/audio-only-and-video-only-prerecorded) diff --git a/_rules/video-only-as-media-alternative-fd26cf.md b/_rules/video-only-as-media-alternative-fd26cf.md index 71a749f1549..84a5123c79c 100755 --- a/_rules/video-only-as-media-alternative-fd26cf.md +++ b/_rules/video-only-as-media-alternative-fd26cf.md @@ -1,6 +1,7 @@ --- id: fd26cf name: Video element visual-only content is media alternative for text +rules_format: 1.1 rule_type: atomic description: | This rule checks non-streaming silent `video` is a media alternative for text on the page. @@ -32,17 +33,17 @@ All the information contained in each target element is available as text (direc Each target element is labeled as a video alternative for text on the page by content that is [visible][] and [included in the accessibility tree][]. -## Assumptions +## Background -A mechanism is available to start the video and that the video element is not simply used to display the [poster](https://www.w3.org/TR/html5/semantics-embedded-content.html#element-attrdef-video-poster). +The term [label](https://www.w3.org/TR/WCAG22/#dfn-labels) used in expectations 2 and 3 does not refer to the `label` element. -## Accessibility Support +### Assumptions -There are no accessibility support issues known. +A mechanism is available to start the video and that the video element is not simply used to display the [poster](https://www.w3.org/TR/html5/semantics-embedded-content.html#element-attrdef-video-poster). -## Background +### Accessibility Support -The term [label](https://www.w3.org/TR/WCAG22/#dfn-labels) used in expectations 2 and 3 does not refer to the `label` element. +There are no accessibility support issues known. ### Bibliography diff --git a/_rules/video-only-audio-track-d7ba54.md b/_rules/video-only-audio-track-d7ba54.md index e912d77bcb6..69863875b88 100755 --- a/_rules/video-only-audio-track-d7ba54.md +++ b/_rules/video-only-audio-track-d7ba54.md @@ -1,6 +1,7 @@ --- id: d7ba54 name: Video element visual-only content has audio track alternative +rules_format: 1.1 rule_type: atomic description: | Non-streaming `video` elements without audio must have an audio alternative. @@ -33,16 +34,16 @@ This rule applies to any [non-streaming](#non-streaming-media-element) `video` e The visual information of each test target is available through an audio track. -## Assumptions +## Background + +### Assumptions This rule assumes that a mechanism is available to start the video and that the video element is not simply used to display the [poster](https://www.w3.org/TR/html5/semantics-embedded-content.html#element-attrdef-video-poster). -## Accessibility Support +### Accessibility Support There are no accessibility support issues known. -## Background - ### Bibliography - [Understanding Success Criterion 1.2.1: Audio-only and Video-only (Prerecorded)](https://www.w3.org/WAI/WCAG22/Understanding/audio-only-and-video-only-prerecorded) diff --git a/_rules/video-only-description-track-ac7dc6.md b/_rules/video-only-description-track-ac7dc6.md index 3b7d5e21e9e..c8dae91a4ac 100755 --- a/_rules/video-only-description-track-ac7dc6.md +++ b/_rules/video-only-description-track-ac7dc6.md @@ -1,6 +1,7 @@ --- id: ac7dc6 name: Video element visual-only content has description track +rules_format: 1.1 rule_type: atomic description: | This rule checks that description tracks that come with non-streaming `video` elements, without audio, are descriptive. @@ -36,17 +37,17 @@ This rule applies to every [non-streaming](#non-streaming-media-element) `video` The visual information of each test target is described with a description `track` element that has the same language as the video or the same language as the page. -## Assumptions +## Background -This rule assumes that a mechanism is available to start the video and that the video element is not simply used to display the [poster](https://www.w3.org/TR/html5/semantics-embedded-content.html#element-attrdef-video-poster). +Multiple description `track` elements may be useful for different languages, but at least one must match the language of the video or the language of the page. -## Accessibility Support +### Assumptions -Currently the description track is not supported by most assistive technologies. Video players may be able to work around the lack of support for the description track by using aria-live but few do this today. +This rule assumes that a mechanism is available to start the video and that the video element is not simply used to display the [poster](https://www.w3.org/TR/html5/semantics-embedded-content.html#element-attrdef-video-poster). -## Background +### Accessibility Support -Multiple description `track` elements may be useful for different languages, but at least one must match the language of the video or the language of the page. +Currently the description track is not supported by most assistive technologies. Video players may be able to work around the lack of support for the description track by using aria-live but few do this today. ### Bibliography diff --git a/_rules/video-only-transcript-ee13b5.md b/_rules/video-only-transcript-ee13b5.md index 91d134dc0f0..ba38d2bdb07 100755 --- a/_rules/video-only-transcript-ee13b5.md +++ b/_rules/video-only-transcript-ee13b5.md @@ -1,6 +1,7 @@ --- id: ee13b5 name: Video element visual-only content has transcript +rules_format: 1.1 rule_type: atomic description: | Non-streaming `video` elements without audio must have all visual information available in a transcript. @@ -38,17 +39,17 @@ This rule applies to any [non-streaming](#non-streaming-media-element) `video` e The visual information of each test target is available through a text transcript that is [visible][], [included in the accessibility tree][], and is either on the page or linked. -## Assumptions +## Background -A mechanism is available to start the video and that the video element is not simply used to display the [poster](https://www.w3.org/TR/html5/semantics-embedded-content.html#element-attrdef-video-poster). +A "text transcript" in the context of this rule is defined in WCAG 2 as an [alternative for time based media](https://www.w3.org/TR/WCAG22/#dfn-alternative-for-time-based-media). -## Accessibility Support +### Assumptions -There are no accessibility support issues known. +A mechanism is available to start the video and that the video element is not simply used to display the [poster](https://www.w3.org/TR/html5/semantics-embedded-content.html#element-attrdef-video-poster). -## Background +### Accessibility Support -A "text transcript" in the context of this rule is defined in WCAG 2 as an [alternative for time based media](https://www.w3.org/TR/WCAG22/#dfn-alternative-for-time-based-media). +There are no accessibility support issues known. ### Bibliography diff --git a/_rules/video-strict-alternative-for-visual-1ec09b.md b/_rules/video-strict-alternative-for-visual-1ec09b.md index bb83b4d63e4..5da24482a22 100755 --- a/_rules/video-strict-alternative-for-visual-1ec09b.md +++ b/_rules/video-strict-alternative-for-visual-1ec09b.md @@ -1,6 +1,7 @@ --- id: 1ec09b name: Video element visual content has strict accessible alternative +rules_format: 1.1 rule_type: composite description: | This rule checks that `video` elements with audio have audio description. @@ -50,17 +51,17 @@ For each test target, the [outcome](#outcome) of at least one of the following r - [`Video` Element Visual Content Has Audio Description](https://www.w3.org/WAI/standards-guidelines/act/rules/1ea59c/) - [`Video` Element Content Is Media Alternative For Text](https://www.w3.org/WAI/standards-guidelines/act/rules/ab4d13/) -## Assumptions +## Background + +### Assumptions - This rule assumes that a mechanism is available to start the video and that the video element is not simply used to display the [poster](https://www.w3.org/TR/html5/semantics-embedded-content.html#element-attrdef-video-poster). - This rule assumes that the language of each test target can be correctly determined (either programmatically or by analyzing the content), and sufficiently understood. -## Accessibility Support +### Accessibility Support The HTML `video` element can also have a `track` element that provides an audio description. This should provide assistive technologies with a timed text description of visual information in a video. However, there is no native support in any major browser for this technique. Technique [H96: Using the track element to provide audio descriptions](https://www.w3.org/WAI/WCAG22/Techniques/html/H96) can not be relied upon to conform to [1.2.5: Audio Description (Prerecorded)](https://www.w3.org/TR/WCAG22/#audio-description-prerecorded). -## Background - ### Bibliography - [Understanding Success Criterion 1.2.5: Audio Description (Prerecorded)](https://www.w3.org/WAI/WCAG22/Understanding/audio-description-prerecorded.html) diff --git a/_rules/video-transcript-1a02b0.md b/_rules/video-transcript-1a02b0.md index bf66b19e91b..4411dac0f2b 100755 --- a/_rules/video-transcript-1a02b0.md +++ b/_rules/video-transcript-1a02b0.md @@ -1,6 +1,7 @@ --- id: 1a02b0 name: Audio and visuals of video element have transcript +rules_format: 1.1 rule_type: atomic description: | This rule checks that non-streaming `video` elements have all audio and visual information available in a transcript. @@ -45,16 +46,16 @@ The visual information of each test target is available through a text transcrip **Note:** A "text transcript" in the context of this rule is defined in WCAG 2 as an [alternative for time based media](https://www.w3.org/TR/WCAG22/#dfn-alternative-for-time-based-media). -## Assumptions +## Background + +### Assumptions This rule assumes that a mechanism is available to start the video and that the video element is not simply used to display the [poster](https://www.w3.org/TR/html5/semantics-embedded-content.html#element-attrdef-video-poster). -## Accessibility Support +### Accessibility Support There are no accessibility support issues known. -## Background - ### Bibliography - [Understanding Success Criterion 1.2.3: Audio Description or Media Alternative (Prerecorded)](https://www.w3.org/WAI/WCAG22/Understanding/audio-description-or-media-alternative-prerecorded) diff --git a/_rules/visible-label-in-accessible-name-2ee8b8.md b/_rules/visible-label-in-accessible-name-2ee8b8.md index 88618546b93..ac679646e82 100755 --- a/_rules/visible-label-in-accessible-name-2ee8b8.md +++ b/_rules/visible-label-in-accessible-name-2ee8b8.md @@ -1,6 +1,7 @@ --- id: 2ee8b8 name: Visible label is part of accessible name +rules_format: 1.1 rule_type: atomic description: | This rule checks that interactive elements labeled through content have their visible label as part of their accessible name. @@ -40,19 +41,19 @@ This rule applies to any element for which all the following is true: For each target element, all [text nodes][] in the [visible text content][] [match characters][] and are contained within the [accessible name][] of this target element, except for characters in the [text nodes][] used to express [non-text content][]. Leading and trailing [whitespace][] and difference in case sensitivity should be ignored. -## Assumptions +## Background -This rule assumes that all resources needed for rendering the page are properly loaded. Checking if resources are missing is out of the scope of rules. Missing resources may be rendered as text (for example, missing `img` are rendered as their `alt` attribute). +This rule applies to elements with a [widget role][] that [support name from content][supports name from content]. This includes the following: `button`, `checkbox`, `gridcell`, `link`, `menuitem`, `menuitemcheckbox`, `menuitemradio`, `option`, `radio`, `searchbox`, `switch`, `tab`, `treeitem`. -## Accessibility Support +The understanding document of [2.5.3 Label in Name][understand253] use the term "symbolic text characters" to refer to a type of [non-text content][] that uses text characters as symbols, such as using "x" to mean "close". This rule considers them as "characters expressing non-text content". Unicode emojis are another example of characters expressing non-text content, although these are not "symbolic text characters". -Implementation of [Presentational Roles Conflict Resolution][] varies from one browser or assistive technology to another. Depending on this, some elements can have one of the applicable [semantic roles][semantic role] and fail this rule with some technology but users of other technologies would not experience any accessibility issue. +### Assumptions -## Background +This rule assumes that all resources needed for rendering the page are properly loaded. Checking if resources are missing is out of the scope of rules. Missing resources may be rendered as text (for example, missing `img` are rendered as their `alt` attribute). -This rule applies to elements with a [widget role][] that [support name from content][supports name from content]. This includes the following: `button`, `checkbox`, `gridcell`, `link`, `menuitem`, `menuitemcheckbox`, `menuitemradio`, `option`, `radio`, `searchbox`, `switch`, `tab`, `treeitem`. +### Accessibility Support -The understanding document of [2.5.3 Label in Name][understand253] use the term "symbolic text characters" to refer to a type of [non-text content][] that uses text characters as symbols, such as using "x" to mean "close". This rule considers them as "characters expressing non-text content". Unicode emojis are another example of characters expressing non-text content, although these are not "symbolic text characters". +Implementation of [Presentational Roles Conflict Resolution][] varies from one browser or assistive technology to another. Depending on this, some elements can have one of the applicable [semantic roles][semantic role] and fail this rule with some technology but users of other technologies would not experience any accessibility issue. ### Bibliography diff --git a/_rules/zoom-text-no-overflow-clipping-59br37.md b/_rules/zoom-text-no-overflow-clipping-59br37.md index c9506e26d43..464f3b987b4 100755 --- a/_rules/zoom-text-no-overflow-clipping-59br37.md +++ b/_rules/zoom-text-no-overflow-clipping-59br37.md @@ -1,6 +1,7 @@ --- id: 59br37 name: Zoomed text node is not clipped with CSS overflow +rules_format: 1.1 rule_type: atomic description: | This rule checks that text nodes are not unintentionally clipped by overflow, when a page is zoomed to 200% on 1280 by 1024 viewport; @@ -41,7 +42,11 @@ Each test target is not [horizontally clipped by overflow][horizontally clipped] Each test target is not [vertically clipped by overflow][vertically clipped] of an [ancestor][] in the [flat tree][] when in a [viewport size][] of 640 by 512, except if the [clipping][vertically clipped] [ancestor][] has a [used][] [line-height][] equal to or greater than the height of its [bounding box][], or in case of a [computed][] [overflow-y][overflow] of `clip`, its [content box][]. -## Assumptions +## Background + +When the [computed][] value of the `line-height` property is `normal`, the [used][] value depends on font specific metrics. [CSS specifications][line-height normal] recommend that the [used][] value is between 1.0 and 1.2 and major browsers are effectively using values close to 1.2. + +### Assumptions If any of the following assumptions is true, failing this rule may not result in a failure of [success criterion 1.4.4 Resize text](https://www.w3.org/TR/WCAG22/#resize-text): @@ -51,14 +56,10 @@ If any of the following assumptions is true, failing this rule may not result in - While [success criterion 1.4.4 Resize text](https://www.w3.org/TR/WCAG22/#resize-text) does not explicitly mention which viewport size has to be resized up to 200%, it is assumed that a [viewport size][] of 1280 by 1024 is applicable. A 1280 by 1024 [viewport size][] is explicitly mentioned under [success criterion 1.4.10 Reflow](https://www.w3.org/TR/WCAG22/#reflow). -## Accessibility Support +### Accessibility Support Some user agents treat the value of the `aria-hidden` attribute as case-sensitive. -## Background - -When the [computed][] value of the `line-height` property is `normal`, the [used][] value depends on font specific metrics. [CSS specifications][line-height normal] recommend that the [used][] value is between 1.0 and 1.2 and major browsers are effectively using values close to 1.2. - ### Bibliography - [Understanding Success Criterion 1.4.4: Resize text](https://www.w3.org/WAI/WCAG22/Understanding/resize-text.html) diff --git a/pages/design/atomic-template-empty.md b/pages/design/atomic-template-empty.md index df5fee5eba6..7944ed605e3 100755 --- a/pages/design/atomic-template-empty.md +++ b/pages/design/atomic-template-empty.md @@ -1,6 +1,7 @@ --- id: name: +rules_format: 1.1 rule_type: atomic description: | This rule checks ... @@ -46,17 +47,29 @@ This rule applies to any (??) element ... Each target element ... -## Assumptions +## Background + +- (e.g. WCAG Techniques or links with background information mentioned in Applicability, Expectations or Assumptions) + +### Assumptions There are no assumptions. -## Accessibility Support +### Accessibility Support There are no accessibility support issues known. -## Background +### Related Rules -- (e.g. WCAG Techniques or links with background information mentioned in Applicability, Expectations or Assumptions) + + +- [rule name here](./abc123) + +### Bibliography + + + +- [link here](#) ## Test Cases diff --git a/pages/design/composite-template-empty.md b/pages/design/composite-template-empty.md index a8037bd07ae..967c7180e73 100755 --- a/pages/design/composite-template-empty.md +++ b/pages/design/composite-template-empty.md @@ -1,6 +1,7 @@ --- id: name: +rules_format: 1.1 rule_type: composite description: | This rule checks ... @@ -49,17 +50,29 @@ For each test target, the outcome of (at least one of | all of | any of etc.) th - [Rule name](relative_link_to_rule.html) - ... -## Assumptions +## Background + +- (e.g. WCAG Techniques or links with background information mentioned in Applicability, Expectations or Assumptions) + +### Assumptions There are no assumptions. -## Accessibility Support +### Accessibility Support There are no accessibility support issues known. -## Background +### Related Rules + + + +- [rule name here](./abc123) + +### Bibliography + + -- - (e.g. WCAG Techniques or links with background information mentioned in Applicability, Expectations or Assumptions) +- [link here](#) ## Test Cases diff --git a/pages/design/manual-template-empty.md b/pages/design/manual-template-empty.md index d619d930eb6..ba43aa16c63 100644 --- a/pages/design/manual-template-empty.md +++ b/pages/design/manual-template-empty.md @@ -1,6 +1,7 @@ --- id: name: +rules_format: 1.1 rule_type: atomic description: | This rule checks ... @@ -52,17 +53,29 @@ This rule applies to any (??) element ... Each target element ... -## Assumptions +## Background + +- (e.g. WCAG Techniques or links with background information mentioned in Applicability, Expectations or Assumptions) + +### Assumptions There are no assumptions. -## Accessibility Support +### Accessibility Support There are no accessibility support issues known. -## Background +### Related Rules -- (e.g. WCAG Techniques or links with background information mentioned in Applicability, Expectations or Assumptions) + + +- [rule name here](./abc123) + +### Bibliography + + + +- [link here](#) ## Test Cases diff --git a/pages/design/rule-design.md b/pages/design/rule-design.md index 1a3353779c5..446acaca38b 100755 --- a/pages/design/rule-design.md +++ b/pages/design/rule-design.md @@ -2,7 +2,7 @@ title: Rule Design --- -The WCAG-ACT-RULES-CG rule design builds on WCAG 2.x and its supporting documents. To achieve the goals the following approach is based on [ACT Rules Format 1.0](https://www.w3.org/TR/act-rules-format/): +The WCAG-ACT-RULES-CG rule design builds on WCAG 2.x and its supporting documents. To achieve the goals the following approach is based on [ACT Rules Format](https://www.w3.org/TR/act-rules-format/): 1. **[Rule properties](#rule-properties)**: Define the test subject and its environment. Includes identifier, name, type and description, as well as other meta data. @@ -10,11 +10,11 @@ The WCAG-ACT-RULES-CG rule design builds on WCAG 2.x and its supporting document 3. **[Expectations](#expectations)**: Assert what must be true about the target elements, in order for them to pass the rule. -4. **[Assumptions](#assumptions)**: Explicitly state all assumptions made by the rule to ensure accountability of the results. +4. **[Background](#background)**: Provide information on relevant resources referenced when developing the rule. -5. **[Accessibility Support](#accessibility-support)**: Provide information on any known feature support issues from assistive technologies or user agents. +5. **[Assumptions](#assumptions)**: Explicitly state all assumptions made by the rule to ensure accountability of the results. -6. **[Background](#background)**: Provide information on relevant resources referenced when developing the rule. +6. **[Accessibility Support](#accessibility-support)**: Provide information on any known feature support issues from assistive technologies or user agents. 7. **[Test cases](#test-cases)**: Define a range of code examples that demonstrate pass, fail and inapplicable outcomes for readers and for validating implementations. diff --git a/pages/design/rule-template.md b/pages/design/rule-template.md index e1b808f4387..58168347e96 100755 --- a/pages/design/rule-template.md +++ b/pages/design/rule-template.md @@ -12,6 +12,7 @@ Use the [empty atomic rule template](https://raw.githubusercontent.com/act-rules --- id: name: +rules_format: 1.1 rule_type: atomic description: | This rule checks ... @@ -57,14 +58,6 @@ This rule applies to any (??) element ... Each target element ... -## Assumptions - -There are no assumptions. - -## Accessibility Support - -There are no accessibility support issues known. - ## Background - Links to Techniques for WCAG 2.2 @@ -74,6 +67,26 @@ There are no accessibility support issues known. - The WCAG 2.2 Techniques already contain examples and code snippets to illustrate which content passes or fails the test. Whenever possible WCAG-ACT-RULES-CG refers to those. Another source for test cases is the W3C Before and After Demonstration. - Other references +### Assumptions + +There are no assumptions. + +### Accessibility Support + +There are no accessibility support issues known. + +### Related Rules + + + +- [rule name here](./abc123) + +### Bibliography + + + +- [link here](#) + ## Test Cases ### Passed @@ -131,6 +144,7 @@ For more about composite rules, see the [ACT Rules Format](https://www.w3.org/TR --- id: name: +rules_format: 1.1 rule_type: composite description: | This rule checks ... @@ -177,14 +191,6 @@ For each test target, the outcome of (at least one of / all of / any of etc.) th - [Rule name](relative_link_to_rule.html) - ... -## Assumptions - -There are no assumptions. - -## Accessibility Support - -There are no accessibility support issues known. - ## Background - Links to Techniques for WCAG 2.2 @@ -194,6 +200,26 @@ There are no accessibility support issues known. - The WCAG 2.2 Techniques already contain examples and code snippets to illustrate which content passes or fails the test. Whenever possible WCAG-ACT-RULES-CG refers to those. Another source for test cases is the W3C Before and After Demonstration. - Other references +### Assumptions + +There are no assumptions. + +### Accessibility Support + +There are no accessibility support issues known. + +### Related Rules + + + +- [rule name here](./abc123) + +### Bibliography + + + +- [link here](#) + ## Test Cases ### Passed diff --git a/pages/glossary/outcome.md b/pages/glossary/outcome.md index e2604d6523a..feb36091450 100755 --- a/pages/glossary/outcome.md +++ b/pages/glossary/outcome.md @@ -5,12 +5,21 @@ unambiguous: true objective: true --- -An _outcome_ is a conclusion that comes from evaluating an ACT Rule on a [test subject](https://www.w3.org/TR/act-rules-format/#test-subject) or one of its constituent [test target](https://www.w3.org/TR/act-rules-format/#test-target). An outcome can be one of the three following types: +A conclusion that comes from evaluating an ACT Rule on a [test subject][] or one of its constituent test target. An outcome can be one of the five following types: - **Inapplicable:** No part of the test subject matches the applicability -- **Passed:** A [test target](https://www.w3.org/TR/act-rules-format/#test-target) meets all expectations -- **Failed:** A [test target](https://www.w3.org/TR/act-rules-format/#test-target) does not meet all expectations +- **Passed:** A [test target][] meets all expectations +- **Failed:** A [test target][] does not meet all expectations +- **cantTell:** Whether the rule is applicable, or not all expectations were met could not be fully determined by the tester. +- **Untested**: The tester has not attempted to evaluate the test subject. -**Note:** A rule has one `passed` or `failed` outcome for every [test target](https://www.w3.org/TR/act-rules-format/#test-target). When there are no test targets the rule has one `inapplicable` outcome. This means that each [test subject](https://www.w3.org/TR/act-rules-format/#test-subject) will have one or more outcomes. +**Note**: A rule has one `passed` or `failed` outcome for every [test target][]. When a tester evaluates a test target it can also be reported as `cantTell` if the rule cannot be tested in its entirety. For example, when applicability was automated, but the expectations have to be evaluated manually. -**Note:** Implementations using the [EARL10-Schema](https://www.w3.org/TR/EARL10-Schema/) can express the outcome with the [outcome property](https://www.w3.org/TR/EARL10-Schema/#outcome). In addition to `passed`, `failed` and `inapplicable`, EARL 1.0 also defined an `incomplete` outcome. While this cannot be the outcome of an ACT Rule when applied in its entirety, it often happens that rules are only partially evaluated. For example, when applicability was automated, but the expectations have to be evaluated manually. Such "interim" results can be expressed with the `incomplete` outcome. +When there are no test targets the rule has one `inapplicable` outcome. If the tester is unable to determine whether there are test targets there will be one `cantTell` outcome. And when no evaluation has occurred the test target has one untested outcome. This means that each [test subject][] always has one or more outcomes. + +Outcomes used in ACT Rules can be expressed using the [outcome property][] of the [[EARL10-Schema]][]. + +[test subject]: https://www.w3.org/TR/act-rules-format-1.1/#test-subject +[test target]: https://www.w3.org/TR/act-rules-format/#test-target +[outcome property]: https://www.w3.org/TR/EARL10-Schema/#outcome +[earl10-schema]: https://www.w3.org/TR/act-rules-format-1.1/#biblio-earl10-schema