Accessibility Guidelines Working Group Teleconference

12 Sep 2017

See also: IRC log


(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
Bruce_Bailey, Chris_Loiselle, Detlev_Fischer, EA_Draffan, Jake_Abma, James_Nurthen, Jan_McSorley
David, Glenda, david-macdonald2, David-macdonald3



<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

1) New SCs - To Merge or not to merge? Survey https://www.w3.org/2002/09/wbs/35422/SC_merge/

<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.

2) Implementation testing process - (https://www.w3.org/2002/09/wbs/35422/WCAG21_impl/).

<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.

3) Responding to comments: Sharing the workload (Github comments and responses).

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

Summary of Action Items

Summary of Resolutions

  1. Leave this open. Needs more discussion.
  2. Leave this open. Will discuss after more have answered the survey next week.
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.152 (CVS log)
$Date: 2017/09/12 16:27:32 $

Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]
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]