IRC log of ag on 2017-09-12

Timestamps are in UTC.

14:31:46 [RRSAgent]
RRSAgent has joined #ag
14:31:46 [RRSAgent]
logging to
14:31:48 [trackbot]
RRSAgent, make logs public
14:31:48 [Zakim]
Zakim has joined #ag
14:31:50 [trackbot]
Meeting: Accessibility Guidelines Working Group Teleconference
14:31:50 [trackbot]
Date: 12 September 2017
14:32:00 [Joshue108]
zakim, agenda?
14:32:00 [Zakim]
I see nothing on the agenda
14:32:09 [Joshue108]
zakim, clear agenda
14:32:09 [Zakim]
agenda cleared
14:32:21 [Joshue108]
agenda+ 1) New SCs - To Merge or not to merge? Survey
14:32:31 [Joshue108]
agenda+ 2) Implementation testing process - (
14:32:43 [Joshue108]
agenda+ 3) Responding to comments: Sharing the workload (Github comments and responses).
14:32:54 [Joshue108]
Chair: Joshue108
14:42:12 [AWK]
AWK has joined #ag
14:42:20 [AWK]
14:49:50 [AWK]
zakim, who is on the phone?
14:49:50 [Zakim]
Present: (no one)
14:49:52 [AWK]
14:50:07 [AWK]
rrsagent, draft minutes
14:50:07 [RRSAgent]
I have made the request to generate AWK
14:50:24 [AWK]
rrsagent, set logs public
14:53:25 [allanj]
allanj has joined #ag
14:53:47 [KimD]
KimD has joined #ag
14:53:54 [KimD]
Present+ KimD
14:55:10 [AWK]
regrets+ Bruce_Bailey, Jake_Abma, Jan_McSorley, Brooks_Newton, Chris_Loiselle, James_Nurthen, EA_Draffan, Detlev_Fischer
14:57:59 [Mike_Pluke]
Mike_Pluke has joined #ag
14:58:08 [Roy]
Roy has joined #ag
14:58:41 [Joshue108]
present+ Joshue108
14:58:51 [Joshue108]
zakim, agenda?
14:58:51 [Zakim]
I see 3 items remaining on the agenda:
14:58:52 [Zakim]
1. 1) New SCs - To Merge or not to merge? Survey [from Joshue108]
14:58:52 [Zakim]
2. 2) Implementation testing process - ( [from Joshue108]
14:58:52 [Zakim]
3. 3) Responding to comments: Sharing the workload (Github comments and responses). [from Joshue108]
14:59:08 [shadi]
14:59:22 [Roy]
present+ Roy
14:59:24 [chriscm]
chriscm has joined #ag
15:00:02 [MelanieP]
MelanieP has joined #ag
15:00:13 [Brooks_Newton]
Brooks_Newton has joined #ag
15:00:33 [AWK]
regrets- Brooks_Newton
15:00:41 [jasonjgw]
jasonjgw has joined #ag
15:00:52 [jasonjgw]
15:01:08 [MichaelC]
15:01:13 [Mike_Pluke]
present+ Mike_Pluke
15:01:14 [Brooks_Newton]
present+ Brooks
15:01:27 [Greg]
Greg has joined #ag
15:01:29 [Joshue108]
present+ Joshue108
15:01:51 [chriscm]
Can I get a link to the WebEx??? I don't see it in the RC header and I don't see it on the email...
15:02:22 [Makoto]
Makoto has joined #ag
15:02:24 [JF]
JF has joined #AG
15:02:33 [chriscm]
Beautiful!!! Bookmarking this, thanks Josh!
15:02:35 [JF]
present+ JF
15:02:46 [Makoto]
present+ Makoto
15:03:41 [david-macdonald]
david-macdonald has joined #ag
15:04:00 [Greg]
present+ Greg_Lowney
15:04:04 [Kathy]
Kathy has joined #ag
15:04:21 [Kathy]
present+ Kathy
15:04:39 [david]
david has joined #ag
15:04:50 [Ryladog]
Ryladog has joined #ag
15:05:07 [JF]
15:05:09 [Ryladog]
Present+ Katie_Haritos-Shea
15:05:09 [david]
Present+ david-macdonald
15:05:29 [david]
15:05:44 [Joshue108]
Scribenick: DavidMacD
15:06:16 [david]
zakim: take uo item 1
15:06:17 [Joshue108]
zakim, next iteam
15:06:17 [Zakim]
I don't understand 'next iteam', Joshue108
15:06:20 [Joshue108]
zakim, next item
15:06:20 [Zakim]
agendum 1. "1) New SCs - To Merge or not to merge? Survey" taken up [from Joshue108]
15:06:42 [laura]
laura has joined #ag
15:06:46 [MelanieP]
present+ Melanie_Philipp
15:07:00 [lisa]
15:07:02 [Joshue108]
15:07:03 [david]
Josh: interesting things on the agenda one of them is the candidate wcag 2.1 success criterion
15:07:43 [Rachael]
Rachael has joined #ag
15:07:51 [Joshue108]
15:07:57 [david]
There overlap between success criterion. Should we merge or success criterion that overlap.
15:08:26 [Glenda]
Glenda has joined #ag
15:08:29 [david]
The results are in and we have a few suggestions.
15:09:21 [Joshue108]
15:09:26 [david]
We have quite a few suggestions there already so there is lots of justification to do it but should we do it.
15:09:59 [david]
There are strong voices on each side
15:10:38 [Joshue108]
15:11:34 [david]
Kim Dirks: I wasn't totally sure if it was talking about changing 2.0
15:11:34 [Glenda]
rrsagent, make minutes
15:11:34 [RRSAgent]
I have made the request to generate Glenda
15:11:42 [Glenda]
present+ Glenda
15:12:00 [david]
We don't want to change 2.0. If were not changing 2.0 and it's just about 2.1 then it's a lot easier but there are still strong considerations
15:12:27 [david]
Josh: we would not be changing 2.0 but we would be absorbing 2.0 into 2.1 so there would be two different standards. 2.1 would be distinct from what was in 2.0
15:12:47 [alastairc]
alastairc has joined #ag
15:12:47 [laura]
present+ Laura
15:13:02 [alastairc]
present+ alastairc
15:13:10 [david]
Michael: clarification so we can take to is a stable standard will not change regardless of what we do with 2.1 people can continue to conform to 2.0 for as long as they like were only talking about success criterion that are copied forward into 2.0. They are technically new 2.1 success criterion is just a question whether we want to merge them are not
15:13:52 [david]
Josh: We will not be touching 2.0. But when we merge 2.0 and 2.1 for the new standard should they go together
15:14:03 [david]
Kim : I understand that addresses my concern
15:14:08 [gowerm]
gowerm has joined #ag
15:14:10 [AWK]
15:14:47 [steverep]
steverep has joined #ag
15:14:55 [david]
Kathy: looking at the different success criterion at the timeline that we have I don't think we have enough time in the timeline to really go through and merge all of the success criterion is as you go through and start looking at how to merge them there's a lot of question still that need to be addressed and I think there needs to be a lot more than just merging of the success criterion to get this right which is I think is better done which is better done in si[CUT]
15:14:55 [steverep]
15:15:05 [gowerm]
present+ MikeGower
15:15:24 [Ryladog]
+1 to Kathy W
15:15:38 [shadi]
+1 to Kathy
15:15:38 [Pietro]
Pietro has joined #ag
15:15:40 [jasonjgw]
15:15:42 [Brooks_Newton]
+1 to Kathy
15:15:43 [david]
It's easier for us to communicate the changes between 2.02.1 if we did have them as separate rather than trying to merge them together and talk about the nuances that we've adjusted them to me that seemed it's going to be something that's going to be harder for people to digest what there is also by having them out as separate success criterion rather than marching them in its bid easier to start calling things out about mobile specific that's my reasons
15:16:24 [Pietro]
15:16:28 [Ryladog]
15:16:44 [david]
Josh: I would rather ask the question about whether philosophically we are okay with merging them rather than all the details of how that would do. For me the colour contrast success criterion could be merged it seems like it would be an easy win for that particular group of success criterion. That kind of things to me seems like a the trivial
15:17:05 [david]
Kathy: it might be trivial but still but there is little benefit also doing.
15:17:27 [david]
Kathy: I don't think we really gain anything by combining them except for reducing the number of success criterion is that we have overall
15:17:36 [david]
Josh: there may be a case made for that being a good thing
15:17:39 [Glenda]
I support not trying to combine at this time. The contrast SC proposed in 2.1 are complex. Combining them will actually make it harder to teach/learn and test successfully.
15:18:15 [lisa]
15:18:21 [david]
Kathy: regardless if they are in one success criterion or to success which are in the requirements are in their together. Companies are still going to combine them down
15:18:35 [Glenda]
I’d rather have clear cut new SC that I need to learn. Rather than making me figure out what I need to learn that has been merged into an existing SC that I already understood very well.
15:18:39 [JF]
+1 to Kathy
15:18:59 [Joshue108]
ack jason
15:19:00 [david]
Kathy: it's very difficult for us to combine the SCs and harder to teach
15:19:40 [JF]
15:19:59 [chriscm]
15:21:06 [Glenda]
15:21:13 [alastairc]
Having thought abaout the graphics contrast proposals, we could jam them together, but it would make very little different to the amount of words used.
15:23:22 [Joshue108]
ack ryl
15:23:26 [shadi]
-1 to making the numbering yet more confusing
15:23:34 [AWK]
q+ to say that the merge problems compound if we decide down the road to do a 2.2 or 2.3, etc
15:23:43 [lisa]
agree wuth shadi
15:23:52 [david-macdonald]
15:25:20 [Glenda]
scribe: Glenda
15:25:26 [MichaelC_]
MichaelC_ has joined #ag
15:25:33 [Joshue108]
ack lisa
15:25:55 [Glenda]
Katie: number of SC is not as important as making it clear how to test (and teach).
15:26:00 [Ryladog]
I am strongly in favor of very specific distinct requirements. It is easier for others to implement new requirements thanto changeexisting criteria.
15:26:13 [david-macdonald2]
david-macdonald2 has joined #ag
15:26:31 [david-macdonald2]
scribe: david-macdonald2
15:26:40 [Glenda]
Lisa: to Kathy’s point, if there is a strong overlap, it makes it easier to merge.
15:26:44 [david-macdonald2]
Test test
15:27:27 [shadi]
15:27:41 [AWK]
q+ to say that there are also potential problems for sites where they meet WCAG 2.0 but not 2.1. They won't be able to express conformance to 2.0 through a 2.1 claim.
15:27:49 [david-macdonald2]
Lisa: nobody wants to merge things that don't fit this is where it makes it simpler to be will in the specification of its one instead of two. That's the whole reason the merge. It will be ambiguous because one will be prefaced by 2.0 and there will be 2.1
15:28:00 [Ryladog]
So I want it to be very clear what developers need to do, and very clear what testers need to test. That is more important to me than the number of SCs
15:28:01 [Glenda]
15:28:35 [david-macdonald2]
Lisa: we want to merge where it makes it less complex were not too worried about people with tools or reports. They can easily say what standard there conforming to and there will be a bit different. And I think that's okay to
15:28:45 [lisa]
15:28:53 [Joshue108]
ack jf
15:29:18 [alastairc]
Why would a conformance claim against 2.0 change for 2.1?
15:29:42 [david-macdonald2]
John folio: I have serious concerns about what would do to conformance claims made before today. We can't be changing existing success criteria out from underneath. I think of 2.1 built on top at 2.0.
15:29:45 [david-macdonald2]
15:29:53 [alastairc]
15:30:10 [david-macdonald2]
John: for people who don't do this on a regular basis I'm concerned about people who don't do this as a regular part of their portfolio
15:30:17 [MichaelC_]
q+ to say a WCAG 2.1 conformance claim has nothing to do with a WCAG 2.0 conformance claim
15:30:21 [JF]
15:30:22 [AWK]
ack AWK
15:30:22 [Zakim]
AWK, you wanted to say that the merge problems compound if we decide down the road to do a 2.2 or 2.3, etc and to say that there are also potential problems for sites where they
15:30:23 [david-macdonald2]
Josh: this is all predicated on the fact that we don't make things more complicated
15:30:25 [Zakim]
... meet WCAG 2.0 but not 2.1. They won't be able to express conformance to 2.0 through a 2.1 claim.
15:30:29 [Joshue108]
ack awk
15:30:35 [MichaelC_]
q+ to say in my survey comments I propose we need to test affected SC from 2.0 to ensure we don´t break backwards compatibility
15:30:48 [Joshue108]
15:31:09 [david-macdonald2]
Andrew: I'm trying to put something into remind me and I guess I need to… I agree with John and I think the merge problems be worse if we have a 2.2 or 2.3 or 2.4 if we continue going forward.
15:31:24 [MichaelC_]
q+ to say WCAG 2.1 should be coherent unto itself
15:31:25 [Alex]
Alex has joined #ag
15:31:54 [MichaelC_]
q+ to say WCAG 2.0 has SC that modify each other, so it should be fine that WCAG 2.1 does
15:31:57 [JakeAbma]
JakeAbma has joined #ag
15:32:05 [JakeAbma]
present+ JakeAbma
15:32:27 [david-macdonald2]
Andrew: also if you also have a website where you need to meet WCAG 2.0 and you need to meet 2.1 for other customers. We are very difficult to pull everything apart if you develop something and you don't meet 2.1 and may be that if we make a change at 2.2.1 and you don't need that the next version of the standard then you have a challenge expressing that you've met the success graduated 2.0
15:32:34 [Ryladog]
My other point was that as interaction paradigms continue to change, having separate distinct requirements eases that challenge
15:32:39 [chriscm]
15:32:41 [kirkwood]
kirkwood has joined #ag
15:32:54 [Joshue108]
ack shadi
15:32:58 [MichaelC_]
q+ to say affect on numbering should not be a factor in the decision
15:33:23 [david-macdonald2]
Shadi: I want to touch upon the point that Andrew just raised. For policy and other standards that build on what gag the transition period between 2.0 and 2.1 the European standard that is being created in which we hope will be able to harmonize with 2.1 needs to be backwards compatible with 2.0 because that's what the policy is in Europe right now
15:34:00 [david-macdonald2]
Shadi: I understand the 2.0 will be a subset of 2.1 but there will be confusion that will emerge by having the same requirements of different wording will creates difficulties so I want to add this standards and policy aspects Kathy was talking about
15:34:51 [shadi]
15:34:52 [david-macdonald2]
Josh: then the question is how do we progress in this or any other technical domain factor in backwards compatibility that we have to improve by simplifying clarifying and strengthening I wonder if this is a good degree of fear here with comes the suggestion of changing the specification at all I'm just wondering if how much factor that is.
15:35:02 [Joshue108]
ack david
15:35:14 [Joshue108]
DavidMacD: I'm divided about this.
15:35:58 [Joshue108]
DMD: I am concerned a la legislation.. if 2.1 is building on 2.0, then 2.1 will look like AAA.
15:35:59 [JF]
15:36:05 [lisa]
+1 to david
15:36:10 [Joshue108]
DDM: So it will look like we just added stuff on.
15:36:26 [MichaelC]
MichaelC has joined #ag
15:36:40 [Joshue108]
DMD: I like the idea of integrating.
15:36:53 [JF]
that's exactly why I am opposed to that David - you can't
15:37:06 [JF]
"up the game" while in transit
15:37:27 [jasonjgw]
15:37:44 [AWK]
q+ to say that WCAG 2.1 changes will only be like AAA if it isn't adopted into policy anywhere
15:38:26 [JF]
David, not "bolted on" but layered on - a huge difference
15:39:35 [Joshue108]
ack alast
15:39:57 [steverep]
q+ to remind that familiarity with WCAG 2.0 is the minority in the outside world
15:40:02 [david-macdonald2]
David: I want to ensure that it is not perceived as a bolt on standard 2.0 and integration would make it better.
15:40:14 [kirkwood]
15:40:39 [david-macdonald2]
Alastair: I can appreciate being backwards compatible but I teach about 20 developers a month and most of them have never read the standard and so anything we can do to make it more coherent and understandable I would like to take advantage of the possible.
15:40:52 [david-macdonald2]
Josh: chair hat off I agree with that perception
15:41:02 [Joshue108]
ack michael
15:41:02 [Zakim]
MichaelC_, you wanted to say a WCAG 2.1 conformance claim has nothing to do with a WCAG 2.0 conformance claim and to say in my survey comments I propose we need to test affected SC
15:41:05 [Zakim]
... from 2.0 to ensure we don´t break backwards compatibility and to say WCAG 2.1 should be coherent unto itself and to say WCAG 2.0 has SC that modify each other, so it should be
15:41:05 [Zakim]
... fine that WCAG 2.1 does and to say affect on numbering should not be a factor in the decision
15:42:46 [david-macdonald]
i got kicked out... coming back... need t keep posts shorter
15:43:08 [david-macdonald3]
david-macdonald3 has joined #ag
15:43:22 [AWK]
MC - you aren't proposing that existing 2.0 SC numbers will change are you?
15:43:23 [david-macdonald3]
scribe: David-macdonald3
15:44:00 [david-macdonald3]
Michael: I could go either way
15:45:33 [JF]
STRONGLY oppose Michael's suggestion
15:45:53 [AWK]
q+ to also say that the 2.0 numbering is not meaningless, even if it was originally
15:46:29 [david-macdonald3]
Michael: I'm fine if numbers change, 2.1 is its own thing... if there is a good reason for doing so
15:47:17 [Joshue108]
ack chriscm
15:47:26 [david-macdonald3]
Michael: if its only for the value of a few merged Sc then it might not be worth the overhead
15:48:31 [david-macdonald3]
Chris: not talking about whether good or not to merge but technical numbering... numbering is very importatn to technical standards, we are talkinging about the difference between 2.1 and 2.0
15:49:37 [david-macdonald3]
Chris: I like making it more digestible, but if we merge its not 2.1 but a 3.0
15:50:32 [david-macdonald3]
Michael: we never promised consistency of numbering between versions
15:50:44 [david-macdonald3]
Josh: we don't want to be constrained for theoretical reasons
15:50:55 [Mike_Pluke]
15:50:58 [david-macdonald3]
Chris: if society and the world has decided that your numbers are important and the success criterion. To arbitrarily discard them is to jeopardize the value of your standard.
15:51:09 [david-macdonald3]
Chris: the world we have decided those important things we should not ignore that
15:51:10 [Joshue108]
ack jf
15:51:52 [david-macdonald3]
John folio: I completely agree with Chris. We deal with these kinds of issues on a regular basis. I would be strongly opposed to changing numbers. There is a mapping exercise that would not be trivial I would have to go along with that.
15:51:56 [gowerm]
15:52:02 [david-macdonald3]
15:52:08 [Joshue108]
zakim, close queue
15:52:08 [Zakim]
ok, Joshue108, the speaker queue is closed
15:52:21 [david-macdonald3]
The reality is is the distant numbers of been stable for more than a decade now. Irina change numbers we should be going to 3.0
15:52:23 [shadi]
+1 to JF
15:52:28 [Brooks_Newton]
+1 JF
15:52:35 [Makoto]
+1 to JF
15:52:41 [david-macdonald3]
I would be very opposed to changing numbers in a 2.X framework
15:52:41 [JakeAbma]
+1 JF
15:53:04 [Joshue108]
ack jason
15:53:05 [kirkwood]
+1 to JF
15:53:33 [david-macdonald3]
Jason: I would be very concerned if the working group were to adopt the position that the normative text which is inherited from 2.0 can't be changed in 2.1 in those instances where we think it's necessary and desirable that kind of position would be very problematic
15:54:14 [JF]
Build on top of the normative text of 2.0, don't change it mid-stream
15:54:31 [david-macdonald3]
One response to that would be to move to silver and that's fine but that's a different conversation. I'm just concerned about the extreme position in which would rule out normative changes to the text that we've inherited. I also agree that we we have to make it as easy as possible to those who are reading
15:55:08 [david-macdonald3]
Jason: there are not that many places where merging makes sense so it seems that we are getting very rather concerned over would probably be a relatively small number of changes to existing text and yes it does involve a bit more care that needs to be taken to make sure that it's backwards compatible with 2.0 but I think it could be done very straightforwardly
15:56:01 [Joshue108]
ack awk
15:56:01 [Zakim]
AWK, you wanted to say that WCAG 2.1 changes will only be like AAA if it isn't adopted into policy anywhere and to also say that the 2.0 numbering is not meaningless, even if it
15:56:01 [david-macdonald3]
Josh: that leads neatly into conversation that we would get the same situation in the next versions. So I'm also concerned of the group takes over rather trenched extreme position over not making any emerging make future versions a lot more compromised.
15:56:04 [Zakim]
... was originally
15:56:12 [alastairc]
I guess the (HTML style) workaround would be to mark an SC as depricated, with the requirements moved into another SC.
15:56:36 [david-macdonald3]
John: there's a lot of legislations around the world
15:57:02 [david-macdonald3]
Josh: I've heard that argument but I think the work itself needs to be the best he could be and it may or may not involve architectural changes.
15:57:25 [Joshue108]
ack awk
15:58:13 [david-macdonald3]
Andrew: I agree with Michael that the numbering was meaningless just like numbering for the new SCs is currently meaningless but I do think that the numbering for 2.0. It's a bizarre type of knowledge but the numbers are very important just like it's important our comprehensive document.
15:58:25 [alastairc]
Hmm, only took me a year to completely forget the WCAG 1.0 numbering ;-)
15:58:27 [JF]
@AWK *Exactly!!!*
15:58:35 [chriscm]
+1 To AWK
15:58:44 [Ryladog]
+1 to AWK
15:58:44 [gowerm]
+1 Alastair
15:58:50 [david-macdonald3]
This would make the work of an accessibility professional very difficult I would very much like to avoid introducing that we are very good making things hard to understand.
15:58:55 [JF]
+1 to AWK
15:59:06 [Brooks_Newton]
+1 to AWK
15:59:25 [Glenda]
scribe: Glenda
15:59:59 [steverep]
How does that change somehow for 3.0? The constraint will stifle progress.
16:00:21 [AWK]
@alastair - but you'll need to remember both sets of numbers for a while since 2.0 and 2.1 will coexist for a good while
16:00:23 [Joshue108]
ack steve
16:00:23 [Zakim]
steverep, you wanted to remind that familiarity with WCAG 2.0 is the minority in the outside world
16:01:16 [Glenda]
steverep: agree with Alastair’s comment on making WCAG 2.1 easy to learn for people who are new to accessibility, seems like something we can do.
16:01:46 [Glenda]
Scribe: Glenda
16:01:49 [Joshue108]
ack Mike
16:02:12 [JF]
16:03:21 [Glenda]
Mike_Pluke: I’m giving the counter argument again. Respect that people do know what the current WCAG 2.0 numbers mean. Changing it causes confusion. Although the numbering didn’t start off with significance, it is very much used now. It has signficance now. Message coming from those reviewingin the European Standard.
16:03:51 [alastairc]
We could easily maintain a mapping for the 0.01% of people who know the numbers, and track merges/changes.
16:03:57 [chriscm]
Yes, but then users USE those tools, and links in those tools break. Which is inexcusable for a 2.0 -> 2.1 type of release.
16:04:03 [Glenda]
Josh: I have to push back on this. The only people who know these numbers are accessibility experts and those who are creating tools. I never considered the numbering as a reason to not merge. But I do take your points Mike. We do need to consdier.
16:04:07 [JF]
disagree Josh, legislations know the numbers, tooling uses the numbers, conformance claims use the numbers
16:04:09 [Glenda]
16:04:21 [Joshue108]
ack gower ack gower
16:04:27 [Joshue108]
ack gower
16:05:16 [JF]
msg/ AWK seems to me I tried to raise this issue about 12 months+ ago
16:05:20 [MelanieP]
Are we unnecessarily conflating two different topics: 1 - merging new SCs and old SCs and 2 - changing existing SC numbers?
16:05:29 [JF]
s/msg/ AWK seems to me I tried to raise this issue about 12 months+ ago/
16:06:12 [Glenda]
gowerm: started talking about merging, but now we are talking about numbering. If you elect not to merge, then you will be adding new SC. In a situationi where we add a new SC that relates to a current SC, it helps to have those SC close together. Mapping is doable. I don’t think the numbering is correlated with merging.
16:06:26 [JF]
16:06:55 [Glenda]
gowerm: if there are things we can merge, to clarify that would be good.
16:07:00 [Joshue108]
ack david
16:07:35 [Glenda]
David: I am on the opposite side of what Mike was saying. I memorized the numbers. But not many people have those memories.
16:08:19 [Alex]
16:08:23 [Glenda]
David: merging, if you don’t pass WCAG 2.1, but you do pass WCAG 2.0…then merging things would cause problems. Merging helps encourage people to go to WCAG 2.1.
16:08:24 [Joshue108]
ack jf
16:09:31 [Glenda]
JF: if we want to do a significant renumbering and merging, then we should be doing a WCAG 3.0. This is a minor dot extension. We should not renumber. 2.1 should build on what is already in WCAG 2.0.
16:09:50 [Alex]
I think I have a solution
16:09:52 [alastairc]
Not so, take the HTML approach. Leave the SC (and numbers) where they are, but specifiy that 5.2.3 is depreicated, and covered by 5.2.4. Create a version which is 'complete', and one sutiable for new(er) people
16:09:57 [steverep]
What a dot extension does is specific to what it is extending, and nowhere did we document numbering cannot change. That argument is baseless IMHO.
16:10:55 [gowerm]
+1 Steve
16:11:17 [JF]
-1 steve
16:11:22 [Glenda]
Alex: if you merge the two things, you would have to list differences between any SC that can be met with different requirements under WCAG 2.0 vs WCAG 2.1. So, you could have a cohesive WCAG 2.1 with the WCAG 2.0 step downs on a few SC.
16:12:06 [Glenda]
Ales: adding IF WCAG 2.0 THEN statements (only where necessary)
16:12:24 [AWK]
16:12:26 [Glenda]
Josh: I don’t hear a consensus. This will need more discussion.
16:12:45 [Glenda]
RESOLUTION: Leave this open. Needs more discussion.
16:12:51 [Glenda]
Zakim, Next Item
16:12:51 [Zakim]
agendum 2. "2) Implementation testing process - (" taken up [from Joshue108]
16:13:20 [Joshue108]
16:13:50 [AWK]
Going to suggest that we might need more feedback on the survey...
16:14:30 [Joshue108]
16:14:36 [Glenda]
Joshue: should we follow the same process or modify the process? Not seeing many responses. Please answer the survey.
16:15:03 [david-macdonald3]
16:15:03 [Glenda]
RESOLUTION: Leave this open. Will discuss after more have answered the survey next week.
16:15:38 [Glenda]
Zakim, Next Item
16:15:38 [Zakim]
I see a speaker queue remaining and respectfully decline to close this agendum, Glenda
16:15:43 [Glenda]
ack David
16:15:48 [Glenda]
Zakim, next item
16:15:48 [Zakim]
agendum 3. "3) Responding to comments: Sharing the workload (Github comments and responses)." taken up [from Joshue108]
16:16:59 [Glenda]
AWK: Followup from last week. Spent time going thru issues in github. We’ve closed anything that is now moot. What we are left with is a bunch of issues that are not trivial or obvious. We need to get people to help out.
16:17:08 [AWK]
16:17:24 [lisa]
I need to drop now.
16:19:08 [Glenda]
For comments from outside, don’t respond in the github issue yet. First, draft your thoughts, and send around to the AG list, so you can get input from the whole group. Then we can provide a true group response.
16:19:21 [chriscm]
chriscm has joined #ag
16:20:13 [Glenda]
AWK: one about color contrast in the spec, can someone volunteer to do an accessibility review of the spec itself to make sure it meets requirements
16:20:23 [gowerm]
16:21:10 [Glenda]
gowerm: just to clarify, we are okay to comment if the question is from a AGWG member. But if the comment is from outside the AGWG, then we should discuss within this WG before responding.
16:21:10 [alastairc]
can we ask questions of external people to clarify, before an official response?
16:22:11 [Glenda]
AWK: Example, we want to provide a group response for items like this (this may involve an AGWG survey first)
16:23:23 [Glenda]
Is the “Public Comment” tag an indicator in github that we should get group agreement before responding? AWK: that has not been consistently used…some of the Public Comments look like they are from AWK…but he put them in based on feedback from external sources.
16:24:07 [Glenda]
AWK: 22 open now, there will be a lot more. We need your help. Please volunteer to help us respond. As we go out for a wider review, we will need to keep on top of these.
16:24:11 [AWK]
ack go
16:24:29 [Glenda]
16:25:14 [Glenda]
Zakim, close item 3
16:25:14 [Zakim]
agendum 3, 3) Responding to comments: Sharing the workload (Github comments and responses)., closed
16:25:16 [Zakim]
I see nothing remaining on the agenda
16:25:16 [Joshue108]
16:25:46 [Glenda]
rrsagent, make logs public
16:26:11 [Glenda]
rrsagent, make minutes
16:26:11 [RRSAgent]
I have made the request to generate Glenda
16:27:19 [Glenda]
trackbot, end meeting
16:27:19 [trackbot]
Zakim, list attendees
16:27:19 [Zakim]
As of this point the attendees have been AWK, KimD, Joshue108, shadi, Roy, jasonjgw, MichaelC, Mike_Pluke, Brooks, JF, Makoto, Greg_Lowney, Kathy, Katie_Haritos-Shea,
16:27:22 [Zakim]
... david-macdonald, Melanie_Philipp, lisa, Glenda, Laura, alastairc, steverep, MikeGower, Pietro, chriscm, JakeAbma, kirkwood
16:27:27 [trackbot]
RRSAgent, please draft minutes
16:27:27 [RRSAgent]
I have made the request to generate trackbot
16:27:28 [trackbot]
RRSAgent, bye
16:27:28 [RRSAgent]
I see no action items