See also: IRC log
<AWK> +AWK
<AWK> Scribe: Ryladog
<Rachael> scribe: Rachael
<AWK> Scribe: Rachel
<AWK> Scribe: Rachael
Reminder for TPAC registration. Will fall in a timeframe when we will be reviewing taskforce content and drafting 2.1. We are laying the groundwork but the meeting in Portugal in Sept will let us talk to people in person. If you can get there, that would be helpful.
<KimD> + KimD
Katy: I will provide a list of about 30 hotels for TPAC that she researched to the email list.
Andrew: This is approved to go out but will likely go out today for public review. Expect that as we get comments, we will have a survey and will need to approve responses to the comments and implement needed changes. Still on track for 2nd week of Sept techniques and understandings.
The numbering has become an issue for the mobile task force. Specifically how do we change exisitng success criteria? If we make a change to an exisiting SC, do we renumber it?
John: We collected a number of different options and proposals. We didn't get a lot of feedback but noone really went in and added a lot of information. We went through the different models. First is a four tier system but there was concern about the string of numbers.
<JF> 3.1 Readable 3.1.1 Language of Page A 3.1.2 Language of Parts AA 3.1.2.1 New COGA AA 3.1.3 Unusual Words AAA 3.1.4 Abbreviations AAA 3.1.5 Reading Level AAA 3.1.6 Pronunciation AAA
John: There was a concern about
keeping the numbers grouped by A, AA, AAA level.
... The only way to fit a new criteria in and retain the
ordering by levels would be to add a new number. There were
concerns about affecting tools or implying that the new
criteria are subsets or less important.
... The second model which is the one that had the most
positive feedback was that we would add new criteria at the end
of each list. Previous discusion that the numbers did not
originally aim to line up with principles, there is a strong
desire to keep them that way.
... A new criteria would be added to the bottom and the
severity would be noted but not used as a filtering
method.
... The next proposal would be similar to proposal 3 but then
the principles would be reordered to retain the level. There
was pushback and confusion to having the numbers out of order.
I agree that presenting an ordered list that is out of order
adds cognitive load.
... There was another suggestion to renumber the criteria. This
was based on severity level but this causes challenges in
backward compatibility and introduces the four level numbering
system.
... The final suggestion would be to remove the numbers but we
have become accustomed to the numbers.
... Kim made the suggestion to look to legislative approach for
renumbering. It may be worth growing the WCAG numbering system
in a way that works with the legislative approaches. In the
legislative world, when there is a new item, they add a new
number.
Concern is where the modifications of existing success criteria. There are a few different patterns that use additional numbers or letters, but the additional number or letter is not separated with a dot.
So if a new item was added to 1.3 but it was very similar to an earlier prinicple, it would be 1.3a or 1.31
There are other patterns but it makes it difficult to find. Another point is that the numbering is important when it comes to citation. Again legislators and lawyers are familiar with this model. My personal preference is to use a modified version of model 2 where new items are added at the bottom but revisions and clarifications are added as 1.1a etc
Katy: A correction that the numbers did align with the principles purposefully. Not that it is always a perfect mapping but it wasn't easy and was very intentional.
<Ryladog_> +1 for Model 2
David: I support the motion. Model 2 makes the most sense to me. I think it will work well.
Mark: I also support Model 2. Most folks I work with daily don't realize the SC are ordered by level. Keep the numbering the same.
John: I modfied the wiki page to
bring home the fact that enumeration by severity level will not
be a key piece. We might consider that if and when we have new
criteria added, that the new items be ordered by
severity.
... It would provide an implied, visual queue on the starting
point for 2.1
<Zakim> AWK, you wanted to discuss changing SC text directly. We haven't decided clearly against this yet.
Andrew: We haven't actually decided as a working group that we will not change the text directly. What I've heard you say, indirectly, that none of these options allow us to chang the text. Did you hear a strong concern that existing criteria should not change.
<Joshue108> -q
<Ryladog_> I agree to not changing the text of a 2.0 SC in 2.1, but rather make a new SC
John: I didn't hear a clear statement that no text shall change but I think there is a concern. There was no explicit statement.
Rachael: Are we editing exisiting critieria?
John: Concern about the term "audio description" which is older technology but I would add a clarification rather than changing the exisitng text.
<Lisa_Seeman> there already is
<Lisa_Seeman> a proposal to change a wording of a sc
David: I support the idea of adding a, b, c for clarifications as long as it is a subset of an exisitng criteria but I would like to discuss what to do when there is a change to the text.
John: In the proposal, a change would be a 1.3.1a instead of a change in the text itself. Is that correct Kim?
Kim: In the legislative world we make changes to the text all the time within the number. The a after a number would indicate a new section is a closely related section to the one above it.
Andrew: So are suggesting that if we edit text, we change the 1.3.1 or add a 1.3.1a?
Kim: If you want to change the
text in an exisitng statute, it would be a change to the text
in the statute and track the changes.
... Its hard to explain clearly. You'd have the text then
<<++Text change>>
<KimD> <<++ apple ++>>
<KimD> << -- apple -->>
Kim: The changes are marked as additions <<++ text ++>> and subtractions << -- text -- >> in the document as it moves through the process but then the final document only shows the change.
<JF> 1.2.3 <<-- Audio -->> <<++ Video ++>> Description or Media Alternative (Prerecorded): ...
Kim: The document with changes tracked is stored for reference and every change is available.
Andrew: The argument against changing text is that people who are familiar with 2.0 will need to know that 2.1 is different.
<Ryladog_> Again, I agree to not changing the text of a 2.0 SC in 2.1, but rather make a new SC
<JF> +1 to Katie's points
<Joshue108> +1 to staying close to what was done in 2.0.
Rachael: Supports changing the text if needed. I agree there are a lot of issues but avoiding changing text limits the ability to make needed changes.
Katy: Believes that text should not be changed. There are too many backward compability issues. Changing text should be held to 3.0
<Makoto> +1 to Katie to not changing text in 2.0
<JF> 1.2.3 Audio Description or Media Alternative (Prerecorded): ... >>> 1.2.3a Video Description or Media Alternative (Prerecorded): ...
Greg: I support model 2 of changing exisiting SC and adding new SCs to the end. Then we could use the legislative model of adding a letter to indicate a replacement of a 2.0 SC. We would delete 1.3.2 and then provide the new text as 1.3.2a. If in the future it changes again it would be come 1.3.2b
The letters would be a versioning of the SC. This is similar to the software world stating its not a whole new version but a minor update.
Greg: I'm not advocating for that specifically but suggesting it if there is a lot of concern about changing existing SCs.
John: Greg makes some good
points. Can we find a balance between what software engineers
expect and legislators expect? Both groups look at our work
with different lenses. Some existing SC need to be broken apart
to better support testing. We need a balance between being too
verbose and too specific.
... Two numbering concerns: How do we record a change to
exisitng text and how do we split apart exisitng issues.
<JF> Huge -1 to "retiring" any SC in WCAG 2.1
Kathy: We do not have the rapid change cycle that software does so we need to be more careful and that may not be a better model. We have human rights legislation referring to us. We may need to wait to 3.0 to make bigger changes. I think changing the text complicates the issues vs. adding a new success criteria that might include both and sound redundant. We have a limited number of interaction models.
The mobile group has been circling on thi sa while. We are dealing with multiple interaction models and working with how this all fits in. I think its important to think about 2.1 and also 3.0 so that it all fits together. If we pick a model for 2.1 like 2.1a and 2.1b it might be an easier way to let people know how everything relates and fits together.
In some cases, there are going to be mulitple techniques (keyboard and touch) both of which are needed.
<Zakim> JF, you wanted to say that I don't see multiple techniques to satisfy a single SC is a problem
We need to look at interaction models as a hard example to figure out how to fit it together.
<AWK> Also, some techniques already require other techniques
John: I don't have a concern about mulitple techniques being "required" (used cautiously). I don't think it is a bad thing. Abstract example: Make a delicious breakfast includes techniques for toast, eggs, etc.
Andrew: I take the point that pracitcal examples are helpful. can you provide one?
<AWK> For example, current 2.1.1:
<AWK> 2.1.1 Keyboard: All functionality of the content is operable through a keyboard interface without requiring specific timings for individual keystrokes, except where the underlying function requires input that depends on the path of the user's movement and not just the endpoints. (Level A)
<AWK> replacement: All functionality of the content is operable through a keyboard and similar non-pointer input interfaces, without requiring specific timings for individual interactions, except where the underlying function requires input that depends on the path of the user's movement and not just the endpoints. (Level A)
Kathy: the wiki page takes the exisitng success criteria and trying to modify them. This is based on the comments we received to touch and pointer.
Andrew: There are a few changes in there.
Kathy: Exploiring if we could change 2.1.1 instead of creating redundant criteria.
<jeanne> https://w3c.github.io/Mobile-A11y-Extension/
We have these in mulitiple formats right now. The next example shows the criteria broken out.
<jeanne> https://w3c.github.io/Mobile-A11y-Extension/#touch-and-pointer
Katy: In my mind all along, adding new guidelines was a better approach. Why did you feel it was not a good idea?
Kathy: Because we kept repeating the same thing over and over. In the past people have preferred each method. If we break them out, it starts to get complicated as you add input methods. We could end up having a very long list.
Katy: we need to look at the work from all of the taskforces.
Andrew: Katy, so you favor adding new criteria instead of changing the existing criteria.
<Lisa_Seeman> is anything here relivent if people have not looked at the proposed sc
Katy: I think adding some of these below the exisitng criteria.
<Ryladog> more SC can make WCAG clearer
David: The mobile task force
conversation is active and passionate trying to find the best
way forward.
... There are pros and cons on each side.
<Ryladog> John = David
Andrew: Part of the challenge is that all the taskforces are looking for this direction.
<davidmacdonald> +1
<Zakim> JF, you wanted to ask if adding a sub-section here might work? EG: 2.1.2 No Keyboard Trap: >>> 2.1.2a No Touch Trap
Katy: What we used before the numbers was keywords and then we added the numbers. The taskforces could focus on gathering the information and then we can work on the organization.
The challenge is that its difficult to write the SC without knowing the organization.
<AWK> ak lisa
John: I had proposed to Kathy about doing the no touch trap. I agree with Katy that the WG should be pushing the direction, the task forces need to get the direction now because its slowing things down.
Lisa: I think for next week its more important to get the guidance for writing Success Criteria rather than the numbers. Once you have the success criteria it may be easier to look things up. I think there is a reality that folks are not doing AAA so we may want to focus on A and AA which people are doing and then push AAA to the bottom.
Also be aware of is that we may request a change of level.
We also have a suggestion to change the wording of some success criteria.
<Zakim> jeanne, you wanted to say that a long WCAG is a concern for acceptance. I think we need to consolidate where we can.
Another thing, in terms of COGA success criteria, some fit under exisitng guidelines but some things you could make new guidelines for. Some would be strange that they would not be under an existing guideline.
Jeanne: Want to add about industry acceptance of 2.1, if we come forward with a 2.1 that is a significant increase over 2.0 so I think that if we can expand the scope of exisitng criteria, we should do so.
<KimD> +1 to keeping text compact/integrated as much as possible
<Ryladog> +1 to AWKs sentiment
<davidmacdonald> +1
<Joshue108> +1
<JF> +1 to AWK
Andrew: Based on what I'm hearing, model 2 is favored. Relating to changing success criteria, I think we should ask the task forces to write the success criteria so that they do not change the exisitng criteria. They may be redundant but then we get the text here and we can gather everything together and can evaluate changes in a single place.
<laura> +1 to AWK
Andrew: Then we can evaulate changes with the full context of possible changes and a new success criteria.
<KimD> +1 to AWK
+1 to AWK
Katie: I think its a great idea. We did something like this. When it comes down to taking the information and numbering and bringing it all together, we had a 4 day face to face meeting. We should look at that in about 6 monthos from now.
Kathy: So we are writing separate but are we writing a 2.1.1a or a new number?
Andrew: are they different if they are 2.1.1a vs 2.1.12?
Kathy: It could be. Perhaps we just do it separate and do it later. It should make sense on its own
There are inter-relations and it could have an impact.
<Joshue108> Correct
David: I support the approach and by december we should ideally have all the success criteria and then from December on we work on consolidating. That way the task forces don't spend a lot of time that would need to be redone when another task force has something specific.
Katie: I've never heard concerns about WCAG being too long. The understanding is long but the complaint I hear is it needs to be clearer. I don't think longer will be an issue.
<Kathy> that was Katie talking
Andrew: Do we have concensus on model 2? It sounds like we have consensus about all SC being separate but I will write it up and we can discuss it on the list. Hopefully we can have that clear before thursday when the next mobile call occurs.
* Thank you for the corrections.
Andrew: Key question is whether there is a difference if a success criteria is adjacent to an exisiting SC vs being alone.
<AWK> trackbot, end meeting
This is scribe.perl Revision: 1.144 of Date: 2015/11/17 08:39:34 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/John: The mobile task/David: The mobile task/ Succeeded: s/John: There are pros and cons/David: There are pros and cons/ Succeeded: s/Kathy: I've never heard concerns/Katie: I've never heard concerns/ Found Scribe: Ryladog Found Scribe: Rachael Found Scribe: Rachel Found Scribe: Rachael Inferring ScribeNick: Rachael Scribes: Ryladog, Rachael, Rachel Default Present: AWK, JF, Joshue108, Rachael, Makoto, Lauriat, Kathy, Laura, Greg_Lowney, lisa, adam_solomon, marcjohlic, KimD, Katie_Haritos-Shea, MichaelC, jeanne, moekraft Present: AWK JF Joshue108 Rachael Makoto Lauriat Kathy Laura Greg_Lowney lisa adam_solomon marcjohlic KimD Katie_Haritos-Shea MichaelC jeanne moekraft Davidmacdonald Regrets: Mike_Elledge Found Date: 19 Jul 2016 Guessing minutes URL: http://www.w3.org/2016/07/19-wai-wcag-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]