Accessibility Conformance Testing Teleconference

Req WCAG scope discussion

https://github.com/w3c/wcag-act/issues/5

Wilco: comment came up, suggest not limiting to WCAG
... "Silver" coming up, and will likely be broader than WCAG alone
... would likely include aspects of ATAG and UAAG
... think need to support that
... put proposal in my comment in GitHub

[[To show that the ACT Framework is capable of targeting different accessibility requirements, the following accessibility requirements are used: WCAG 2.0, ATAG 2.0, ARIA Authoring Practices 1.0 and EPUB Accessibility 1.0.]]

MaryJo: can see the relationship to ARIA and ePub as semantic markup formats
... but not sure how easy it would be to do ATAG or other such specifications

Wilco: put ATAG and not UAAG
... lots of CMS tools are web-based
... think we could address some aspects

Romain: had same reaction as MaryJo
... if you are considering web-based authoring tools, then you are testing WCAG not ATAG
... what do we mean by "accessibility requirements are used"
... need to be explicit

Wilco: wasn't going to be that explicit
... but think sufficient if we can cover at least one rule

Shadi: think we need to separate document formats like ARIA and ePub from user accessibility requirements like WCAG, ATAG, and UAAG
... think we may be covering some ATAG and UAAG aspects
... maybe we can say "will address WCAG, which may address some aspects of ATAG and UAAG", and provide an example or two
... may address some mobile aspects of UAAG

Charu: agree with Shadi, should differentiate the different aspects
... document formats and accessibility requirements
... but also WCAG and others

Wilco: think EPUB Accessibility 1.0 goes beyond WCAG

MaryJo: ARIA Autoring Practices are not normative
... think may want to stick to the normative specs

Wilco: suggestion to follow ARIA Authoring Practices as they go beyond WCAG
... but agree would be good to stick with normative specs

Romain: ePub a11y follows WCAG to 90%
... goes beyond on only some few aspects

Wilco: but it is its own requirements doc

<rdeltour> http://www.idpf.org/epub/a11y/accessibility.html

Romain: yes but links back to WCAG

Shadi: can we describe the type of testing that we will cover rather than the guidelines?
... will it be content, browser chrome, OS mappings?

Wilco: like the approach but not sure
... broader than web content but not all aspects
... maybe content and ePub?

shadi: think ePub is type of content
... maybe can also spell out some use cases
... and what we are *not* focusing on

Charu: think ARIA aspects will likely become part of WCAG
... might help us say the type of content that we are targetting

Romain: elephant in the room when we talk about digital publishing is PDF
... and that may be the difficult part
... in response to Charu, trying to provide this back into WCAG

<maryjom> +1 to what Romain just said. Want to be specific enough in our scope to limit to web-based content.

Romain: IDPF and W3C working together
... creating a shared working group
... and also sent issues to WCAG WG

Charu: want to target normative work
... especially if it will be covered by WCAG

shadi: on PDF, will our *format* (Framework) not be applicable to PDF?

<Wilco> "To show that the ACT Framework is capable of targeting different accessibility requirements for web content and digital publications."

shadi: versus the rules that we will initially develop

Wilco: don't see why the format should not be applicable to PDF
... but the rules that we will create initially to complete the standard will be mostly HTML based

<rdeltour> suggest s/digital publications/web-based digital publications/

<maryjom> +1

+1 to romain

<Wilco> To show that the ACT Framework is capable of targeting different accessibility requirements for web content and web-based digital publications.

+1

<maryjom> +1

shadi: maybe put the use cases as an appendix to the requirements, and link to them from this section?

Wilco: like that idea

<Wilco> ACTION: Wilco to update scope description [recorded in http://www.w3.org/2016/11/23-wcag-act-minutes.html#action01]

<trackbot> Created ACTION-20 - Update scope description [on Wilco Fiers - due 2016-11-30].

Req "negative tests" discussion

Wilco: thread did not really come to a conclusion

Alistair: not wild about what we will not be doing
... more interested in what we will be doing
... including the reason for failing

<Wilco> The ACT Framework will focus on defining rules that enable clear reasons for non-compliance to be given to the user. Breaking accessibility requirements down into rules lets us get meaningful results from testing parts of an accessibility requirement, where it may not be possible or practical to have rules that cover the full accessibility requirement. e.g. “images must have an alternative text”, but not "the text alternative must be descriptive". Wher[CUT]

<Wilco> The ACT Framework will focus on defining rules that enable clear reasons for non-compliance to be given to the user e.g. “displayed content in a page flashes more than three times per second”. Where possible, ACT Rules should map to [WCAG 2.0 Failure Techniques](https://www.w3.org/TR/WCAG20-TECHS/failures.html).

Alistair: in your suggestion, you switch from what we will do to what we will not do
... we can have a different example than the flashing but think should keep the focus on what we do

Charu: think nicely clarifies what the rules will be testing for
... maps to sucess criteria and outlines the failure condition
... the second one (the initial proposal)

Katie: also agree with the second one

Wilco: better examples we can use than three-flashes?

Alistair: can send you a selection of examples

<Wilco> +1

<maryjom> +1 to "failure condition"

<cpandhi> +1

Shadi: like the term "failure condition" from Charu

Update management section https://w3c.github.io/wcag-act/act-framework.html#quality-updates

Shadi: should use it when we need to differentiate from "failure techniques"

+1 to "update management" (rather than "change management")

Romain: think sequence of major - minor version numbers may be backwards
... if you change the API or break existing behavior, that would be a major update
... concerned about "which could lead to a different result" in minor update

Wilco: was thinking what would impact users

<scribe> ...new user violations are major impact

Wilco: chaning major function would lead to remediation effort

Romain: better understand where you are coming from
... may be clearer if we phrase it in terms of violations
... maybe along the lines "documents will pass future versions when only the minor version is changed" or such

Alistair: we don't version the tests but the entire suite
... may be a nightmare to version the individual tests

Katie: agree

Romain: are you talking about the rules or the steps in the rules?

Alistair: good point but may be difficult to have individual tests with different states
... for example, if you correct a spelling mistake in a CSS selector, is this minor or major change?

Wilco: sounds major to me

Romain: if it produces new failures then it is major, correct

Alistair: you'll get a lot of major versions

Wilco: don't have a problem with that

Katie: example of dot-version update?

Wilco: anything that doesn't cause violations to go away
... change of values that does not cause new violations

Katie: violations is the only parameter?

Wilco: would typo in CSS selector make it to publishing?

Katie: possibly not
... but versioning should be suite not the individual tests

Charu: maybe would be better to describe the versioning in terms of impact rather than the change

+1 to charu

Wilco: agree

Alistair: probably want to claim conformance to entire test suite rather than individual tests
... do we actually need versioning for individual tests?

Next Meeting

<Wilco> https://www.w3.org/WAI/GL/task-forces/conformance-testing/track/actions/open

No meeting next week, 30 November

Next meeting 7 December 2016

Action Items

Charu: still working on my action, should be ready for the next call
... added IBM column in the test description#

Wilco: yes, saw that - thanks!

Romain: pending questions on my action