alistair: We need to have a way to express pointers that can handle the shadow DOM
wilco: I thinks that's outside of the scope
of our spec
... This should be discussed when there's an update to EARL.
Shadi: There's a type for the assertion, would it help to add the type of pointer it is.
Alistair: We have our own set of pointers but it could be broken over several depths of shadow DOM.
<MoeKraft> Happy New Year!
<wilco> https://github.com/w3c/wcag-act/blob/master/earl-act.json
Wilco: This example has a default type of pointer, but you can override it.
Shadi: I need to look over this when we come to the output format.
alistair: Is there someplace that when
defining iFrames and multiple depths of iFrame and the same for shadow
DOM is expressed?
... Xpath and CSS selectors don't have a way to point to things in the
shadow DOM. W3C needs to have either a new series of selectors or allow
selectors to point to elements in shadow DOM.
Shadi: We should probably bring this up with the CSS working group to get it solved here.
Alistair: We need a way to have a pointer type, and leave it in the pseudo level. I can send an email for a proposed change.
Shadi: Go ahead and merge in this change and I'll take another pass before we publish, and check with EARL.
<Kasper> +1
<shadi> +1
<cpandhi> +1
+1
Group decided to merge in.
<wilco> clear queue
<wilco> https://github.com/w3c/wcag-act/pull/155/files?diff=split
Wilco: I updated the test procedure to use applicability & expectations.
Charu: I updated a rule using this and it was pretty straightforward.
Moe: Small grammatical change - I'll add a
comment on this pull request.
... Is the expectation the result of the test or the statement about the
test target?
Wilco: It is about the target.
Charu: I thought it was more about the result.
Wilco: The test target is the image.
Charu: The expectation is that the image should have a description. Is that the result - "pass"?
Wilco: Yes, if the expectation is true, then the result is "pass".
Moe: I was leaning toward expected result of the test. If the expected result is passed, the test passed.
Alistair: I presume each expectation must be
discreet, no crossover between statements.
... Each statement should be testable of its own right.
... I think the word 'discrete' should be in there
... The nice thing about expectations is you can put them in a VPAT.
They are your statements of conformance.
Wilco: That's also what I like about this
approach.
... Anything we can do to make this clearer for you, Moe?
Alistair: I would have another paragraph that adds in 'discrete' in the description.
<wilco> https://github.com/w3c/wcag-act/pull/155/files?diff=split#diff-9ac0a6633720a5535b0a53cba04ababeR166
Moe: In the example, does this mean #1 and #2 have to pass for the rule to pass?
Wilco: Yes.
Alistair: These should include statements about conformance.
Charu: I agree.
Wilco: I'll update the pull request and we'll have it on a survey for next week.
<wilco> For example, a rule that would partially test WCAG 2.0 Success Criterion 1.4.3 (minimum contrast) could state that it only applies to HTML text content stylable with CSS and does not support images of text.
Wilco: I like this suggested addition.
... Hearing no comments, I'll update the spec with this content.
<Kasper> https://github.com/w3c/wcag-act/issues/109#issuecomment-356633131
Kasper: I have proposed replacing the Test
Subject Types with Aspects Under Test.
... Rules may be on HTTP, the DOM, or on anything containing text.
Wilco: You got rid of the list, and do we
need a list?
... If we have a list, there will at least be some things that people do
consistently.
Alistair: I think you were thinking of
auto-refresh when talking about HTTP, but I think that would be two
tests.
... I think for each test we have a specific thing we are testing.
Kasper: We have a rule where we compare the lang attribute set in HTTP and the lang attribute in the DOM tree. So there can be a need for combinations.
Wilco: I agree that in most cases, you have a single type but some cases you do need to compare things.
Alistair: So you're saying you can define one or more test targets. The test has to be discretely defined.
Kasper: Test subjects will still be discretely defined, but multiple aspects of that test subject you want to test in a rule.
Alistair: We need to define the test aspect,
and we have a list of potential target types. You define the test aspect
discretely.
... So we should really probably keep the list.
Wilco: When I was thinking about breaking
down the test aspects, some tests require sight or hearing to do them.
Should we define this as part of the test?
... This is a requirement for the test subject, and this is a
requirement for the tester that you can do x, y, z.
... Is that a useful addition to this?
... There are things you need to be able to do from the test
environment.
Alistair: Should this be covered under assumptions?
Wilco: Assumptions are about the subject, not the environment.
Kasper: In the aspects you could define the
environment constraints. The aspect of the test is HTTP messages,
there's multiple ways to get those.
... Unless you're in an environment where you can't get an HTTP message
there isn't an issue.
... I will update and put into a pull request, and give a list of
examples.
Wilco: Vision and hearing might be important aspects to add.
Kasper: I will also add that aspects are
discretely defined.
... I can get the update done before the Monday planning meeting so we
can put it on the survey for next week's meeting.