13:55:50 <RRSAgent> RRSAgent has joined #wcag-act
13:55:50 <RRSAgent> logging to http://www.w3.org/2017/07/24-wcag-act-irc
13:55:52 <trackbot> RRSAgent, make logs public
13:55:52 <Zakim> Zakim has joined #wcag-act
13:55:54 <trackbot> Zakim, this will be
13:55:54 <Zakim> I don't understand 'this will be', trackbot
13:55:55 <trackbot> Meeting: Accessibility Conformance Testing Teleconference
13:55:55 <trackbot> Date: 24 July 2017
13:56:31 <Wilco> agenda?
13:56:41 <Wilco> agenda+ Accessibility Support
13:56:49 <Wilco> agenda+ Rules Format pull request: Expand accessibility requirements section https://github.com/w3c/wcag-act/pull/96
13:57:05 <Wilco> agenda+ Rules Format pull request: Merge change log with version history https://github.com/w3c/wcag-act/pull/94
13:57:15 <Wilco> agenda+ Use of the term "Test case" in the spec
13:57:24 <Wilco> agenda+ What rules to use as examples
13:57:33 <Wilco> agenda+ Book and register for TPAC: Thurs-Fri is the ACT meeting
13:57:40 <Wilco> agenda+ Next meeting is on July 31
13:58:56 <Wilco> zakim, take up item 1
13:58:56 <Zakim> agendum 1. "Accessibility Support" taken up [from Wilco]
13:59:38 <rdeltour> rdeltour has joined #wcag-act
14:01:56 <agarrison> agarrison has joined #wcag-act
14:03:13 <rdeltour> scribe: Romain
14:03:17 <maryjom> maryjom has joined #wcag-act
14:03:17 <rdeltour> scribenick: rdeltour
14:03:21 <Wilco> present+
14:03:24 <rdeltour> present+
14:03:28 <maryjom> present+
14:03:36 <rdeltour> agenda?
14:04:44 <rdeltour> zakim, take up next
14:04:44 <Zakim> agendum 2. "Rules Format pull request: Expand accessibility requirements section https://github.com/w3c/wcag-act/pull/96" taken up [from Wilco]
14:05:09 <rdeltour> zakim, take up item 1
14:05:09 <Zakim> agendum 1. "Accessibility Support" taken up [from Wilco]
14:05:21 <Wilco> https://www.w3.org/TR/act-rules-format/#structure-acc-supp
14:05:55 <rdeltour> wilco: my idea is to ahve some sort of way to deal with a11y support in rules
14:06:05 <rdeltour> s/ahve/have.
14:06:26 <rdeltour> wilco: currently some orgs don't deal with a11y support at all, which is a downside
14:06:42 <rdeltour> ... we shouldn't miss the opportunity to miss that here
14:06:53 <MoeKraft> MoeKraft has joined #wcag-act
14:07:04 <rdeltour> ... some comments was received on the prose, it's time to open that discussion again
14:07:46 <rdeltour> ... my question for the group is: do we want to take this back and use it to push a11y support?
14:08:25 <rdeltour> maryjom: it's a touchy subject
14:08:26 <rdeltour> ...
14:08:59 <rdeltour> ... you can't test with every screen readers, etc. how do you know you have full a11y support?
14:09:10 <rdeltour> wilco: you can't. I don't know what full a11y support even means
14:09:30 <rdeltour> ... for whatever you're testing, you set a baseline of what you want to support
14:09:54 <rdeltour> ... say, for a website, you say you want to support the latest version of VO, NVDA, JAWS
14:10:05 <agarrison> Q+
14:10:12 <rdeltour> ... by setting a support level, you can decide what rule you want to use
14:11:14 <rdeltour> maryjom: if you come up accross issues, you don't know if it's a bug in your code, in AT. It takes time to figure this out
14:11:34 <rdeltour> wilco: it does put the burden on the developer
14:11:58 <rdeltour> ... you indicate that you support an AT and you may have to work around bugs in AT in your code
14:12:50 <rdeltour> maryjom: it's hard to maintain, e.g. to follow screen reader changes. it's not always easy in practice
14:13:07 <Wilco> ack ag
14:13:08 <rdeltour> wilco: right. it seems to me nobody has a handle on a11y support at this point
14:13:43 <rdeltour> agarrison: my commnent is that it's a very simplistic thing that replicates what you right for the test anyway
14:14:16 <rdeltour> ... on example 1, that's the selector you have in the test anyway. why replicate it in the a11y support section?
14:14:36 <rdeltour> ... same for example 2, it's redundant with the test
14:14:56 <rdeltour> ... a second comment: I don't think we should look at a11y support within our tests
14:15:00 <MoeKraft> https://w3c.github.io/wcag-act/act-rules-format.html#structure-acc-supp
14:15:11 <rdeltour> ... this is something you're interested in when selecting the technique
14:15:22 <rdeltour> ... then you use the tests to validate the technique
14:15:38 <rdeltour> ... the a11y support decision is all made in a higher level, in the technique selection
14:15:47 <rdeltour> ... keeping the technique up to date is another discussion
14:16:13 <rdeltour> ... I don't see how a11y support is important at the test level
14:16:35 <rdeltour> wilco: I'm confused about what you mean by "at the technique level"
14:17:27 <rdeltour> agarrison: [further describes with a detailed table example]
14:18:01 <rdeltour> wilco: for tables, would you add 1 rule that addresses scope, 1 rule to address headers, 1 rule that address scope and headers?
14:18:32 <rdeltour> agarrison: it's their choice wheather to use headers and IDs or scopes, it's the dev's choice how to build their stuff
14:18:57 <rdeltour> ... we don't care about their choices, we build the rules to test them all
14:19:27 <rdeltour> wilco: say for our organisation, we use headers and IDs, not scopes
14:19:42 <rdeltour> ... a developer comes along and is only using scope, the rule would fail?
14:20:18 <rdeltour> agarrison: what you do is provide a set of best practices, and then select some tests to support these best practices
14:20:52 <rdeltour> ... it's how it's done in all the organisations I've worked in
14:21:11 <rdeltour> wilco: then you need rules for these best practices
14:21:45 <rdeltour> agarrison: if you tell people you're only using headers and IDs, you write a test only for header and IDs
14:22:27 <MoeKraft> https://www.w3.org/TR/WCAG20/#accessibility-supporteddef
14:22:35 <rdeltour> wilco: the problem is that there are things in Techniques which are not a11y supported
14:23:49 <rdeltour> agarrison: [rephrases the comments]
14:24:03 <rdeltour> wilco: so you're delegating that to people who write the techniques?
14:24:10 <rdeltour> agarrison: or the people who select the techniques
14:26:10 <MoeKraft> q+
14:26:39 <Wilco> ack moe
14:26:52 <rdeltour> rdeltour: I think I understand Alistair's point, but IMO the a11y support info is useful to select the test of filter the steps in the test?
14:27:17 <rdeltour> moekraft: the rules themselves should be testing techniques that are a11y supported
14:27:44 <rdeltour> ... if you're using a technique, it's a11y supported
14:28:35 <rdeltour> ... the techniques themselves are supporting some AT
14:28:50 <rdeltour> ... there would be a level of redundancy if we add a11y support to the tests
14:29:18 <rdeltour> ... I think we need to call it out, but maybe not included it in every rule
14:30:14 <rdeltour> ... if someone relies on a11y support in test, it may not be implemented properly
14:31:04 <Wilco> Only accessibility-supported ways of using technologies are relied upon to satisfy the success criteria. Any information or functionality that is provided in a way that is not accessibility supported is also available in a way that is accessibility supported. (See Understanding accessibility support.)
14:31:11 <rdeltour> ... a screen reader can have the ability to override bad code
14:31:53 <agarrison> q+
14:32:47 <rdeltour> wilco: my understanding of the text abovie: you're only allowed to say you pass SC if the way you've done it works for AT
14:34:29 <rdeltour> wilco: I think we should provide information within the rule that allows people using the rule to figure out whether using the rule [???]
14:34:56 <rdeltour> ... the way I would write my table rule w/b: you write several steps
14:35:16 <rdeltour> ... 1. one uses scopes, 2. uses haeders+IDs
14:35:46 <rdeltour> ... some mechanism allows users to say "we have this context, so we can turn off step 1, or 2, or we need both"
14:36:05 <rdeltour> ... what is a11y supported depends on what your baseline is
14:36:38 <rdeltour> ... your baseline is different whether you're targetting macOS users only, or also mobile users with Android
14:36:39 <Wilco> ack a
14:37:10 <rdeltour> agarrison: you would only need to include a support baseline thing in tests if the people writing the test wouldn't have already selected a technique already
14:37:37 <rdeltour> ... a user wrote a site without selecting the technique, then run the test, then the test can inform on the a11y support
14:37:54 <rdeltour> ... anyone else would be using best practices to follow for the target baseline
14:38:11 <rdeltour> ... who would write an entire product without selecting best practices first?
14:38:36 <rdeltour> wilco: I'm trying to make the rules work in any situation
14:38:57 <rdeltour> agarrison: they can select the technique they want
14:39:12 <rdeltour> ... I don't see us saying "you selected a technique we don't support"
14:39:25 <rdeltour> ... I don't see why this is so important at the test level
14:39:44 <rdeltour> wilco: we want to be able to reuse the use accross different organizations and people
14:39:55 <rdeltour> ... let's take our table rule again
14:40:09 <rdeltour> ... if we (ACT TF) publish a rule on tables
14:40:19 <rdeltour> ... if an organization has to support Android an Talkback
14:40:36 <rdeltour> ... they have to tests other things than an organization that just supports Windows and macOS
14:41:09 <rdeltour> ... our options are: either we write multiple tests for these differenet organisation, or write 1 test that can be configured to fit the needs of these orgnanizations
14:41:12 <MoeKraft> q+
14:41:29 <rdeltour> agarrison: I think we should be going for the most atomic tests
14:41:59 <rdeltour> moekraft: you may have something that VO doesn't support today but something that is a11y supported
14:42:17 <rdeltour> ... we need something to select the appropriate rule for a situation
14:42:25 <Wilco> ack moe
14:42:56 <rdeltour> ... I see where you're coming from wilco, but sometimes it can be a11y supported and not on a particular AT
14:43:20 <rdeltour> ... we need to ensure that the techniques that we test for themselves are a11y supported
14:43:36 <rdeltour> ... and I do agree with Allistar that we should aim for smaller tests
14:43:51 <rdeltour> s/Allisar/Allistair/
14:44:41 <rdeltour> wilco: what is the alternative to putting this complexity to the rules?
14:45:08 <rdeltour> ... Allistair you're talking about keeping the rules small. for the table example, you'd write several rules?
14:45:35 <rdeltour> agarrison: it's not me, but every recommendation on writing tests recommends being atomic
14:45:52 <rdeltour> ... then you use a selector to select whether it's applicable or not
14:46:41 <rdeltour> wilco: no disagreement from me! but what would you do for the table example?
14:47:13 <rdeltour> agarrison: in our organisation, we have different tests
14:47:21 <rdeltour> wilco: so you need to aggregate them?
14:47:40 <rdeltour> agarrison: not when running them, but you could aggregate the results in a higher level
14:48:06 <rdeltour> ... you don't do the aggregation at the unit-test level, but for the whole test runner
14:48:29 <rdeltour> ... our tests should be just finding fail/pass, not an aggregator result for best practices
14:49:06 <rdeltour> wilco: in a lot of rules you can use one of any number of techniques to pass.
14:50:24 <rdeltour> agarrison: so if a rule fails, it doesn't necessarily means that a SC fails, since another rule can pass?
14:50:42 <rdeltour> agarrison: what you want for test is to produce a result, and can be reused
14:51:05 <rdeltour> ... I'm a bit reticent about writing super-tests that run smaller tests, it's more a platform kind of thing
14:51:53 <rdeltour> moekraft: we do have a separate mobile ruleset, which is a subset of our web ruleset
14:52:14 <rdeltour> ... some rules make sense on our platforms and not others
14:52:41 <rdeltour> ... if you have smaller rules, if one pass and the other fails, how do you come up with a summary of whether the SC passes?
14:53:03 <rdeltour> wilco: the idea is that if all of them fail, the SC fails, and if any of them pass, the SC passes
14:53:31 <rdeltour> ... should we introduce the concept of a group?
14:53:44 <rdeltour> ... if a rule belongs to a group you need only one of them to pass
14:54:59 <rdeltour> agarrison: if you only look at the failing tests, it doesn't matter whether you implement things in one way or another
14:56:06 <rdeltour> ... ... in LevelAccess (SSB), we test for all sort of things and just flag the things that fail
14:56:23 <rdeltour> wilco: and if you have a group, you have a way to say that one of them passed so it's OK?
14:56:46 <rdeltour> agarrison: one issue with WCAG is that it's difficult to say that something passed, but you can say when it fails
14:57:20 <rdeltour> wilco: we're making progress. I'll take on myself to write a proposal with the idea of groups
14:57:38 <rdeltour> agenda?
14:58:15 <rdeltour> moekraft: I was thinking labelling can be another example to look at
14:58:34 <Wilco> https://wilcofiers.github.io/act-rules/
14:59:41 <rdeltour> wilco: I've been working on the rules to publish along our next draft [links not working currently]
14:59:46 <rdeltour> wilco: thanks everyone, let's talk next week!
15:00:40 <rdeltour> trackbot, end meeting
15:00:40 <trackbot> Zakim, list attendees
15:00:40 <Zakim> As of this point the attendees have been Wilco, rdeltour, maryjom
15:00:48 <trackbot> RRSAgent, please draft minutes
15:00:48 <RRSAgent> I have made the request to generate http://www.w3.org/2017/07/24-wcag-act-minutes.html trackbot
15:00:49 <trackbot> RRSAgent, bye
15:00:49 <RRSAgent> I see no action items