IRC log of wcag-act on 2017-07-24

Timestamps are in UTC.

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