W3C

Accessibility Conformance Testing Teleconference

26 Jul 2018

Attendees

Present
MaryJo, Kasper, Shadi, Trevor, Charu, Moe, Kathy
Regrets

Chair
MaryJo
Scribe
Kasper

Contents


Issue 226: ACT security checks - https://github.com/w3c/wcag-act/issues/226

<maryjom> https://www.w3.org/TR/security-privacy-questionnaire/#questions

Mary Jo: This section is what we will focus on

<cpandhi> +1

Mary Jo: Do a +1 if none of the questions answer to "yes"

+1

<trevor> +1

Mary Jo: None of the questions marked as TODO should apply to the spec

<maryjom> +1

Mary Jo: We should be good with this one

RESOLUTION: ACT-TF has not identified any security concerns

Introductions

Kathy: Work at the US Access Board on Trusted Tester. Currently working on identifying new testing approach and tools.

[rest of the TF introduce themselves]

Issue 225: ACT i18n checks - https://github.com/w3c/wcag-act/issues/225

Mary Jo: Similar type of questions, this time for internationalisation

<MoeKraft> Did we post the GitHub issue in IRC?

<shadi> https://www.w3.org/International/techniques/developing-specs

<MoeKraft> https://github.com/w3c/wcag-act/issues/225

This one rather: https://github.com/w3c/wcag-act/issues/226

The agenda labels, or links, are slightly off

<maryjom> Yes, the links are backwards from the titles. Shadi will fix.

Moe: A few of us already replied to the GitHub issue, but I don't think any of the questions apply. Does Kathy have any advice for us?
... If we're using Bikeshed, would that format work?

Shadi: I don't believe we have any clear things we need to consider, maybe a note here and there. Mixing of languages shouldn't happen; the entire rule will probably be written in English.

Moe: We do state that the rule description should be written in plain language.

Shadi: Maybe the note we should add is that rules should be written in an accessible format.

Mary Jo: Anne mentioned something about referencing definitions. If we use terms like "character" or "string", we should probably provide the appropriate definition.

Shadi: Is there anywhere in the spec where we assume that the rule will be accessible and properly coded using whatever technology is used?

Mary Jo: Maybe add a comment to the issue to check if there's a need to add definitions.

Shadi: Could maybe be added directly under the section "rule structure" or "quality assurance".

Moe: Like having it in section 4 and maybe emphasise it in section 15.

Review /update exit criteria - https://www.w3.org/WAI/GL/task-forces/conformance-testing/wiki/Exit_Criteria_for_Rules_Format_Spec

Mary Jo: We need exit criteria so we can document what needs to be done for the spec to go to recommendation

Shadi: The W3C requirement is to demonstrate interoperability of the implementations of the spec.
... For each feature that is a MUST, we must have at least 2 independent implementations. We want rules that demonstrate the different variations of the features.

Mary Jo: It's not the raw number rules that matters, but the number of atomic rules, the number of composed rules, etc.

Shadi: The points listed are not mutually exclusive.
... A small number of wisely selected rules should be enough to demonstrate the different aspects of the spec.

Mary Jo: I would remove the "X of" on the non-bulleted items.

Kasper: It's difficult to find a set of rules that cover all permutations of features. Some test aspects are e.g. inherently manual; audio and visual aspects.

Shadi: I'm not sure how the benchmarking point is envisioned. Do we need it there?

Mary Jo: One of the potential concerns could be to make that there aren't any false positives.

Mary Jo: We're testing for the spec though, not the rules.

Shadi: We want to show that if you implement a rule using the spec, you end up with a valid rule.

Mary Jo: Our spec is a format, not a spec for the implementation. It's not WCAG techniques, which are very specific as they're testing requirements. This is higher level. Benchmarking would be part of validation of the rules themselves, but might not be required for the spec itself.

Shadi: Some measure of false positives/negatives might be needed.

Mary Jo: To me it's more about if we can make rules that make sense and use all the features of the spec. Can we make rules that are meaningful and understandable?

Shadi: At the very least we're unsure whether this is a MUST or a MAY requirement.
... There's also mention of benchmarking under the "Implementations of ACT Data Format" bullet.

Mary Jo: Do we need to go as far as having actual tools implement the rules?

Shadi: My feeling is that it probably will be. A certain number will need to be implemented. The fact that you have rules doesn't mean that they can be implemented in manual methodologies and automated tools.

Mary Jo: So an action for everybody to start thinking about is what the numbers should be.

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

Mary Jo: If you have any thoughts on what the numbers should or additional items to add or delete from the exit criteria, post it in that issue to help move the topic along.

Summary of Action Items

Summary of Resolutions

  1. ACT-TF has not identified any security concerns
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.152 (CVS log)
$Date: 2018/07/26 14:52:27 $