14:31:46 RRSAgent has joined #ag 14:31:46 logging to http://www.w3.org/2017/09/12-ag-irc 14:31:48 RRSAgent, make logs public 14:31:48 Zakim has joined #ag 14:31:50 Meeting: Accessibility Guidelines Working Group Teleconference 14:31:50 Date: 12 September 2017 14:32:00 zakim, agenda? 14:32:00 I see nothing on the agenda 14:32:09 zakim, clear agenda 14:32:09 agenda cleared 14:32:21 agenda+ 1) New SCs - To Merge or not to merge? Survey https://www.w3.org/2002/09/wbs/35422/SC_merge/ 14:32:31 agenda+ 2) Implementation testing process - (https://www.w3.org/2002/09/wbs/35422/WCAG21_impl/). 14:32:43 agenda+ 3) Responding to comments: Sharing the workload (Github comments and responses). 14:32:54 Chair: Joshue108 14:42:12 AWK has joined #ag 14:42:20 agenda? 14:49:50 zakim, who is on the phone? 14:49:50 Present: (no one) 14:49:52 +AWK 14:50:07 rrsagent, draft minutes 14:50:07 I have made the request to generate http://www.w3.org/2017/09/12-ag-minutes.html AWK 14:50:24 rrsagent, set logs public 14:53:25 allanj has joined #ag 14:53:47 KimD has joined #ag 14:53:54 Present+ KimD 14:55:10 regrets+ Bruce_Bailey, Jake_Abma, Jan_McSorley, Brooks_Newton, Chris_Loiselle, James_Nurthen, EA_Draffan, Detlev_Fischer 14:57:59 Mike_Pluke has joined #ag 14:58:08 Roy has joined #ag 14:58:41 present+ Joshue108 14:58:51 zakim, agenda? 14:58:51 I see 3 items remaining on the agenda: 14:58:52 1. 1) New SCs - To Merge or not to merge? Survey https://www.w3.org/2002/09/wbs/35422/SC_merge/ [from Joshue108] 14:58:52 2. 2) Implementation testing process - (https://www.w3.org/2002/09/wbs/35422/WCAG21_impl/). [from Joshue108] 14:58:52 3. 3) Responding to comments: Sharing the workload (Github comments and responses). [from Joshue108] 14:59:08 present+ 14:59:22 present+ Roy 14:59:24 chriscm has joined #ag 15:00:02 MelanieP has joined #ag 15:00:13 Brooks_Newton has joined #ag 15:00:33 regrets- Brooks_Newton 15:00:41 jasonjgw has joined #ag 15:00:52 present+ 15:01:08 present+ 15:01:13 present+ Mike_Pluke 15:01:14 present+ Brooks 15:01:27 Greg has joined #ag 15:01:29 present+ Joshue108 15:01:51 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 has joined #ag 15:02:24 JF has joined #AG 15:02:33 Beautiful!!! Bookmarking this, thanks Josh! 15:02:35 present+ JF 15:02:46 present+ Makoto 15:03:41 david-macdonald has joined #ag 15:04:00 present+ Greg_Lowney 15:04:04 Kathy has joined #ag 15:04:21 present+ Kathy 15:04:39 david has joined #ag 15:04:50 Ryladog has joined #ag 15:05:07 agenda? 15:05:09 Present+ Katie_Haritos-Shea 15:05:09 Present+ david-macdonald 15:05:29 scribe:David 15:05:44 Scribenick: DavidMacD 15:06:16 zakim: take uo item 1 15:06:17 zakim, next iteam 15:06:17 I don't understand 'next iteam', Joshue108 15:06:20 zakim, next item 15:06:20 agendum 1. "1) New SCs - To Merge or not to merge? Survey https://www.w3.org/2002/09/wbs/35422/SC_merge/" taken up [from Joshue108] 15:06:42 laura has joined #ag 15:06:46 present+ Melanie_Philipp 15:07:00 present+ 15:07:02 https://www.w3.org/2002/09/wbs/35422/SC_merge/ 15:07:03 Josh: interesting things on the agenda one of them is the candidate wcag 2.1 success criterion 15:07:43 Rachael has joined #ag 15:07:51 https://www.w3.org/2017/08/telecon-info_ag 15:07:57 There overlap between success criterion. Should we merge or success criterion that overlap. 15:08:26 Glenda has joined #ag 15:08:29 The results are in and we have a few suggestions. 15:09:21 q? 15:09:26 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 There are strong voices on each side 15:10:38 q? 15:11:34 Kim Dirks: I wasn't totally sure if it was talking about changing 2.0 15:11:34 rrsagent, make minutes 15:11:34 I have made the request to generate http://www.w3.org/2017/09/12-ag-minutes.html Glenda 15:11:42 present+ Glenda 15:12:00 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 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 has joined #ag 15:12:47 present+ Laura 15:13:02 present+ alastairc 15:13:10 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 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 Kim : I understand that addresses my concern 15:14:08 gowerm has joined #ag 15:14:10 q? 15:14:47 steverep has joined #ag 15:14:55 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 present+steverep 15:15:05 present+ MikeGower 15:15:24 +1 to Kathy W 15:15:38 +1 to Kathy 15:15:38 Pietro has joined #ag 15:15:40 q+ 15:15:42 +1 to Kathy 15:15:43 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 Present+ 15:16:28 q+ 15:16:44 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 Kathy: it might be trivial but still but there is little benefit also doing. 15:17:27 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 Josh: there may be a case made for that being a good thing 15:17:39 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 q+ 15:18:21 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 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 +1 to Kathy 15:18:59 ack jason 15:19:00 Kathy: it's very difficult for us to combine the SCs and harder to teach 15:19:40 Q+ 15:19:59 present+ 15:21:06 q+ 15:21:13 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 ack ryl 15:23:26 -1 to making the numbering yet more confusing 15:23:34 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 agree wuth shadi 15:23:52 test 15:25:20 scribe: Glenda 15:25:26 MichaelC_ has joined #ag 15:25:33 ack lisa 15:25:55 Katie: number of SC is not as important as making it clear how to test (and teach). 15:26:00 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 has joined #ag 15:26:31 scribe: david-macdonald2 15:26:40 Lisa: to Kathy’s point, if there is a strong overlap, it makes it easier to merge. 15:26:44 Test test 15:27:27 q+ 15:27:41 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 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 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 q- 15:28:35 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 q- 15:28:53 ack jf 15:29:18 Why would a conformance claim against 2.0 change for 2.1? 15:29:42 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 q+ 15:29:53 q+ 15:30:10 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 q+ to say a WCAG 2.1 conformance claim has nothing to do with a WCAG 2.0 conformance claim 15:30:21 s/folio/Foliot 15:30:22 ack AWK 15:30:22 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 Josh: this is all predicated on the fact that we don't make things more complicated 15:30:25 ... 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 ack awk 15:30:35 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 https://www.w3.org/2002/09/wbs/35422/SC_merge/results 15:31:09 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 q+ to say WCAG 2.1 should be coherent unto itself 15:31:25 Alex has joined #ag 15:31:54 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 has joined #ag 15:32:05 present+ JakeAbma 15:32:27 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 My other point was that as interaction paradigms continue to change, having separate distinct requirements eases that challenge 15:32:39 q+ 15:32:41 kirkwood has joined #ag 15:32:54 ack shadi 15:32:58 q+ to say affect on numbering should not be a factor in the decision 15:33:23 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 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 s/Kathy/Katie 15:34:52 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 ack david 15:35:14 DavidMacD: I'm divided about this. 15:35:58 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 Q+ 15:36:05 +1 to david 15:36:10 DDM: So it will look like we just added stuff on. 15:36:26 MichaelC has joined #ag 15:36:40 DMD: I like the idea of integrating. 15:36:53 that's exactly why I am opposed to that David - you can't 15:37:06 "up the game" while in transit 15:37:27 q+ 15:37:44 q+ to say that WCAG 2.1 changes will only be like AAA if it isn't adopted into policy anywhere 15:38:26 David, not "bolted on" but layered on - a huge difference 15:39:35 ack alast 15:39:57 q+ to remind that familiarity with WCAG 2.0 is the minority in the outside world 15:40:02 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 present+ 15:40:39 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 Josh: chair hat off I agree with that perception 15:41:02 ack michael 15:41:02 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 ... 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 ... fine that WCAG 2.1 does and to say affect on numbering should not be a factor in the decision 15:42:46 i got kicked out... coming back... need t keep posts shorter 15:43:08 david-macdonald3 has joined #ag 15:43:22 MC - you aren't proposing that existing 2.0 SC numbers will change are you? 15:43:23 scribe: David-macdonald3 15:44:00 Michael: I could go either way 15:45:33 STRONGLY oppose Michael's suggestion 15:45:53 q+ to also say that the 2.0 numbering is not meaningless, even if it was originally 15:46:29 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 ack chriscm 15:47:26 Michael: if its only for the value of a few merged Sc then it might not be worth the overhead 15:48:31 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 Chris: I like making it more digestible, but if we merge its not 2.1 but a 3.0 15:50:32 Michael: we never promised consistency of numbering between versions 15:50:44 Josh: we don't want to be constrained for theoretical reasons 15:50:55 Q+ 15:50:58 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 Chris: the world we have decided those important things we should not ignore that 15:51:10 ack jf 15:51:52 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 q+ 15:52:02 q+ 15:52:08 zakim, close queue 15:52:08 ok, Joshue108, the speaker queue is closed 15:52:21 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 +1 to JF 15:52:28 +1 JF 15:52:35 +1 to JF 15:52:41 I would be very opposed to changing numbers in a 2.X framework 15:52:41 +1 JF 15:53:04 ack jason 15:53:05 +1 to JF 15:53:33 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 Build on top of the normative text of 2.0, don't change it mid-stream 15:54:31 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 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 ack awk 15:56:01 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 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 ... was originally 15:56:12 I guess the (HTML style) workaround would be to mark an SC as depricated, with the requirements moved into another SC. 15:56:36 John: there's a lot of legislations around the world 15:57:02 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 ack awk 15:58:13 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 Hmm, only took me a year to completely forget the WCAG 1.0 numbering ;-) 15:58:27 @AWK *Exactly!!!* 15:58:35 +1 To AWK 15:58:44 +1 to AWK 15:58:44 +1 Alastair 15:58:50 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 +1 to AWK 15:59:06 +1 to AWK 15:59:25 scribe: Glenda 15:59:59 How does that change somehow for 3.0? The constraint will stifle progress. 16:00:21 @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 ack steve 16:00:23 steverep, you wanted to remind that familiarity with WCAG 2.0 is the minority in the outside world 16:01:16 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 Scribe: Glenda 16:01:49 ack Mike 16:02:12 Q+ 16:03:21 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 We could easily maintain a mapping for the 0.01% of people who know the numbers, and track merges/changes. 16:03:57 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 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 disagree Josh, legislations know the numbers, tooling uses the numbers, conformance claims use the numbers 16:04:09 agenda? 16:04:21 ack gower ack gower 16:04:27 ack gower 16:05:16 msg/ AWK seems to me I tried to raise this issue about 12 months+ ago 16:05:20 Are we unnecessarily conflating two different topics: 1 - merging new SCs and old SCs and 2 - changing existing SC numbers? 16:05:29 s/msg/ AWK seems to me I tried to raise this issue about 12 months+ ago/ 16:06:12 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 Q+ 16:06:55 gowerm: if there are things we can merge, to clarify that would be good. 16:07:00 ack david 16:07:35 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 q+ 16:08:23 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 ack jf 16:09:31 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 I think I have a solution 16:09:52 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 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 +1 Steve 16:11:17 -1 steve 16:11:22 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 Ales: adding IF WCAG 2.0 THEN statements (only where necessary) 16:12:24 agenda? 16:12:26 Josh: I don’t hear a consensus. This will need more discussion. 16:12:45 RESOLUTION: Leave this open. Needs more discussion. 16:12:51 Zakim, Next Item 16:12:51 agendum 2. "2) Implementation testing process - (https://www.w3.org/2002/09/wbs/35422/WCAG21_impl/)." taken up [from Joshue108] 16:13:20 https://www.w3.org/WAI/GL/WCAG20/implementation-report/ 16:13:50 Going to suggest that we might need more feedback on the survey... 16:14:30 https://www.w3.org/2002/09/wbs/35422/WCAG21_impl/ 16:14:36 Joshue: should we follow the same process or modify the process? Not seeing many responses. Please answer the survey. 16:15:03 q+ 16:15:03 RESOLUTION: Leave this open. Will discuss after more have answered the survey next week. 16:15:38 Zakim, Next Item 16:15:38 I see a speaker queue remaining and respectfully decline to close this agendum, Glenda 16:15:43 ack David 16:15:48 Zakim, next item 16:15:48 agendum 3. "3) Responding to comments: Sharing the workload (Github comments and responses)." taken up [from Joshue108] 16:16:59 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 https://github.com/w3c/wcag21/issues?q=is%3Aopen+is%3Aissue+label%3A%22AGWG+Work+item%22 16:17:24 I need to drop now. 16:19:08 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 has joined #ag 16:20:13 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 https://github.com/w3c/wcag21/issues/156 16:20:23 q+ 16:21:10 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 can we ask questions of external people to clarify, before an official response? 16:22:11 AWK: Example, we want to provide a group response for items like this https://github.com/w3c/wcag21/issues/211 (this may involve an AGWG survey first) 16:23:23 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 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 ack go 16:24:29 agenda? 16:25:14 Zakim, close item 3 16:25:14 agendum 3, 3) Responding to comments: Sharing the workload (Github comments and responses)., closed 16:25:16 I see nothing remaining on the agenda 16:25:16 q? 16:25:46 rrsagent, make logs public 16:26:11 rrsagent, make minutes 16:26:11 I have made the request to generate http://www.w3.org/2017/09/12-ag-minutes.html Glenda 16:27:19 trackbot, end meeting 16:27:19 Zakim, list attendees 16:27:19 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 ... david-macdonald, Melanie_Philipp, lisa, Glenda, Laura, alastairc, steverep, MikeGower, Pietro, chriscm, JakeAbma, kirkwood 16:27:27 RRSAgent, please draft minutes 16:27:27 I have made the request to generate http://www.w3.org/2017/09/12-ag-minutes.html trackbot 16:27:28 RRSAgent, bye 16:27:28 I see no action items