Move secondary requirement texts out of the background #2060

WilcoFiers · 2023-05-16T13:01:10Z

This PR moves the secondary requirements text out of the background and in with the requirement itself. This work is related to the following PRs:

I will do the rest of the texts once I've got agreement from the group that this is a good way to write these.

Need for Call for Review: 1 week

How to Review And Approve

Go to the “Files changed” tab
Here you will have the option to leave comments on different lines.
Once the review is completed, find the “Review changes” button in the top right, select “Approve” (if you are really confident in the rule) or "Request changes" and click “Submit review”.
Make sure to also review the proposed Call for Review period. In case of disagreement, the longer period wins.

_rules/meta-refresh-no-delay-no-exception-bisz58.md

_rules/text-contrast-afw4f7.md

…t-rules.github.io into secondary-requirement-texts

tbostic32 · 2023-05-18T13:24:33Z

_rules/text-contrast-afw4f7.md

-    failed: not satisfied
-    passed: further testing needed
-    inapplicable: further testing needed
+    secondary: Because this success criterion has a higher minimum contrast, it is stricter than the rule. This is also why some passed examples do not satisfy this success criterion.


Suggested change

secondary: Because this success criterion has a higher minimum contrast, it is stricter than the rule. This is also why some passed examples do not satisfy this success criterion.

secondary: Because this success criterion has a higher minimum contrast, it is stricter than the rule. This is why some passed examples do not satisfy this success criterion.

Jym77

Yes, I think that's the good place to put these explanations 👍

WilcoFiers · 2023-07-26T16:57:45Z

_rules/image-no-text-0va7u6.md

-<img alt="WCAG Rocks" src="data:image/svg+xml;utf8,
+<img
+	alt="WCAG Rocks"
+	src="data:image/svg+xml;utf8,
 <svg xmlns='http://www.w3.org/2000/svg' height='20px' width='80px'>
  <text x='0' y='15'>WCAG Rocks</text>
-</svg>" />
+</svg>"
+/>


This was Prettier's doing.

tbostic32

My only final comment would be that we use the word "this" a lot in these definitions. The normal template seems to be "This success criterion .... this rule. This is because.... This rule". I'm not sure if we can or should cut down on the repetition, but it does feel a bit overly wordy to me, but maybe thats just personal preference.

_rules/link-non-empty-accessible-name-c487ae.md

tbostic32 · 2023-07-27T12:44:43Z

_rules/links-identical-name-equivalent-purpose-b20e66.md

@@ -11,7 +11,7 @@ accessibility_requirements:
    passed: further testing needed
    inapplicable: further testing needed
 wcag20:2.4.4: # Link Purpose (In Context) (A)
-secondary: true
+secondary: This success criterion is **less strict** than this rule. This is because the rule does not consider the context of the link. This is why some of the failed examples may not satisfy this success criterion.


If the success criterion is less strict, shouldn't the failed examples potentially satisfy the criterion (e.g., where the link text does not provide the purpose but the context does).

In regard to @tbostic32's concerns with the over-use of the word "this"...
Without commenting on the accuracy of the statements, a rewrite of the prior secondary could be:

This success criterion is less strict than this rule because the rule does not consider the context of the link. Some of the failed examples may not satisfy this success criterion.

@tbostic32's second comment seems correct to me just reading the sentence statements. If the following is not accurate, then I think there's a larger problem here...

This success criterion is less strict than this rule because the rule does not consider the context of the link. Some of the failed examples may ~~not~~ satisfy this success criterion.

tbostic32 · 2023-07-27T12:45:32Z

_rules/aria-state-or-property-valid-value-6a7281.md

@@ -12,9 +12,9 @@ accessibility_requirements:
    passed: satisfied
    inapplicable: satisfied
  wcag20:1.3.1: # Info and Relationships (A)
-    secondary: true
+    secondary: This success criterion is **less strict** than this rule. This is because the rule does not ignore irrelevant ARIA properties. This is why some of the failed examples may not satisfy this success criterion.


Similar to m other comment, but shouldn't less strict criterion mean some of the failed examples may satisfy the criterion?

Co-authored-by: Trevor R. Bostic <[email protected]>

WilcoFiers · 2023-07-27T13:25:00Z

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

