Suggested edit:

Each HTML video element meets the expectations defined by at least one of the following rules:

Rationale: "meets expectations" is vague - it could mean meeting only parts of the defined expectation.

"meets all expectations"

Going with "meets the expectations" as suggested. "All expectations from one rule" is a bit confusing IMO. I'm not using "as defined in", as I don't think it helps readability. This is an example, making this editorial. We can revisit it if we have to in CR.

"The distinction ... has to be made clear" - should that be a MUST requirement?

editorial

Misuse of "may" keyword. Here some suggestions:

• could be used to list accessibility requirements and standards that are thematically related (remove "may")
• could be used to list accessibility requirements and standards when they are thematically related (replace "may")
• MAY be used to list accessibility requirements and standards that are thematically related (move "may" to make it a requirement)

Going with option 2. Didn't pick the third one as the background section already has a "MAY" in it.

Replace "may" with "can" in the example.

Consider making "could be created" to "MAY be created" (ie. changing it to a requirement).

Didn't pick up this suggestion, as an external mapping is not part of the rules format. Therefore we can't make suggestions for it.

"These rules are to be kept small and atomic. Meaning that atomic rules test..." --> "These rules are to be kept small and atomic, meaning that atomic rules test..."

Missing a comma?
"how any one of these satisfying conditions, or some combination of them is used to determine a single outcome" --> "how any one of these satisfying conditions, or some combination of them, is used to determine a single outcome"

This is both a WCAG 2.0 and 2.1 requirement. How do we expect people to communicate this? And should we show this in the examples?

Should video be uppercase? Composite rule: Video elements have an audio...

Decided in the ACT TF meeting that this is not relevant for the examples.

This is both a WCAG 2.0 and 2.1 requirement. How do we expect people to communicate this? And should we show this in the examples?

I don't think rules should have to quote every single version that a requirement appears in or you'll wind up with a very long list. Maybe simply have the standard without the version and a link pointer would be best.

Why do we use "List" here? Other items could be lists as well, e.g. the accessibility requirements, but we don't add "List" to these sections.

Suggesting to make it a bit more specific: "This rule checks that each HTML document has a title"

I disagree. If the test subject is a single page, you wouldn't talk about "each HTML document". Similarly, we don't say "Each img element in each HTML document". You'd use that language if you're talking about a set of web pages. So for example: "The rule checks that the title of an HTML page is unique within a set of web pages".

"meet the expectations" --> "meet all expectations"

"determine a single passed or failed [=outcome=] for a [=test subject=]" implies that composite rules will always apply to e.g. a whole page at a time, without possibility to pinpoint which element passed/failed.

Correct. We've defined outcome in relationship to test subject, not to test targets.

It's nice that we list the SC here. Can we do that consistently in other examples too, where relevant?

Shouldn't it be about the outcomes of the input rules here (passed/failied/inapplicable), rather than about meeting the expectations? This could open up for (potentially) picking and choosing between different expectations in the same input rule...

As above.

I still say that it has to meet all expectations of at least one input rule. It can't meet half an input rule and still pass.

Editorial: "These rules are to be kept small and atomic. This means that atomic rules..."

Editorial:
"if landmarks used to satsify [WCAG 2.1, success criterion 2.4.1 bypass blocks]"
-->
"if landmarks are used to satisfy [WCAG 2.1, success criterion 2.4.1 Bypass Blocks]"

Instead of "description", shouldn't it be the "descriptive title" that should be included here? (see ACT Rule Structure)

Editorial: This sentence doesn't work without the parenthesis, suggesting it maybe shouldn't be there.

I suggest that definitions are only have to be put into the glossary if it's not possible to define it unambiguously in the applicability or expectation itself (which should be the goal).

This note should be in the Glossary instead according to latest edits.

Not if we allow inline definitions like you suggested before. That's a good addition.

Editorials needed for "it MUST be the union of all the applicability in the [input rules]". Maybe add "sections" to "applicability"

Disagree. We're not merging the sections, we're creating a new section that describes what the union.

I think the issue is with the "the" in the sentence. How about "all applicability definitions" instead of "sections"? Later on (in the note) you simply use "applicability" - maybe this could work too. In any case, the grammar of this sentence does seem wrong to me too.

