W3C

Accessibility Conformance Testing Teleconference

29 Nov 2018

Attendees

Present
MaryJo, Alistair, Shadi, Kasper, Trevor, Wilco, Kathy, SteinErik
Regrets

Chair
Mary_Jo_Mueller
Scribe
kasper

Contents


Pull request 304 - Remove formal syntax

<maryjom> https://github.com/w3c/wcag-act/pull/304

<shadi> https://github.com/w3c/wcag-act/pull/304/files

trevor: What's the reasoning behind this?

maryjom: Not quite sure. Anybody remember?

wilco: It didn't seem like it was gonna get a lot of use. Wanted to keep the spec small.

<shadi> +1

maryjom: Everybody okay with that?

Pull request 305 (related to Issue 293 we discussed last week)

<maryjom> https://github.com/w3c/wcag-act/issues/293

<maryjom> https://github.com/w3c/wcag-act/pull/305

<shadi> https://github.com/w3c/wcag-act/pull/305/files

*group discussing how the suggested changes came about*

shadi: Let's take this step by step. Accessibility support?

maryjom: Wilco, did you have a problem with the change from SHOULD to MUST in accessibility support?

wilco: No.

alistair: What happens if people don't understand the section on accessibility support?

*group discussing implications of changing some SHOULDs to MUSTs*

shadi: Are there any objections to this?

alistair: It's difficult to object as most people will likely just write that there are no known issues.

Skotkjerra: If authors miss an issue, we can still collect issues by having people submit reports.

maryjom: Should we take this to a vote?

wilco: On accessibility support?

<Wilco> 0

maryjom: Do people agree or disagree on changing accessibility support to a MUST? Can I see some +1s?

<shadi> +1

<trevor> +1

<Skotkjerra> +1

maryjom: We'll leave it as a MUST.

shadi: To be clear, all these pull requests will still go to a CFC.

maryjom: Next is the section on the issues list, this has been changed to a MUST.

wilco: I do have a problem with that one. This used to be a MAY. This requires that rule authors have a process in place for tracking issues, which may not be the case.
... I'd rather keep this as a MAY.

Skotkjerra: Shadi, was is originally you who suggested this?

shadi: I don't recall. I think it was originally optional.

Skotkjerra: I think this was changed back and forth a few times in the pull request.

alistair: I would raise the MAY being inconsistent. It should be SHOULD, shouldn't it?

maryjom: I tend to agree. It's good to document the issues if you know about.

alistair: I'm just saying that the word MAY should be a SHOULD for consistency.

*group discussing the differences between MAY and SHOULD*

<Wilco> +1

<Skotkjerra> +1

maryjom: If we change this back to MAY, shouldn't we also add "optional" to the title?

<trevor> +1

<shadi> +1

<maryjom> +1

<kathyeng> +1

shadi: The last sentence will also need to be removed.

maryjom: Next is acknowledgements. Any comments on those changes?

<shadi> +1

maryjom: Hearing none, moving on to background.

<shadi> +1

maryjom: Any comments?
... Hearing none, moving on to next agenda item.

Pull request 308: Acknowledgement Section

<maryjom> https://github.com/w3c/wcag-act/pull/308

maryjom: Are there any people missing from the section?

shadi: Let me know if the names are correct.

Skotkjerra: Anne mentioned that she wanted her name changed.

wilco: Shadi, is there a reason that organizations aren't mentioned?

<Wilco> +1

<Skotkjerra> +1

<maryjom> +1

<trevor> +1

<kathyeng> +1

<shadi> +1

<Skotkjerra> with addition of Nørregaard to Anne Thymes name

Changing the requirements document (not just failure cases)

<Wilco> https://w3c.github.io/wcag-act/act-fr-reqs.html

maryjom: We've been talking about being able to use rules for things like best practices and testing for passes, not just failures.
... In the requirements document, we however state that we're only covering failure cases.
... Wilco, you've opposed changing the scope of the spec as it goes beyond the requirements document?

wilco: That's one of the reasons. I'm concerned we're trying to do this as a last minute. I don't know how such a change would impact the work we've done so far. Not that it can't be done, but it wasn't defined as part of our scope.

alistair: Just for clarity, are we trying to put in test saying if people have passed?

wilco: Rules are tests for failures. Failing a rule means failing the corresponding accessibility requirement. Was is being asked is allowing failures not to be failures of the requirement.

Skotkjerra: What we've proposed is a way of being able to describe the actual relationship between a rule and a requirement.
... If we want to start the discussion on changing the requirements, there are other things we need to change as well.

alistair: Isn't it true to say that we'll be judged against the requirements document?

Skotkjerra: As far as I know they're not approved by the AGWG. I couldn't find any correspondence to the contrary.

shadi: Judged or approved is a bit hard. It is common that requirements change if we can justify it.
... *describing the issue at hand*

Skotkjerra: Can we currently list failure techniques as accessibility requirements?

wilco: There's nothing preventing you from doing that.
... There are no restrictions on what can be listed.

alistair: We've been used to writing tests in the negative style. We haven't had the possibility of saying that something passed.

Skotkjerra: The RGAA has positive statements as testing requirements.
... We can't currently write rules for these as they expect to return passes, not failures.

alistair: So your test would be that you weren't able to find a failure.

wilco: For example, RGAA has a requirement that HTML pages have valid HTML. That's not required by WCAG. A rule that test for that wouldn't be a WCAG rule.

Skotkjerra: We're not discriminating between requirements.

alistair: There must be cases like this in WCAG as well.

Skotkjerra: That's what we've been discussing. It's hard to find these really good examples. Should we not allow them or should we allow them?
... We ask that we have a way of describing these relationships.

alistair: It does bring about a bit of a change to the model. We've assumed that if you fail something, you fail.

shadi: Assuming that we stay in WCAG, we have success criteria and we have techniques.
... Some advisory techniques may exceed requirements and some techniques have very different relationships to requirements.

*group discussing best practices versus accessibility requirements*

Skotkjerra: This is all about supporting all the different kinds of accessibility requirements out there.

shadi: So you're satisfied with the current draft?

Skotkjerra: No, we'd like to see further changes.

<shadi> https://www.w3.org/WAI/GL/task-forces/conformance-testing/wiki/Rules_Mapping_Issue

alistair: What about putting all of this in an email with examples and sending it around?

shadi: Let's continue trying to lay out the different examples and options and see where we can get to.

Skotkjerra: Wilco, is there any other option you would like to take a look at other than going back to the previous draft?

wilco: We need a vote if we want to look at writing positive rules.

Summary of Action Items

Summary of Resolutions

[End of minutes]

Minutes manually created (not a transcript), formatted by David Booth's scribe.perl version 1.154 (CVS log)
$Date: 2018/11/29 15:48:54 $