@@ -6,9 +6,9 @@ description: |
  This rule checks that each `aria-` attribute specified is defined in ARIA 1.2.
 accessibility_requirements:
  wcag20:1.3.1: # Info and Relationships (A)
-    secondary: true
+    secondary: This success criterion is **less strict** than this rule. This is because the rule does not ignore irrelevant ARIA properties. This is why some of the failed examples may not satisfy this success criterion.


Suggested change

secondary: This success criterion is **less strict** than this rule. This is because the rule does not ignore irrelevant ARIA properties. This is why some of the failed examples may not satisfy this success criterion.

secondary: This success criterion is **less strict** than this rule. This is because the rule does not ignore irrelevant ARIA properties. Some of the failed examples satisfy this success criterion.

@WilcoFiers and others ... I would want us to define the "some" where as you'd want to map to what are the "some" examples that people can reference in context of what fails / passes as secondary reqs. Thanks!

Suggested change

secondary: This success criterion is **less strict** than this rule. This is because the rule does not ignore irrelevant ARIA properties. This is why some of the failed examples may not satisfy this success criterion.

secondary: This success criterion is less strict than this rule. This is because the rule does not ignore irrelevant ARIA properties. Additionally, some of the failed examples meet this success criterion.

I agree that the second sentence should be "warning, some failed examples pass the SC" rather than "warning, some failed examples fail the SC", because the later is the normal behaviour of rules.

I'd rather keep some emphasis on "less strict" (like the bolding here), to show this is some sort of keyword. I'd even push toward having one such emphasised term in each secondary explanation since it can help us (and readers) categorise them ("less strict", "more strict", "partial", …) Once we get a bit more usage on these secondary requirements, we may even include these terms in the ACt rules format (or a similar document), with detailed explanation about what they mean.

agree that the "this is why" is a bit of a mouthful after a sentence full of "thus rule" and "this SC". Another possibility could be:

Therefore, some FE do satisfy the SC.