element --> test target?

I still say that it has to meet all expectations of at least one input rule. It can't meet half an input rule and still pass.

Should it say here that the test targets are the things that are applicable to the rule?
I know that it becomes a bit circular when following the link from the Applicability, but out of context, the definition seems very thin.

I think this is a good idea. Maybe simply:

A distinct part of the [=test subject=], as defined by Applicability.

(minor/editorial) I suggest changing "meets the expectations" to "meets all expectations", to emphasize the meaning and for better readability ("the" implies a definite set, which makes me pause to think which set you actually mean. On the other hand, "all" implies the entire set and does not require further processing cylces in my view).

Following the ACT TF discussion on 31 January 2019, I suggest we also change "Each HTML 'video' element" to "All HTML 'video' elements", to better emphasize the scope.

(medium) In the first list item below, add "identifier" to "name, title, or summary"

(medium) Change "link" to "a link or reference" (eg. if the document is not publicly available or directly linkable for any other reason)

(important) I think this paragraph needs to be rewritten, to better explain the different types of definition forms for expectations. It seems that we have two types:

1. individual test targets - the expectation applies to individual test targets, like "every test target has an accessible name"
2. sets of test targets - the expectation applies to a set of test targets, like "85% of all test targets have an accessible name"

I think in these cases, also the applicability definitions need to be formulated accordingly. For the first type of expectation, the applicability is "every X" (eg. every element), while for the the section the applicability is "all X) (eg. all elements). I think it would be illogical to mix these types of forms, for example to say "every element ... 85% of all elements have an accessible name".

See more below on definition for "meets all expectations".

... building on what Shadi said, I think that the "85%..." type of expectation rules out saying anything about whether a particular test target meets the expectation. These types of rules can only say something about the set they apply to.

(Even though an implementation could choose to report which elements count toward/from meeting the expectation. And it would probably be nice to report some calculations too, e.g. how many % had an accessible name, and how far is it from the 85% threshold).

I also don't really see why it's not always "meet all expectations". I agree that it's not always "all test targets", like in the 85% case, but I cannot imagine an example where we would allow for only meeting e.g. 2 out of 3 expectations in a rule. If the expectation is "85%...", this is still an expectation that needs to be met.

Following the ACT TF discussion on 31 January 2019, I suggest we change this paragraph as follows:

Expectation can be statements in the form of "Each test target has ..."; for example, "Each test target has an accessible name". For such expectations, all test targets need to [=meet expectations|meet the expectation=] for the rule to pass. Expectations can also be statements in the form of "The set of test targets has ..."; for example, "85% of all test targets have an accessible name". For such expectations, the entire set of test targets needs to [=meet expectations|meet the expectation=] for the rule to pass.

How do we know if this video is in the 80% or 20%?

Agree. In my view this example does not make sense. We are trying to match an individual test target on an expectation about an entire set of test targets (see suggestions for expectations suggestion above).

Following the ACT TF discussion on 31 January 2019, I suggest we change this example to:

A set of 3 HTML 'video' elements of which 2 do not have captions does not meet the following expectation:

Shouldn't we use the "meets all expectations" definition here?

I'm wondering why we are distinguishing "meets" and "is true".

Editorial: Suggest added sentence read as follows...
For example, there are multiple methods to give an accessible name to an HTML 'img' element.

I'm not sure I understand the reason for changing "outcome" to "findings". The "outcome" is the finding of an ACT rule, whether it be atomic or composite. I don't think we need two different terms for that.

See issue #327 on removing "failure", and simply say "condition" instead.

Editorial: Remove "in order"

Where should accessibility issues in test cases be documented to meet this "warned in advance" requirement? In the test case itself, in the rule description? Is that flexible?

Also, there is the use of normative language - "MUST" and this is a note, right? Is this requirement in the ACT Rules Format somewhere?

To your latter comment @maryjom, AFAIK this is not a note but a paragraph in a normative section of the document. It actually sets two normative requirements (accessible content and advance warning).

Maybe remove "satisfying" from here (just "conditions", as suggested in issue #327)?

Following the ACT TF discussion on 31 January 2019, Please change "Each 'video' or 'audio' element ... as well as each 'object' element" to "All 'video' and 'audio' elements ... as well as all 'object' elements"