See also: IRC log
<AWK> +AWK
<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...
<chriscm> Beautiful!!! Bookmarking this, thanks Josh!
<david> scribe:David
<Joshue108> Scribenick: DavidMacD
<david> zakim: take uo item 1
<Joshue108> https://www.w3.org/2002/09/wbs/35422/SC_merge/
<david> Josh: interesting things on the agenda one of them is the candidate wcag 2.1 success criterion
<Joshue108> https://www.w3.org/2017/08/telecon-info_ag
<david> There overlap between success criterion. Should we merge or success criterion that overlap.
<david> The results are in and we have a few suggestions.
<david> We have quite a few suggestions there already so there is lots of justification to do it but should we do it.
<david> There are strong voices on each side
<david> Kim Dirks: I wasn't totally sure if it was talking about changing 2.0
<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
<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
<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
<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
<david> Kim : I understand that addresses my concern
<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]
<Ryladog> +1 to Kathy W
<shadi> +1 to Kathy
<Brooks_Newton> +1 to Kathy
<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
<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
<david> Kathy: it might be trivial but still but there is little benefit also doing.
<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
<david> Josh: there may be a case made for that being a good thing
<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.
<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
<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.
<JF> +1 to Kathy
<david> Kathy: it's very difficult for us to combine the SCs and harder to teach
<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.
<shadi> -1 to making the numbering yet more confusing
<lisa> agree wuth shadi
<david-macdonald> test
<Glenda> scribe: Glenda
Katie: number of SC is not as important as making it clear how to test (and teach).
<Ryladog> I am strongly in favor of very specific distinct requirements. It is easier for others to implement new requirements thanto changeexisting criteria.
<david-macdonald2> scribe: david-macdonald2
<Glenda> Lisa: to Kathy’s point, if there is a strong overlap, it makes it easier to merge.
Test test
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
<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
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
<alastairc> Why would a conformance claim against 2.0 change for 2.1?
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.
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 portFoliot
<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
Josh: this is all predicated on the fact that we don't make things more complicated
<Joshue108> https://www.w3.org/2002/09/wbs/35422/SC_merge/results
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.
... 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
<Ryladog> My other point was that as interaction paradigms continue to change, having separate distinct requirements eases that challenge
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
... 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 Katie was talking about
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.
<Joshue108> DavidMacD: I'm divided about this.
<Joshue108> DMD: I am concerned a la legislation.. if 2.1 is building on 2.0, then 2.1 will look like AAA.
<lisa> +1 to david
<Joshue108> DDM: So it will look like we just added stuff on.
<Joshue108> DMD: I like the idea of integrating.
<JF> that's exactly why I am opposed to that David - you can't
<JF> "up the game" while in transit
<JF> David, not "bolted on" but layered on - a huge difference
David: I want to ensure that it is not perceived as a bolt on standard 2.0 and integration would make it better.
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.
Josh: chair hat off I agree with that perception
<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
<david-macdonald> i got kicked out... coming back... need t keep posts shorter
<AWK> MC - you aren't proposing that existing 2.0 SC numbers will change are you?
<david-macdonald3> scribe: David-macdonald3
Michael: I could go either way
<JF> STRONGLY oppose Michael's suggestion
Michael: I'm fine if numbers
change, 2.1 is its own thing... if there is a good reason for
doing so
... if its only for the value of a few merged Sc then it might
not be worth the overhead
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
... I like making it more digestible, but if we merge its not
2.1 but a 3.0
Michael: we never promised consistency of numbering between versions
Josh: we don't want to be constrained for theoretical reasons
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.
... the world we have decided those important things we should
not ignore that
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.
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
<shadi> +1 to JF
<Brooks_Newton> +1 JF
<Makoto> +1 to JF
I would be very opposed to changing numbers in a 2.X framework
<JakeAbma> +1 JF
<kirkwood> +1 to JF
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
<JF> Build on top of the normative text of 2.0, don't change it mid-stream
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
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
<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
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.
<alastairc> I guess the (HTML style) workaround would be to mark an SC as depricated, with the requirements moved into another SC.
John: there's a lot of legislations around the world
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.
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.
<alastairc> Hmm, only took me a year to completely forget the WCAG 1.0 numbering ;-)
<JF> @AWK *Exactly!!!*
<chriscm> +1 To AWK
<Ryladog> +1 to AWK
<gowerm> +1 Alastair
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.
<JF> +1 to AWK
<Brooks_Newton> +1 to AWK
<Glenda> scribe: Glenda
<steverep> How does that change somehow for 3.0? The constraint will stifle progress.
<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
<Zakim> steverep, you wanted to remind that familiarity with WCAG 2.0 is the minority in the outside world
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.
<scribe> Scribe: 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.
<alastairc> We could easily maintain a mapping for the 0.01% of people who know the numbers, and track merges/changes.
<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.
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.
<JF> disagree Josh, legislations know the numbers, tooling uses the numbers, conformance claims use the numbers
<Joshue108> ack gower ack gower
<JF> AWK seems to me I tried to raise this issue about 12 months+ ago/ AWK seems to me I tried to raise this issue about 12 months+ ago
<MelanieP> Are we unnecessarily conflating two different topics: 1 - merging new SCs and old SCs and 2 - changing existing SC numbers?
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.
... if there are things we can merge, to clarify that would be
good.
David: I am on the opposite side
of what Mike was saying. I memorized the numbers. But not many
people have those memories.
... 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.
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.
<Alex> I think I have a solution
<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
<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.
<gowerm> +1 Steve
<JF> -1 steve
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.
Ales: adding IF WCAG 2.0 THEN statements (only where necessary)
Josh: I don’t hear a consensus. This will need more discussion.
RESOLUTION: Leave this open. Needs more discussion.
<Joshue108> https://www.w3.org/WAI/GL/WCAG20/implementation-report/
<AWK> Going to suggest that we might need more feedback on the survey...
<Joshue108> https://www.w3.org/2002/09/wbs/35422/WCAG21_impl/
Joshue: should we follow the same process or modify the process? Not seeing many responses. Please answer the survey.
RESOLUTION: Leave this open. Will discuss after more have answered the survey next week.
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.
<AWK> https://github.com/w3c/wcag21/issues?q=is%3Aopen+is%3Aissue+label%3A%22AGWG+Work+item%22
<lisa> I need to drop now.
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.
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
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.
<alastairc> can we ask questions of external people to clarify, before an official response?
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)
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.
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.
trackbot, end meeting
This is scribe.perl Revision: 1.152 of Date: 2017/02/06 11:04:15 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: Irssi_ISO8601_Log_Text_Format (score 1.00) Succeeded: s/folio/Foliot/ Succeeded: s/Kathy/Katie/ Succeeded: s/msg/ AWK seems to me I tried to raise this issue about 12 months+ ago/ Default Present: AWK, KimD, Joshue108, shadi, Roy, jasonjgw, MichaelC, Mike_Pluke, Brooks, JF, Makoto, Greg_Lowney, Kathy, Katie_Haritos-Shea, david-macdonald, Melanie_Philipp, lisa, Glenda, Laura, alastairc, steverep, MikeGower, Pietro, chriscm, JakeAbma, kirkwood Present: (no one) KimD Joshue108 shadi Roy jasonjgw MichaelC Mike_Pluke Brooks JF Makoto Greg_Lowney Kathy Katie_Haritos-Shea david-macdonald Melanie_Philipp lisa Glenda Laura alastairc steverep MikeGower Pietro chriscm JakeAbma kirkwood Regrets: Bruce_Bailey Chris_Loiselle Detlev_Fischer EA_Draffan Jake_Abma James_Nurthen Jan_McSorley Found Scribe: David Found ScribeNick: DavidMacD Found Scribe: Glenda Inferring ScribeNick: Glenda WARNING: No scribe lines found matching previous ScribeNick pattern: <DavidMacD> ... Found Scribe: david-macdonald2 Inferring ScribeNick: david-macdonald2 Found Scribe: David-macdonald3 Inferring ScribeNick: david-macdonald3 Found Scribe: Glenda Inferring ScribeNick: Glenda Found Scribe: Glenda Inferring ScribeNick: Glenda Scribes: David, Glenda, david-macdonald2, David-macdonald3 ScribeNicks: DavidMacD, Glenda, david-macdonald2, david-macdonald3 Found Date: 12 Sep 2017 Guessing minutes URL: http://www.w3.org/2017/09/12-ag-minutes.html People with action items: WARNING: Input appears to use implicit continuation lines. You may need the "-implicitContinuations" option.[End of scribe.perl diagnostic output]