I'm also not a huge fan of "may (not)" in the "some (passed/failed) example may (not) satisfy the SC". I feel it collides a bit with the RFC 2119 usage of these terms which is somewhat different here. This sounds like an instruction to rule writers (or part of the format): "when a SC is less strict, you MAY write FE that satisfy this SC"; while here we describe a more static state: "there exist FE that satisfy the SC, deal with it".
(plus "may not satisfy" is always slightly ambiguous between "(may not) satisfy" (= are forbidden to satisfy) and "may (not satisfy)" (=are not forced to satisfy); "do not satisfy" doesn't have this ambiguity)

kengdoj · 2023-07-27T14:14:54Z

_rules/link-non-empty-accessible-name-c487ae.md

@@ -27,7 +26,7 @@ accessibility_requirements:
    passed: further testing needed
    inapplicable: further testing needed
  wcag20:1.1.1: # Non-text content (A)
-    secondary: true
+    secondary: This success criterion **partially overlaps** this rule. This is because the HTML `area` element counts as both a link and as non-text content. This is why some of the failed examples may not satisfy this success criterion.


Suggested change

secondary: This success criterion **partially overlaps** this rule. This is because the HTML `area` element counts as both a link and as non-text content. This is why some of the failed examples may not satisfy this success criterion.

secondary: This success criterion is **conditionally applicable** in this rule. It is applicable because the HTML `area` element counts as both a link and as non-text content. Most failed examples satisfy this success criterion.

I didn't see how an explanation would be written for Keyboard Trap Example 7 in this PR, but I thought "partially" would work better there than here.

For Ex.7: This SC is partially covered in this rule because the rule does not test for other possible solutions. As a result, this SC may be satisfied by some failed examples.

maryjom · 2023-07-27T15:30:21Z

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

@@ -6,9 +6,9 @@ description: |
  This rule checks that each `aria-` attribute specified is defined in ARIA 1.2.
 accessibility_requirements:
  wcag20:1.3.1: # Info and Relationships (A)
-    secondary: true
+    secondary: This success criterion is **less strict** than this rule. This is because the rule does not ignore irrelevant ARIA properties. This is why some of the failed examples may not satisfy this success criterion.


This rule is more strict than the success criterion because it does not ignore irrelevant ARIA properties. Therefore, some of the reported failures can be false positives rather than a success criterion failure.

My comment carries to the rest of the examples where this text appears. It was a little difficult to read and understand, as written.

I'm not a huge fan of using the term "false positives" here, since it has a connotation of "the rule is bad and generate false positives" while we want to carry the information "this rule is designed for a slightly different use case and tangentially affects this use case".

Typically, in a color contrast case, saying that the 1.4.6 rule "reports false positives (for 1.4.3)" is technically true but sounds a bit dramatic.

I like the change from saying "the rule more strict" (than the SC) to "the SC is less strict" (than the rule).

Jym77 · 2023-08-10T08:39:35Z

__tests__/frontmatter.js

+			if (!accReq) {
+				return
+			} else if (accReq.secondary) {


Note: depending on our ES target, we may be able to use optional chaining:

Suggested change

if (!accReq) {

return

} else if (accReq.secondary) {

if (accReq?.secondary) {

That's not quite the same. Doing it the way you suggests triggers the tests on line 107 / 108, which would then fail.

Jym77 · 2023-08-10T08:45:37Z

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

@@ -6,9 +6,9 @@ description: |
  This rule checks that each `aria-` attribute specified is defined in ARIA 1.2.
 accessibility_requirements:
  wcag20:1.3.1: # Info and Relationships (A)
-    secondary: true
+    secondary: This success criterion is **less strict** than this rule. This is because the rule does not ignore irrelevant ARIA properties. This is why some of the failed examples may not satisfy this success criterion.


I agree that the second sentence should be "warning, some failed examples pass the SC" rather than "warning, some failed examples fail the SC", because the later is the normal behaviour of rules.

I'd rather keep some emphasis on "less strict" (like the bolding here), to show this is some sort of keyword. I'd even push toward having one such emphasised term in each secondary explanation since it can help us (and readers) categorise them ("less strict", "more strict", "partial", …) Once we get a bit more usage on these secondary requirements, we may even include these terms in the ACt rules format (or a similar document), with detailed explanation about what they mean.

agree that the "this is why" is a bit of a mouthful after a sentence full of "thus rule" and "this SC". Another possibility could be:

Therefore, some FE do satisfy the SC.

I'm also not a huge fan of "may (not)" in the "some (passed/failed) example may (not) satisfy the SC". I feel it collides a bit with the RFC 2119 usage of these terms which is somewhat different here. This sounds like an instruction to rule writers (or part of the format): "when a SC is less strict, you MAY write FE that satisfy this SC"; while here we describe a more static state: "there exist FE that satisfy the SC, deal with it".
(plus "may not satisfy" is always slightly ambiguous between "(may not) satisfy" (= are forbidden to satisfy) and "may (not satisfy)" (=are not forced to satisfy); "do not satisfy" doesn't have this ambiguity)

Jym77 · 2023-08-10T08:50:27Z

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

@@ -6,9 +6,9 @@ description: |
  This rule checks that each `aria-` attribute specified is defined in ARIA 1.2.
 accessibility_requirements:
  wcag20:1.3.1: # Info and Relationships (A)
-    secondary: true
+    secondary: This success criterion is **less strict** than this rule. This is because the rule does not ignore irrelevant ARIA properties. This is why some of the failed examples may not satisfy this success criterion.


I'm not a huge fan of using the term "false positives" here, since it has a connotation of "the rule is bad and generate false positives" while we want to carry the information "this rule is designed for a slightly different use case and tangentially affects this use case".

Typically, in a color contrast case, saying that the 1.4.6 rule "reports false positives (for 1.4.3)" is technically true but sounds a bit dramatic.

Jym77 · 2023-08-10T08:59:00Z

_rules/image-no-text-0va7u6.md

@@ -12,7 +12,6 @@ accessibility_requirements:
    inapplicable: further testing needed
  wcag20:1.4.9: # Images of Text (No Exception) (AAA)
    forConformance: true
-    secondary: true


While I understand why this has been removed (together with the Background note), I feel this requires a specific PR just to make 1.4.9 a primary requirement instead.

(implementer hat on), making the requirement primary may make my implementation "partially consistent" if it doesn't already report it. That requires me to update my report. An easy fix, but I'd rather track that change to an ACT PR that focuses on it.
(Alfa is actually not having an implementation of this rule, but you get the idea).

The real reason I did this is because I couldn't come up with an explanation of why this was secondary. If you have one I don't mind putting it in, but I don't think there's anything I can put in here. This rule assumes that the difference between 1.4.5 and 1.4.9 doesn't occur, and so the rule maps to those criteria the same way.

I can put this into a separate PR, but I can't merge this one until that separate PR would then be merged. I did it this way to avoid introducing a blocking PR. Are you okay with that @Jym77?

Jym77 · 2023-08-10T08:59:45Z

_rules/image-no-text-0va7u6.md

@@ -12,7 +12,6 @@ accessibility_requirements:
    inapplicable: further testing needed
  wcag20:1.4.9: # Images of Text (No Exception) (AAA)
    forConformance: true
-    secondary: true


Also, we made 1.4.6 a secondary requirement for the 1.4.3 rule, while it always fail.
Iirc, that was due to the fact that 1.4.6 is AAA and some tools don't report AAA failures, but that shouldn't prevent them to claim consistency on the 1.4.3 rule.

How is that case different?

See above. This rule assume there is the difference between 1.4.5 and 1.4.9 never occurs. That's why we don't have two rules for image-no-text. There is no difference in how we test 1.4.5 and 1.4.9. For color contrast the numbers are different, and so we have two different rules.

I'm confused 😕

Back in #1920 when we added secondary requirements, part of the reasoning in the PR description was:

Their implementations are reported as partially consistent for not failing a AAA success criterion, even though the implementor does not support AAA to begin with. [in the 1.4.3/1.4.6 case]

This, in turn, linked to w3c/wcag-act-rules#134 which has pretty much the same description:

reporting against AAA criteria should not be required by tools that don't support AAA criteria.

The later is marked as fixed by w3c/wcag-act#531 which updates the format (to allow secondary requirements) but doesn't change the tool consistency checking by discarding AAA mapping for AA tools or something like that.

How will that not recreate the same situation?
Tools/methods that only check AA level won't report AAA SC, hence they won't report 1.4.9 on these test cases. Which part of our machinery (something in act-tools?) will let them claim a consistent implementation of the rule?

There are two reasons why an implementation may not report an accessibility requirement and still be consistent:

The requirement is secondary

The requirement is of a conformance level the implementation does not support

I think what you were expecting is for secondary requirements to cover both situations. That's not the intent. This is exactly an example of why that difference is necessary. If an implementation supports AAA, then it must report both 1.4.5 and 1.4.9 as not satisfied when this rule fails, Otherwise it is partially consistent. An implementation that only covers AA is not required to report 1.4.9.

Whether or not it can report 1.4.9 is an open question, and is possibly a topic for TPAC.

I still do not understand why 1.4.9 shouldn't be a more strict secondary requirement 🤔

How is the 1.4.5/1.4.9 case (and the 2.1.1/2.1.3 one) different from the 2.4.4/2.4.9, the 1.4.3/1.4.6, the 1.2.3/1.2.5-1.2.8, or the 2.2.1/2.2.4-3.2.5 ones?
This PR keeps a more strict secondary requirement for the 4 later cases, but changes the first two as primary requirements instead. What is the criterion to decide that a more strict SC is a secondary or primary requirement? (shouldn't we instead try and find Passed Examples that fail the more strict SC?)

I won't block the PR due to that, it seems I'm misunderstanding something. I guess we can talk through that at TPAC.

I'll take another crack at explaining, but yes, lets take this to TPAC.

The way I think of it, and why I ended up doing it this way is because this rule effectively treats those 1.4.5 and 1.4.9 as identical criteria. The assumption effectively says there is no difference, and so they are tested in the same way, and only require one rule. Compare that to 2.2.1 / 2.2.4. There are two rules for it. One with the 20 hour exception and one without. Similarly 1.4.3 / 1.4.6. Two rules, one with a 4.5:1 contrast, and one with a 7:1 contrast.

I can explain why the rule for 1.4.3 is less strict than 1.4.6: The number is lower. I can explain why the rule for 2.2.1 is less strict than 2.2.4: The rule has a 20 hour exception. There is no difference between how 1.4.5 is measured and how 1.4.9 is measured. The rule assume it.

Updated, please check again

_rules/meta-viewport-b4f0c3.md

_rules/text-contrast-enhanced-09o5cg.md

_rules/role-required-states-and-properties-4e8ab6.md

_rules/role-attribute-valid-value-674b10.md

_rules/link-non-empty-accessible-name-c487ae.md

_rules/meta-refresh-no-delay-no-exception-bisz58.md

pages/design/rule-design.md

kengdoj

mostly editorial, and one suggestion to deprecate the meta viewport rule.

pages/design/rule-design.md

Co-authored-by: Kathy Eng <[email protected]>

bruce-usab · 2023-08-23T21:25:42Z

_rules/image-no-text-0va7u6.md

@@ -56,7 +55,7 @@ There are no accessibility support issues known.

 ## Background

-This rule is designed specifically for [SC 1.4.5 Images of Text][sc1.4.5] which includes exceptions to the images it applies to that are not part of [SC 1.4.9 Images of Text (No Exception)][sc1.4.9]. Therefore, some images that are inapplicable for this rule can be applicable to [SC 1.4.9 Images of Text (No Exception)][sc1.4.9].
+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.


While I agree that SC 1.4.5 and 1.4.9 are very similar, I do not agree with characterization of "only minimal differences" because using the Essential exception for logotypes is very common.

But maybe there is a precondition for the applicability of this test?

I think the confusion here comes from this "No exception" thing in the title of that SC. 1.4.9 does allow text where presentation is essential (like logos) and text that is purely decorative. The only difference between 1.4.5 and 1.4.9 is that 1.4.5 allows images of text if the text can be customised.

bruce-usab

Approve, but please see my inline comment/question regarding logotypes and the Essential Exception for 1.4.5.

Jym77

There are a couple of typos in the design document. These should be fixed but aren't a huge deal either.
I still do not understand why some more strict SC are listed as more strict secondary requirement, and some are listed as primary requirements (without the less strict SC being listed as less strict secondary requirement either). Won't block because of that, though.
I love the "design" bit 😄 Good work in clarifying the situation.

pages/design/rule-design.md

Jym77 · 2023-08-28T08:55:40Z

_rules/image-no-text-0va7u6.md

@@ -12,7 +12,6 @@ accessibility_requirements:
    inapplicable: further testing needed
  wcag20:1.4.9: # Images of Text (No Exception) (AAA)
    forConformance: true
-    secondary: true


I still do not understand why 1.4.9 shouldn't be a more strict secondary requirement 🤔

How is the 1.4.5/1.4.9 case (and the 2.1.1/2.1.3 one) different from the 2.4.4/2.4.9, the 1.4.3/1.4.6, the 1.2.3/1.2.5-1.2.8, or the 2.2.1/2.2.4-3.2.5 ones?
This PR keeps a more strict secondary requirement for the 4 later cases, but changes the first two as primary requirements instead. What is the criterion to decide that a more strict SC is a secondary or primary requirement? (shouldn't we instead try and find Passed Examples that fail the more strict SC?)

I won't block the PR due to that, it seems I'm misunderstanding something. I guess we can talk through that at TPAC.

Jym77 · 2023-08-28T08:56:23Z

_rules/scrollable-element-keyboard-accessible-0ssw9k.md

@@ -12,7 +12,6 @@ accessibility_requirements:
    inapplicable: further testing needed
  wcag20:2.1.3: # Keyboard (No Exceptions) (AAA)
    forConformance: true
-    secondary: true


Also not sure why this shouldn't be a more strict secondary requirement instead.

Co-authored-by: Jean-Yves Moyen <[email protected]>

* Move secondary requirement texts out of the background * Apply suggestions from code review * fix test * Fix failing test * Secondary reqs on ARIA rules * Update all secondary requirements * Typos * Fix failing tests * Update _rules/link-non-empty-accessible-name-c487ae.md Co-authored-by: Trevor R. Bostic <[email protected]> * Tweaked the language some more * Update rule design info for secondary requirements * Fix tests * Apply suggestions from code review Co-authored-by: Kathy Eng <[email protected]> * Apply suggestions from code review Co-authored-by: Jean-Yves Moyen <[email protected]> --------- Co-authored-by: Trevor R. Bostic <[email protected]> Co-authored-by: Kathy Eng <[email protected]> Co-authored-by: Jean-Yves Moyen <[email protected]>

…2125) * Update programmatically-determined-link-context.md * Update iframe-not-focusable-has-no-interactive-content-akn7bn.md * Update programmatically-determined-link-context.md * Update iframe-not-focusable-has-no-interactive-content-akn7bn.md * Create modal-dialog * Rename modal-dialog to modal-dialog.md * Update iframe-not-focusable-has-no-interactive-content-akn7bn.md * Update iframe-not-focusable-has-no-interactive-content-akn7bn.md * Apply suggestions from code review Co-authored-by: Dan Tripp <[email protected]> * Update iframe-not-focusable-has-no-interactive-content-akn7bn.md * Update and rename modal-dialog.md to inert.md * Update iframe-not-focusable-has-no-interactive-content-akn7bn.md * Update iframe-not-focusable-has-no-interactive-content-akn7bn.md * Update spelling-ignore.yml * Update iframe-not-focusable-has-no-interactive-content-akn7bn.md * Update inert.md * Apply suggestions from code review Co-authored-by: Jean-Yves Moyen <[email protected]> Co-authored-by: Dan Tripp <[email protected]> * Update iframe-not-focusable-has-no-interactive-content-akn7bn.md * Update inert.md * Apply suggestions from code review Co-authored-by: Wilco Fiers <[email protected]> * AGWG Updates (#2067) * Add (alt="") for clarity on empty alt * Resolve focus visible feedback * Tweak contrast rules * Tweak page title descriptive * Fix tests * Apply suggestions from code review Co-authored-by: Trevor R. Bostic <[email protected]> --------- Co-authored-by: Trevor R. Bostic <[email protected]> * [cae760] Frame has non-empty accessible name (#2034) * First pass in response to Feb 16 TF meeting * typo * Update _rules/iframe-non-empty-accessible-name-cae760.md Co-authored-by: Wilco Fiers <[email protected]> * Update _rules/iframe-non-empty-accessible-name-cae760.md Co-authored-by: Wilco Fiers <[email protected]> * Update _rules/iframe-non-empty-accessible-name-cae760.md Co-authored-by: Wilco Fiers <[email protected]> * Update _rules/iframe-non-empty-accessible-name-cae760.md Co-authored-by: Wilco Fiers <[email protected]> * Update _rules/iframe-non-empty-accessible-name-cae760.md Co-authored-by: Wilco Fiers <[email protected]> * Move note about frame to background * Set height for frame * Test wants alphabetical contributors * Update _rules/iframe-non-empty-accessible-name-cae760.md Co-authored-by: Jean-Yves Moyen <[email protected]> * Update _rules/iframe-non-empty-accessible-name-cae760.md Co-authored-by: Jean-Yves Moyen <[email protected]> * Update _rules/iframe-non-empty-accessible-name-cae760.md Co-authored-by: Jean-Yves Moyen <[email protected]> * Move note to background --------- Co-authored-by: Wilco Fiers <[email protected]> Co-authored-by: Jean-Yves Moyen <[email protected]> * Updating glossary definition. (#2069) * Bump yaml and zx (#2056) * Bump yaml and zx Bumps [yaml](https://github.com/eemeli/yaml) to 2.2.2 and updates ancestor dependency [zx](https://github.com/google/zx). These dependencies need to be updated together. Updates `yaml` from 1.10.2 to 2.2.2 - [Release notes](https://github.com/eemeli/yaml/releases) - [Commits](eemeli/yaml@v1.10.2...v2.2.2) Updates `zx` from 5.3.0 to 7.2.1 - [Release notes](https://github.com/google/zx/releases) - [Commits](google/zx@5.3.0...7.2.1) --- updated-dependencies: - dependency-name: yaml dependency-type: indirect - dependency-name: zx dependency-type: direct:development ... Signed-off-by: dependabot[bot] <[email protected]> * Trigger CLA? --------- Signed-off-by: dependabot[bot] <[email protected]> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com> Co-authored-by: Jean-Yves Moyen <[email protected]> * new rule: ARIA required ID references exist (#2041) * new rule: ARIA required ID references exist * Address review comments Co-authored-by: Carlos Duarte <[email protected]> * Apply suggestions from code review Co-authored-by: Jean-Yves Moyen <[email protected]> * Apply suggestions from code review Co-authored-by: Tom Brunet <[email protected]> Co-authored-by: Jean-Yves Moyen <[email protected]> * Update _rules/aria-required-id-references-in6db8.md * Apply suggestions from code review Co-authored-by: Carlos Duarte <[email protected]> --------- Co-authored-by: Carlos Duarte <[email protected]> Co-authored-by: Jean-Yves Moyen <[email protected]> Co-authored-by: Tom Brunet <[email protected]> * scrollable element: clarify the title (#2083) * UpdateTableHeaderRule (#2074) * UpdateTableHeaderRule * Update table-header-cell-has-assigned-cells-d0f69e.md * trigger test * Update _rules/table-header-cell-has-assigned-cells-d0f69e.md Co-authored-by: Jean-Yves Moyen <[email protected]> --------- Co-authored-by: Wilco Fiers <[email protected]> Co-authored-by: Jean-Yves Moyen <[email protected]> * Adds apostrophe to mark the possessive form (#2080) Co-authored-by: Wilco Fiers <[email protected]> * Focus visible rule: Fix typo (#2082) * Contrast rules: Tweak background text (#2090) * Tweak name / description of Scrollable element keyboard (#2092) * Deprecate HTML page lang and xml:lang attributes have matching values (#2086) * Deprecate HTML page lang and xml:lang attributes have matching values * Apply suggestions from code review Co-authored-by: Carlos Duarte <[email protected]> --------- Co-authored-by: Carlos Duarte <[email protected]> * Rephrase Applicability (#2079) * Rename file (#2078) * Move secondary requirement texts out of the background (#2060) * Move secondary requirement texts out of the background * Apply suggestions from code review * fix test * Fix failing test * Secondary reqs on ARIA rules * Update all secondary requirements * Typos * Fix failing tests * Update _rules/link-non-empty-accessible-name-c487ae.md Co-authored-by: Trevor R. Bostic <[email protected]> * Tweaked the language some more * Update rule design info for secondary requirements * Fix tests * Apply suggestions from code review Co-authored-by: Kathy Eng <[email protected]> * Apply suggestions from code review Co-authored-by: Jean-Yves Moyen <[email protected]> --------- Co-authored-by: Trevor R. Bostic <[email protected]> Co-authored-by: Kathy Eng <[email protected]> Co-authored-by: Jean-Yves Moyen <[email protected]> * fix test on secondary requirements (#2102) * fix test on secondary requirements * More assertions * Update _rules/aria-required-id-references-in6db8.md Co-authored-by: Jean-Yves Moyen <[email protected]> --------- Co-authored-by: Jean-Yves Moyen <[email protected]> * Update dependencies (including act-tools) (#2103) * fix test-assets not getting built right (#2104) * Update element-lang-valid-de46e4.md (#2100) Co-authored-by: Jean-Yves Moyen <[email protected]> * fix the approve-rule action (#2105) * Remove outdated accsupport note (#2111) * "Element with lang attribute has valid language tag" [de46e4]: Updated Failed Examples 4 and 5 to reflect Applicability (#2094) * Update element-lang-valid-de46e4.md Updated Failed examples 4 and 5 to reflect applicability * Apply suggestions from code review Co-authored-by: Jean-Yves Moyen <[email protected]> * Update _rules/element-lang-valid-de46e4.md Co-authored-by: Dan Tripp <[email protected]> --------- Co-authored-by: Jean-Yves Moyen <[email protected]> Co-authored-by: Dan Tripp <[email protected]> Co-authored-by: Carlos Duarte <[email protected]> * Text spacing rewrite (#1923) * Add new letter-spacing rule and deprecate old one * Add new word-spacing rule and deprecate old one * Clean up assumptions * Clean up * Clean up * Add new line-height rule and deprecate old one * Replace old letter spacing version rather than deprecating it * Replace old line height version rather than deprecating it * Replace old word spacing version rather than deprecating it * Target text nodes * Improve background note * Apply suggestion from review * Clean up * Target text nodes rather than their parents * Target text nodes rather than their parents * Add missing reference * Update example * Apply to parent of text nodes, not text nodes * Apply suggestions from code review Co-authored-by: Carlos Duarte <[email protected]> * Typos Co-authored-by: Carlos Duarte <[email protected]> * Typos --------- Co-authored-by: Carlos Duarte <[email protected]> * "Meta viewport allows for zoom" (b4f0c3): Explicit meaning of 'has' (#1994) * Explicit meaning of 'has' * Improve expectation and examples * Typo * Improve algorithm description Co-authored-by: Carlos Duarte <[email protected]> * Rephrase expectations * Streamline Applicability * Typo * Simplify expectations --------- Co-authored-by: Carlos Duarte <[email protected]> * Map Empty-heading rule to ARIA instead of WCAG (#2120) Co-authored-by: Jean-Yves Moyen <[email protected]> * Deprecate 4.1.1 rules (#2117) Co-authored-by: Jean-Yves Moyen <[email protected]> --------- Signed-off-by: dependabot[bot] <[email protected]> Co-authored-by: giacomo-petri <[email protected]> Co-authored-by: Carlos Duarte <[email protected]> Co-authored-by: Dan Tripp <[email protected]> Co-authored-by: Wilco Fiers <[email protected]> Co-authored-by: Trevor R. Bostic <[email protected]> Co-authored-by: Tom Brunet <[email protected]> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com> Co-authored-by: HelenBurge <[email protected]> Co-authored-by: Wilco Fiers <[email protected]> Co-authored-by: Daniel Montalvo <[email protected]> Co-authored-by: Kathy Eng <[email protected]>

Move secondary requirement texts out of the background

5f48d0e

WilcoFiers commented May 17, 2023

View reviewed changes

_rules/meta-refresh-no-delay-no-exception-bisz58.md Outdated Show resolved Hide resolved

_rules/text-contrast-afw4f7.md Outdated Show resolved Hide resolved

WilcoFiers and others added 3 commits May 17, 2023 11:06

Apply suggestions from code review

0ad26ef

fix test

2024439

Merge branch 'secondary-requirement-texts' of github.com:act-rules/ac…

00565c2

…t-rules.github.io into secondary-requirement-texts

WilcoFiers marked this pull request as ready for review May 18, 2023 09:49

Fix failing test

6f1574a

tbostic32 reviewed May 18, 2023

View reviewed changes

Secondary reqs on ARIA rules

9d0892f

Jym77 approved these changes May 25, 2023

View reviewed changes

Jym77 mentioned this pull request May 25, 2023

Updating the Transcript Rules #2064

Open

Jym77 mentioned this pull request Jun 22, 2023

"Audio or video element avoids automatically playing audio" [80f0bf]: Add Accessibility Support note about autoplay not being respected #2076

Merged

7 tasks

kengdoj mentioned this pull request Jul 20, 2023

WCAG mapping for 'Link has non-empty accessible name' c487ae #1875

Closed

WilcoFiers added 3 commits July 26, 2023 15:47

Update all secondary requirements

db61a47

Typos

5c2a33c

Fix failing tests

ca20b61

WilcoFiers commented Jul 26, 2023

View reviewed changes

tbostic32 reviewed Jul 27, 2023

View reviewed changes

WilcoFiers requested review from Jym77 and tbostic32 July 27, 2023 12:56

Update _rules/link-non-empty-accessible-name-c487ae.md

ba3a875

Co-authored-by: Trevor R. Bostic <[email protected]>

WilcoFiers commented Jul 27, 2023

View reviewed changes

kengdoj reviewed Jul 27, 2023

View reviewed changes

maryjom reviewed Jul 27, 2023

View reviewed changes

Jym77 previously requested changes Aug 10, 2023

View reviewed changes

WilcoFiers added 2 commits August 10, 2023 13:57

Tweaked the language some more

49cc4f5

Update rule design info for secondary requirements

0102e0e

WilcoFiers requested a review from Jym77 August 10, 2023 12:15

Fix tests

6dd391a