See also: IRC log
<AWK> +AWK
<AWK> agneda+ Thursday meetings
can someone privately pass me the password??? (I’m supposed to scribe!)
<interaccess> trackbot, start meeting
<trackbot> Meeting: Accessibility Guidelines Working Group Teleconference
<trackbot> Date: 19 September 2017
<AWK> Conference info for today: https://www.w3.org/2017/08/telecon-info_ag
<Detlev> I can't see a link to the Webex call on the page referenced in the invitation
<laura> I can’t joined either.
<Detlev> when I call up default webex and enter the meetuing number I get the message "Call doesn't exist or is over"
<scribe> Scribe: Glenda
<Detlev> I see the link in the IRC header but the page that is brought up does not have a Webex link in it
<lisa> michael sent an email just now with diffrent call in instuctions\
<lisa> you need to dial in :(
<david-macdonald> Netherlands https://test.medinfo.bayer.
<david-macdonald> Netherlands 08000235009
<AWK> https://www.w3.org/WAI/GL/wiki/Scribe_List
AWK: please volunteer to scribe.
AWK: We are restarting Thursday
mtgs for 1.5 hours. More opportunities to scribe on Thursdays.
We need a scribe as soon as this Thursday.
... Our regular WebEx mtg got cancelled an hour ago. So today
we had to have a quick switch over to an Adobe bridget. We
should be back on WebEx this Thursday. Sorry for the challenges
at the last minute.
<lisa> thanks for getting the meeting off the ground with the last minuet changes
<jamesn> http://www.intercall.com/adobe/ gives a not found.
AWK: reminder TPAC. Book your hotels and flights quickly.
<jamesn> What is the URL?
Go here to get the new bridge for today: https://www.w3.org/2017/08/telecon-info_ag
<laura> @jamesn you need to dial in
Jason: I agree with Michael that the numbers are an artifact of order listed in new version. No promise for stability. Might as well happen this time around.
Steve: I agree with Jason that the numbers are an artifact. I do like Laura’s idea of making them id numbers with characters. We owe it to the readers to explain how we are numbering and why.
<david2> tinyurl.com/jmo9st4
Brooks: Is it wrong to want it all? I appreciate the spirited debate on both sides. Frankly, I prefer a categorization scheme that both keeps the SC numerical ordering correct and like SC levels together. In some way, we'll need to adjust our approach to how we label SC a bit. I'm no expert in versioning labels, though. So, I'll defer to others on specifics.
<david2> http://tinyurl.com/jmo9st4
<Brooks_Newton> https://en.wikipedia.org/wiki/Software_versioning
Brooks: append with a letter to get it located in the correct place. See https://en.wikipedia.org/wiki/Software_versioning
Laura: I like the idea of prioritizing the short handles and de-emphasizing the numbers. More flexible. Put unique identifiers at the end fo the SC (de-emphasize the unique numbers)
David: I want to get the best of
both worlds if possible. Compromise if we treat AAA
differently. Propose that AAA Success Criteria don't have the
same level of association and entrenchment. If 8 of the 25 AAA
SCs were renumbered, our ordering problems would be
solved.
... Proposed Numbering Scheme - http://davidmacd.com/test/proposed-numbering-scheme.html
... the WCAG numbers should make sense based on an outline
structure.
... Steve really captured it when he said “if you change it to
an id instead of an outline. it has always been just an
outline."
Marc: Sounds to me a lot of other people reference by short name. But I’m used to referencing by number. That is why I was leaning towards a numerical order. I like David MacDonald’s idea.
<Zakim> bruce_bailey, you wanted to affirm that we agree that keeping the SC numbers stable is essential and to ask about four digit numbering in some cases
Bruce: In WCAG 2.1 you could keep
them together based on priority (not numerical order).
... have we had a call for consensus on preserving the number
and names?
... preserving number and names from WCAG 2.0 to WCAG 2.1 is a
high priority.
... I want to keep the same short names and keep the same
numbers on A and AA. AAA don’t need to stay the same. Or we
could go to a 4 digit scheme.
<Detlev> agree that David's suggestion would probably be the best solution
Bruce: 1.3.1 is such a kitchen sink. It needs to be broken down and having a 4 digit scheme would help us do that too.
AWK: But that is creating new SC. Not in scope for WCAG 2.1.
<Detlev> Isn't there enough work to do without taking apart 1.3.1??
Bruce: Maybe would could break down 1.3.1 in WCAG 2.2 or another future release.
Michael: I prefer sorting and renumbering everything to make sense for the spec itself as a standalone, but think I won't win that.
Kim: I think we need to do both. Keep levels together, keep numbers and names. Need to think outside the box. We can look at patterns to how we ammend laws by adding a 4 digit scheme.
<KimD> https://www.w3.org/WAI/GL/wiki/WCAG_2.1_SC_Numbering#Non-Specific_Feedback
jnurthen: do not support
renumbering any current SC. will cause immense confusion. If we
are going to renumber, we need to use a number scheme that
isn’t currently use in WCAG 2.0.
... vote for no changes in current SC numbers
<KimD> *We should also take into account the possibility of a WCAG 2.2, 2.3, 2.4
Joshue: be careful about how this will impact us if we go to WCAG 2.2. I like David’s idea that we don’t have to be as careful with AAA.
<bruce_bailey> James makes good point about (potentially) for example 1.4.6 being AA under 2.1 but AAA under 2.0.
<bruce_bailey> I thought I liked David’s proposal, but James’ observation has caused me to change my mind.
gowerm: we are going to have
problems making everyone happy. from usability perspective,
people new to learning WCAG benefit from a logical sequence. We
should find out how many tools are referencing AAA
numbers?
... I think David’s propoals is the most elegant solution.
<Detlev> Refresh survey results - votes have changed...
<Zakim> MichaelC, you wanted to say we shouldn´t disenfranchise AAA by saying ¨ok to renumber them but not others¨, nor should we assume if people have problems with renumbering they
MichaelC: very reluctant to introduce a new numbering scheme for WCAG 2.1
<Zakim> AWK, you wanted to ask what problems people anticipate if the levels are not together in WCAG 2.1
AWK: I’m not convinced about the need to keep the levels together. We can have a quick reference tool to filter for levels.
<Zakim> bruce_bailey, you wanted to say David’s proposal will not work
AWK: I prefer keeping the SC in numerical order
Bruce: people will refer to just the numbers. When people look it up, and get to the wrong version, they are looking at the wrong requirement. It will cause collisions and confusion.
<bruce_bailey> Section 508 will not be updating just because 2.1 is finalized.
bruce: numbers and short names need to be stable.
<KimD> *+1 - I totally agree with you Bruce
detlev: i’ve changed my mind during the call. the arguments are quite convincing. Do not change any current SC to a new number.
<Brooks_Newton> +1 to preserving current 2.0 Success Criteria numbers
<Joshue108> +1 to numbering being more important than levels for A/AA
detlev: just add the new SC at the end, with new numbers that have not been used before (no confusion or collisions)
<Rachael> +1 to preserving current 2.0 numbers
+1 to numbering being more important than levels for A/AA
<Greg> I agree with Bruce
<kirkwood> afree with Bruce as well
<kirkwood> afreee/agree
<KimD> -1 to changing numbers of any existing SCs in 2.0 for 2.1
<Detlev> Michael is right it would send a bad message to change the AAA numbers
<Zakim> bruce_bailey, you wanted to reply to mikeg
gowerm: AAA has a different level of scrutiny. I’m not persuaded that changes to AAA will cause significant problems.
<Detlev> Germany requires 2.4.8 location (the only AAA criterion)
Bruce: problem is peopel will go to the source documents and look up 1.4.6 in 2.1 but the end up in WCAG 2.0 and they look up the wrong information.
Brooks: preserve the 2.0 SC numbering. Not changing any of them, including AAA. Maintain the trust of stakeholders who have bought in to WCAG 2.0.
<Detlev> @ Shadi - no that is a BITV-Test invention which has recently been taken out...
<Zakim> MichaelC, you wanted to say we don´t have universal data about usage of guidelines, and can´t assume there aren´t users impacted by changes that concern us for higher levels
MichaelC: Will changing numbering of AAA cause problems? We don’t have universal information on how these SC are used. Great deal of concern about changing the numbering. Presumed promise of AAA numbering should be equally respected (as no change in numbering for A and AA). Let’s be consistent.
Rachel: Some people use a few AAA, so changes in the numbering would cause issues
<Detlev> vote in review has changed again a bit
AWK: challenging decision. I hear stronger concerns about changing numbering. Less concern over loosing grouping of levels (A/AA/AAA). Is that what y’all are hearing too?
<marcjohlic> agree - hearing more concern with changing numbering than grouping
<Joshue108> JOC: That sounded about right to me.
<Joshue108> JOC: but potentially worry about perception of AAA usage, if we do renumber.
<gowerm> +1 take a draft with the numbering preserved and see what happens
David: We are not going to get consensus. Let’s not vote anything off the island. Let’s pick a direction and continue to look for an elegant solution in the future.
+1 agreeing that AWK is hearing the same thing I’m hearing. Preference for not changing numbers between WCAG 2.0 and WCAG 2.1
<Kathy_> +1 for not changing the numbers from WCAG 2.0 to 2.1
<bruce_bailey> *Thanks David for taking a stab with a fresh approach
<Zakim> steverep, you wanted to ask why this has been approached from the direction of needing consensus to change rather than not change, and to make sure we are considering the value we
AWK: We can make a decision and request more feedback. We can revisit the decision if needed.
<lisa> just got thoughn off the call
Steve: Is there a reason why we’ve landed on tacking everything on? I’m concerned how this portrays WCAG 2.1 versus 2.0.
MichaelC: order of WCAG 2.1 currently was to drop them at the end of logical place where they belong. Now is the first time we are consideirng order changing.
AWK: I disagree, I think that adding them at the end was the least objectionable. And we knew we would revisit. We defered dealing with the question deeply until now.
<AWK> straw poll - keep numbers in order (new sc at the end): +1, mix the numbers to keep levels together: +2
<steverep> +3
<AWK> +1
<JakeAbma> +1
<allanj> +1
<gowerm> +3
<Detlev> +1 to keeping order and tack new ones to end
<KimD> +3 to keep both
<laura> +3
+1 (and have a tool for sorting by a different order)
<Kathy_> +1
<david-macdonald> +3
<MelanieP> +1
<Greg> +1 (which really means keeping existing numbers as IDs)
<Rachael> +1 for keeping numbers but not sure the new SC have to be at end
<Joshue108> +1
<marcjohlic> +1
<jnurthen> +1 to always keep old numbers constant
<Brooks_Newton> +3
<Joshue108> +q to ask would rearranging AAA help with this?
<marcjohlic> I'm OK with SC's not being grouped by level
james: can kim give us her ideas
Kim: I think all we really need
to do is decide - 1) do we want the number be the same 2) do we
want to group them by level 9and abandon the numbers0 3) do we
want to keep both - the numbers stay the same and the order is
grouped by level…we can do this with legal ammendment
patterns
... numbers for the new SC will likely be in a different
format. For example if we bring something in that belongs
between two current SC…it will need a new dot digit.
<marcjohlic> Wouldn't adding the 4th digit / decimal give them impression of the new SC being directly tied to the existing SC?
<Detlev> More than three levels really get messy - and convey the impression that the inserted ones are sub-criteria
<Brooks_Newton> +1 to Kim
<KimD> https://www.w3.org/WAI/GL/wiki/WCAG_2.1_SC_Numbering#Non-Specific_Feedback
<marcjohlic> +1 to Detlev
<Zakim> Joshue, you wanted to ask would rearranging AAA help with this?
<laura> Kim’s examples are at: https://www.w3.org/WAI/GL/wiki/WCAG_2.1_SC_Numbering#Non-Specific_Feedback
<Detlev> Preface all new ones with 'N' ? (for new)?
Joshue: AAA is not in legislation. So having a different option for AAA seems like it would not be a problem.
<Joshue108> Have we put to bed the AAA thing?
<gowerm> +1 to Kim. We are sooner or later going to have to remove an SC or breakup an existing one (or elaborate on it). Going to a 4 digit level for new ones is not a massive problem.
<Joshue108> yes!
<Joshue108> If we could move AAA to make a coherent ordering system I'm in favour of that.
AWK: let’s be consistent with AAA. MichaelC has good points on this.
<Joshue108> ok
<Joshue108> np
<Detlev> +1 to MichaelC's reluctance to discriminate against AAA SCs
<AWK> Glenda: when doing a lot of coding - the 4th digit might have a default of "00" to allow room to add items in
Glenda: could we proposed a 4th dot for each SC…and come up with a reasonable default .0050 for all WCAG 2.0 and the 2.1 can slide in where they need to bew.
<david-macdonald> I could live with that Text alternatives 1.1.1.0
<KimD> *Yes, we need to set up a scheme now to make potential 2.x updates work!
Glenda: Don’t allow anything to be closer than 20 points
<david-macdonald> Focus Visible 2.4.7.0
Kathy: I’m not opposed to adding new digits to exisiting SC. We do need to be careful if we left 1.3.1 as a SC…and added a 1.3.1.1 ….that would give a mistaken sub relationship. That would be bad. So all SC would need to have a meaningful number in the new dot number to show relationships.
<KimD> *I propose adding a note to explain the scheme - Kathy has a valid point
<gowerm> +1 Jason
jason: don’t agree with Michael’s concern about AAA. The fact that they are at AAA does that already. But to stabelize A and AA is meaningful based on the number of legal requirements that only refer to A/AA. I think we should hae more flexibility on how we handle AAA.
<gowerm> +1 to better architecting for silver
jason: decouple the numbering with a short character code for gropuing. Maybe we have to wait until silver.
AWK: short character code - could you clarify?
<steverep> Seems to be an extension of the outline to ID proposals, just with a different ID idea
Jason: you could assign two letters to each SC in the document. non-numerical. not in any order. try to make it based on short name. Very brief stable identifier. Decouple the number ordering. Move stable way of identifying SC by something other than numbering.
<laura> Yes. Prioritizing the short handles and de-emphasize the numbers.
+1 to what Bruce just said. WCAG 1.0 SC numbers cannot be confused with WCAG 2.0 and that is GOOD!
Detlev: agree with Katie that adding 4th level of numbering can be confusing and show heirarchy relationships. Jason’s idea would be better considered in silver. I think we should just add them at the end for now. And let Silver reshuffle.
<Zakim> bruce_bailey, you wanted to mention that, by design, wcag 1.0 checkpoint numbers are not confusable with wcag 2.0 sc
<AWK> +1 to Detlev
Bruce: by design, wcag 1.0
checkpoint numbers are not confusable with wcag 2.0 sc
... we could add .0000 to any current SC (then there would be
no confusion on relationshiop/heirarchy)
<KimD> *I think the question is whether we want to keep numbers, levels, or both from 2.0
<KimD> *Then after that, we can look at some options for how to do that. There are a number of patterns (please see https://www.w3.org/WAI/GL/wiki/WCAG_2.1_SC_Numbering#Non-Specific_Feedback)
David: pivot off my previous proposal, and jump on the idea of the 4th digit. Bruce just made a REALLY important point. Just looking at the numbers you can immediately tell what version you know which version is in play.
<Detlev> people WILL imply hierarchy even if we don't intend that!
But detlev, if 1.3.1 becomes 1.3.1.0050 and something that needs to go after that becomes 1.3.1.0075, that will not be implied.
<Detlev> Well the conformance level makes it crystasl clear they are NOT second-class add-ons
<bruce_bailey> Rather than adding a decimal, I was suggesting adding zeros to the last number
Marc: throw away numbers completely now!
<bruce_bailey> If the ID scheme changes too much, adoption of 2.1 will be slower
AWK: like Laura’s suggestion, push 2.0 numbers to the end, and create smart short names.
<Greg> ...numbers were not originally meant to function that way. (Personally, I try to always refer to SC by both ID and handle, e.g. 1.2.2 "Captions (Prerecorded)".) That said, maintaining numerical order in the document doesn't seem as important because placeholder cross-references to new, moved, or deleted SC can be included in the document as locations where people are likely to look for them.
AWK: Ask for a couple of people to volunteer to put together some models for us to review, much like David MacDonald did.
Kim: beyond what I already put together in that wiki?
AWK: this is good, but we need to
see it applied ot WCAG 2.1 - example of how it would look
... respond to more of the concerns in this call. Have an
exmaple of de-emphasizing numbers and adding short-names for
each. Have a mock-up
<marcjohlic> I'm willing to do that for what i suggested
AWK: the wiki is close to the mark, but needs a bit more
<Zakim> Greg, you wanted to say I don't believe we should change existing numbers. Having been through projects where numbering changed over time, it introduced a huge amount of confusion
<david-macdonald_> My current works as a model without SCs http://tinyurl.com/jmo9st4
Greg: do you want to defer this to another day/mtg
<KimD> I will work on fleshing out my examples
gower: anything other than these 4 points to consider: I heard several desirable things given: 1) a way to identify the new 2.1 SCs, 2) a need to scale later, 3) a need to preserve existing numbering, 4) a desire to group by level. Are there others?
AWK: Kathy wants to make sure we don’t implicitly introduce parent child relationsihps.
<KimD> *thx Mike
Greg: Need to keep direct identifiers that are not translated between natural languages
<Detlev> +1 to keeping a numerical id that can suffer translation
<marcjohlic> Marc is willing to create a brief model of what I suggested - dropping numbers altogether
<KimD> and I'll beef up my examples
David: volunteers to help gower, steverep create a model
RESOLUTION: leaving open
<bruce_bailey> If I have time, I will try and past something into the current wiki page
AWK: discussed last week. substantial issues related to merging SC. better to move forward with all new SC being listed as separate. No merging at this time. We hae a few that are kind of close. But we think we should not merge anything at this time. Seem reasonable?
jason: talking about merging and identifer - my two character code idea would solve all of this.
<AWK> Glenda: No merging
<Zakim> steverep, you wanted to ask if we can discuss this on a case by case basis instead
Steve: take this down a level to discuss what we need to merge.
Glenda - but Steve, for people who need to comply with WCAG 2.0 versus WCAG 2.1…any merging causes a problem. End of story. Don’t merge now. Merge in silver.
KimD: what do we mean by merge?
AWK: means changing an existing
SC from WCAG 2.0. So that SC would be different in WCAG 2.0
than it is in WCAG 2.1.
... Easier to deal with backwards compatibility if the SC does
not change.
Kim: replacing something is really tricky.
<laura> Would be easier to discuss specific proposals for merging SCs on a case by case basis.
Brooks: echo what Kim said. We
need to make it as easy as possible for people to understand
what is different between WCAG 2.0 and WCAG 2.1.
... need to understand the delta for training, for resourcing,
for costs - for organizaiton adoption. Need to know what is
new. Brand new hybrid thing where it is hard to figure out what
is old and what is new..that is confusing and inappropraite for
a minor version.
Rachael: prefer to have this conversaion on a case by case basis. are there any level changes between WCAG 2.0 versus 2.1? If so, we need to discuss this on a case by case basis.
Glenda: reminding y’all, this is a minor dot release…stop trying to change so much. Later gang. Later!
gowerm: please look at this on a case by case basis. Assume this is merging new SC with new SC..that is totally okay.
AWK: merging a new SC with a new SC, that is totally okay.
gowerm: we would need to be very, very careful about merging existing SC. we might want to consider it.
<david-macdonald_> This model leads with the handle. The numbers are now deemphasized to become IDs rather than Outline mode which is in 2.0. Practically speaking that means the IDs would probably move to the right side of the SC rather than being in front of the short handle. All the WCAG 2.0 SC 3s remain even the AAAs http://tinyurl.com/y9vat92l
<Rachael> Can we set a guideline that we want to avoid merging but not take it off the table entirely?
<gowerm> +1
+1
<marcjohlic> +1
<david-macdonald_> +1
<KimD> +1
<JakeAbma> +1
<bruce_bailey> +1 to maybe if it feels right
<Detlev> not sure
<KimD> Potentially we could talk about putting Graphics Contrast under 1.4.3 - in other words we could amend 1.4.3 to include graphics contrast. Is that "merging?"
Kim: ick…no!
<KimD> Thanks
<steverep> Can we just file the potentials merges/eliminations as issues and work them like anything else?
Kim - that is so complex…trust me…you don’t want to go there
jason: 2.1.1 and device sensors may really need to be merged
<Rachael> Glenda: do you want me to take over?
<KimD> +1 to Jason - Amending may make the most sense
+1 to what gowerm just said. Go with Rachael’s wording “set a guideline that we want to avoid merging but not take it off the table entirely”
+1
<KimD> +1
<gowerm> +1
<Rachael> +1
<marcjohlic> +1
<Brooks_Newton> +1
<Detlev> still not sure - sorry
<bruce_bailey> +1
<Zakim> steverep, you wanted to request filing issues
<david-macdonald_> +1
<laura> +1 to steve. case by case. File issues for proposals.
<gowerm> goal
RESOLUTION: set a goal that we want to avoid merging but not take it off the table entirely. case by case - file issue for specific mergings.
<lisa> i gt thoughn off again. should i call back in or is the call almost over\
<lisa> thanks
AWK: please review the rest of the agenda items, we need help/ volunteers to help with the open issues
<AWK> yes
awk: you can handle comments if they are from people who are involved in AGWG. If they are public comments…we tend to want to have discussion so we respond with a consensus response.
<laura> bye.
AWK: don’t forget call on Thursday. We should be back on WEbEx.
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/do not require mapping from WCAG 2.0 to WCAG 2.1/are not translated between natural languages/ Default Present: AWK, JakeAbma, jasonjgw, Joshue108, Brooks, MichaelC, david-macdonald, KimD, Greg_Lowney, Roy, Melanie_Philipp, Glenda, lisa, bruce_bailey, shadi, steverep, Laura, Kathy, Pietro, kirkwood, Detlev, MikeGower WARNING: Replacing previous Present list. (Old list: (no, one)) Use 'Present+ ... ' if you meant to add people without replacing the list, such as: <dbooth> Present+ AWK Present: AWK JakeAbma jasonjgw Joshue108 Brooks MichaelC david-macdonald KimD Greg_Lowney Roy Melanie_Philipp Glenda lisa bruce_bailey shadi steverep Laura Kathy Pietro kirkwood Detlev MikeGower Regrets: jon_avila JF Katie_Haritos-Shea Denis_Boudreau Crystal_Jones Mike_Elledge Chris_McMeeking Found Scribe: Glenda Inferring ScribeNick: Glenda Found Date: 19 Sep 2017 Guessing minutes URL: http://www.w3.org/2017/09/19-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]