<AWK> +AWK

<AWK> Scribe: Lauriat

<steverep> +steverep

WCAG 2.1 requirements

<laura> + Laura

<Joshue108> https://www.w3.org/WAI/GL/wiki/WCAG_2.1_Requirements_Draft

<AWK> Extension requirement from earlier in the year (http://www.w3.org/TR/wcag2-ext-req/)

Josh: Taking up the WCAG 2.1 Requirements Draft, based on the extensions document and bits of the 2.0 document. Linked above

JF: How extensible are we around success criterion not being worked on today?

<JF> https://www.w3.org/TR/media-accessibility-reqs/

Josh: If you see something that comes out of the MAUR, do bring that up. Link?

<AWK> MAUR = Media Accessibility User Requirements

JF: Other question: what's the process by which we'd propose things in advance?

Josh: On-list, pull request, all of the above.

<Zakim> AWK, you wanted to say that we should clarify the requirements first, the process second

AWK: Should focus on what requirements we have, rather than how to meet those requirements. Focusing on the first part.

Josh: Not a bad idea if you want to go through that now.

AWK: Drawn from the WCAG 2 extension requirements, so familiar to people here. Can pull out the major points in there and make sure we agree on those.

<Joshue108> https://www.w3.org/TR/wcag2-req/

Josh: When talking about WGAC 2.1, talking about .X in general. .X requirements must satisfy existing requirements, linked here.
... Work we do in 2.1 will by default satisfy those. If we need to diverge from those for some reason, that may likely go under 3.0 work. May mean something bigger that needs addressing.
... Trying to keep .X requirements as tightly mapped as possible to 2.0. Agreed a good idea?

<AWK> WCAG 2.0 requirements:

<AWK> Ensure that requirements may be applied across technologies

<AWK> Ensure that the conformance requirements are clear

<AWK> Design deliverables with ease of use in mind

JF: Yes.

<AWK> Write to a more diverse audience

<AWK> Clearly identify who benefits from accessible content

<AWK> Ensure that the revision is "backwards and forward compatible"

<Zakim> jeanne, you wanted to ask about definitions

Jeanne: Where do definitions fit?

Josh: Concerned about including that in the 2.1 scope. If you want to spearhead that, do feel free to.

Jeanne: Dealing with such an old definition of web content, really. Don't want to hold off on updating for another five years.

Josh: Do bring it up on the list, though, we should start talking about that.

<Zakim> JF, you wanted to ask about "shifting" SC from AAA to AA - will we be able to do that?

Jeanne: Will do.

JF: Moving current AAA success criterion to AA criterion, thought on including this?

Josh: Thought to include this in the extensions, but moving away from that to 2.1 work. Not really sure of the mechanism to do so, honestly.

Michael: Seems within scope of 2.0 to 2.1.

Josh: What about moving AA to A?

<Joshue108> -q

<Joshue108> +q to say criteria for moving SC levels may need to be based on testability or other metrics

Michael: I think we can make any changes around that we'd want to. If we'd move 5.1.10, it may result in renumbering, which would complicate things (administratively). Not a reason not to do it, just something to keep in mind.

JF: To Michael's point, this is why I originally proposed another dot, extending it in a different direction.

<Zakim> AWK, you wanted to say that definitions need to be part of the 2.1 work

JF: Contrast historically has only applied to text, but with icons, the iconography exists as a kind of language, so how would we add something like that to 2.1?

AWK: Related to John's earlier question around changing the level. I agree we'll have challenges around that, but we shouldn't allow that to keep us from considering it. In moving something from AAA to AA because something is now testable or no longer experimental as in 2008, we should address that, and then decide how best to represent that.
... To the earlier definitions point, I don't think we can do a 2.1 without addressing existing definitions. As long as we don't weaken the definition and we still have the ability to meet 2.0 based on those, we're okay. The definition of web content as applied to older criterion, we'll need to handle carefully.

Jeanne: Agreed, but we need to handle it.

AWK: It may expose what we can't handle in 2.1 and may need to wait on 3.0 for it.

<Zakim> Joshue, you wanted to say criteria for moving SC levels may need to be based on testability or other metrics

Jeanne: We need to at least try.

Josh: We need criteria for moving success criteria. Success criteria must be testable.

JF: Difference between testable and machine testable, correct?

<AWK_> AWK agrees that testable includes but does not require machine testing

Josh: We should include this in the definitions, now that you mention it. Problems with subjective and difficult to measure success criteria. The only way to stand by decisions to move success criteria are to have a set of criteria for moving them.

Katie: For color contrast, we definitely need a new success criterion, for interactive controls, icons, and such. I agree that definitions need to be in scope for 2.1 and that we need to move things around (putting visual focus in A).

Josh: Could we remove a success criterion?

Katie: Sure. Example?

Josh: Abstract example: say an existing criterion isn't great and everyone agrees, could we decide to remove it?
... Changing context from monster mega-menus, maybe.

Katie: I wouldn't prioritize removal of success criteria.

Josh: 4.1.1, meaningful sequence, what is the purpose of that?

Katie: Whether you use ARIA correctly, what is the point of that?

<Rakesh> How about consistant identification and consistant navigation

<jon_avila> Just saw an issue with 4.1.1 where input field contained inner text that messed up accessibility API -- so issues in 4.1.1 do affect AT

<Ryladog> Jon Avila - I do completely agree.

Andrew: In order to have things backward compatible… Example: 1.3.1. Delete it, break it apart, but ensure we don't forget something. Maybe keep that in place and have an additional dot level. Another case: 4.1.1, where something else already covers the success criterion.

Josh: When you've something that already covers a success criterion, that makes things easier.

<Zakim> jeanne, you wanted to give the example of changing "No keyboard Trap" to "No Navigation Trap"

<Ryladog> +1 to Jeanne

<allanj> +1 to Jeanne

Jeanne: Wanted to give the example from the Mobile Task Force, expand the context: "No keyboard Trap" expanded to "No navigation trap" to include touch. I want to have that in scope, but have boundaries on the scope change, otherwise, we might as well call it 3.0.
... I think Andrew said accounting for a broadening of technologies would cover it reasonably.

Josh: I like that.

<Ryladog> +1 to David

David: I'd like to see in 2.1 attention paid to dynamic content, things like aria-live, how do we handle injected content and when would we require that to be announced.

Katie: Agreed. In cases where we need to make it a "No navigation trap" I agree. For the cases brought up for possible movement, I think we should add numbers, rather than moving numbers.

<AWK> Let's not argue the meaning of SC now...

Katie: I don't think we should remove anything, including 4.1.1.

Josh: Incomprehensible to devs, though. What does that mean? My point: that needs improvement.

Katie: Absolutely. Don't call it some other number, but improve the language itself.

JF: I don't disagree with that, but we need to account for backward compatibility. We can't change the language.

<jeanne> +1 James

James: What's great in one situation may prove terrible in another situation, so we need to be very careful with this. With touch, what happens when voice comes in more? We need to stay away from becoming too prescriptive.

(Thanks!)

<Rachael> +present Rachael

JF: Talking about adjusting the level or what have you, right now, the numbering follows A, AA, and AAA. What happens if we want to add a new AA at 3.1.7 (for example)? If new, we break the pattern? We either add a new x.x.x or we can add a x.x.x.x.

Josh: Language can include meeting the parent.

(Very much appreciated!)

<Zakim> MichaelC, you wanted to say we probably need requirements for 2.1, and think they should be conservative

<jeanne> +1 Michael for scoping 2.1 carefully.

<Joshue108> https://www.w3.org/WAI/GL/wiki/WCAG_2.1_Requirements_Draft

Michael: A little off track, but we need to write some success requirements for 2.1, so we can figure out what's in scope for 2.1 vs. 3.0. We should remain conservative in our requirements.

AWK: Definitely. Anyone feel like backward compatibility with 2.0 shouldn't be a requirement for 2.1?

Katie: One way to avoid breaking that: adding a new success criterion as opposed to changing an existing one.

AWK: Yes or no for a requirement?

Katie: Good way to go, but sometimes we may need to add a new one to not change the old one.

Josh: We shouldn't have backward compatibility prevent us from fixing things. We have criteria too difficult to understand and follow today. If we need to break backward compatibility, I think that's fine.

<Zakim> AWK, you wanted to say backward compatibility SHOULD be required unless we are going right to 3.0. We can wriggle out of that restriction after 2.1

David: I want things that worked before to remain accessible. We all agree landmarks are a good idea, but we can't add that due to backward compatibility. We definitely don't want to constrain ourselves with backward compatibility when we can improve things.

AWK: Concerned from administrative perspective. I think we need guardrails to keep 2.1 on track. Talking about putting a document out for review in a year, if we say anything's up for grabs, that'll make it more difficult. More substantial work, we could say would come in 3.0. We should include some guidance for 2.1 in order to keep things manageable.

Josh: To what degree should we constrain things by the past? Legacy user agents, for example. We should have the ability to do the new thing for now.

<JF> +1 to AWK

AWK: If we want to have new success criteria, we can say to meet 2.1 you have to do more. You have to ensure that any structures of these types (x, y, z) would be required under 2.1. That's okay, because if you do it, you'll still meet 2.0. That doesn't worry me so much.

<Zakim> JF, you wanted to say that lawyers may not agree with Josh on Backward Compatability

Josh: A lot of that to me just sounds like techniques.

<AWK> +1 to JF comments

<marcjohlic> +1

JF: In terms of backward compatibility, I wouldn't want us to drop anything. That'd be a major concern for general council. Adding ARIA roles to 2.1 doesn't change 2.0, so going back and adding these things is a major reason for having a 2.1. If you don't add color contrast for icons (etc.), you're still 2.0, just not 2.1. I don't see backward compatibility as a restriction.

<allanj> spot on, +1 JF

<jeanne> +1 JF

<Rakesh> +1 JF

Marc: I see touch and things like that perfect for 2.1. If you want to meet 2.1, you need to meet those things, if not: still 2.0.

+1 JF

David: I don't see how we're disagreeing. (Laughs)
... I wouldn't want people to have this nostalgia for 2.0 and restrict 2.1 based on that.

JF: Not about nostalgia, but about conformance. 2.1 will only add to 2.0. Example: you could be conformant with HTML or XHTML and HTML, because of the backward compatibility.

James: If you write something conformant in HTML 5.1 it may not be with HTML 5, though.

Josh: Maybe we need to define what we mean by backward compatibility.

<JF> +1 to Makoto - we cannot "un-do" WCAG 2.0

Makoto: in any case, conforming to 2.1 should mean conforming to 2.0. If not, that could create problems. In Japan, that would cause major problems, so we should keep that in mind in terms of international requirements.

Katie: That speaks to how we can add things, but not subtract. No removal of success criteria. Does that make sense?

Makoto: Yes.

Katie: Thank you, that helps with the scope.

<Joshue108> https://www.w3.org/WAI/GL/wiki/WCAG_2.1_Requirements_Draft

<Zakim> JF, you wanted to ask Josh about architecture point

Josh: We could maybe start to think about 3.0 stuff, and we need to define the scope more clearly in order to have a path to build on, and then to 3.0 more easily. Talking about a .X release, after all. Other requirements beyond backward compatibility, need to discuss needs of users in multiple domains and the conformance model.

JF: You mentioned the architecture of this. WCAG 2.0, the numbering convention we have all follow A, AA, then AAA. If we add new success criteria, do we renumber, or do we add after the AAA, regardless of level? Agnostic, but I think we should answer that.

Katie: We should not renumber.

JF: All agreed, though? Do we need to ask?

Josh: This will go out for comment, important questions. We will look for consensus on this, the conformance model, all of it.

James: Similar to moving levels from AAA to AA, which can cause confusion.

Josh: I'd rather not change the structure, since people know the numbers today and wouldn't want that to change. Maybe in 3.0, but for 2.1, definitely not.

David: I share that. We'll probably end up with an extra dot. This whole issue of conforming alternative. In a mobile world, technically someone could say "I don't need to make my mobile site accessible because my desktop version is. That's the alternative." We need to close that hole.

<jeanne> +1 DMcD - conforming alternatives

<Mike_Elledge> +1

Josh: Please note that. What does it mean to have a conforming alternative?

<JF> This is why I keep coming back to "the extra dot" - for example currently we have (for example) 3.3.5 Help: Context-sensitive help is available. (Level AAA). If we were to advance this to AA in a WCAG 2.1, I would propose that we did it via the additional dot umber - i.e 3.3.5 = AAA @WCAG 2.0, and 3.3.5.1 = AA in WCAG 2.1

Rachael: In 3.0, I think we should revisit the numbering scheme, just so that we can avoid this when we eventually make it to 3.1 work.

<Zakim> MichaelC, you wanted to say this is another wide review question - policy wonks may care greatly, or not at all, how we number things - we need to explicitly ask

<davidmacdonald> maybe 3.3.5 (a)

<davidmacdonald> We could start adding letters???

Michael: Evaluators may care a great deal about that, so we should ask them when the time comes.

<Makoto> +1 to JF

Github working group issues walk thru.

New Success Criteria principles

Josh: Likely will go on, but I want us to think about success criteria requirements. Not clearly documented, so we need to think about this and work it out. Within the requirements draft document, a draft for success criteria requirements. Open for edits, comments, so on. Have a look at that. For editors on 2.0, how did you decide things for this?

<JF> msg/ AWK http://parkerhiggins.net/2013/01/writing-the-prince-symbol-in-unicode/

<JF> s/msg/ AWK http://parkerhiggins.net/2013/01/writing-the-prince-symbol-in-unicode//

David: Testability has to always apply. You have to scope things in and out of them. If too wide, you have to narrow it down. If too narrow, you have to expand it out. It is a real art to writing success criteria. That have to be technology agnostic, they have to always be true.
... It's a statement about what is. We tend to say "Don't do this" it should be a statement of what is. "There is alternative text for all images"

Katie: Right, it's a specific outcome. Then understanding how that can happen in more technical detail.

Josh: I like that. I've documented some of this in the requirements document.

<AWK> The most difficult issue will be how to handle the line between what is needed for PWD and what is needed for people in general.

Josh: Any other thoughts or comments from the veterans?

Katie: I think that covers it. We have to be really careful about what we put in it.

Josh: Makes me think about the principles behind universal design.

Katie: I don't think we should mix the two, as that can create problems for people with disabilities.

AWK: I think we'll have a much larger set from low vision and cognitive. In the past, where WCAG has said "Use simple language" this may pose problems for end users.

<Rachael> +1 to AWK

Katie: The awesome part comes from the studies coming out of the WGs. If there's evidence that support creates problems for people with disabilities, then that helps.

<JF> +1 to Katie - out of scope

Josh: Not just "this is a disability thing"

Katie: Not in our charter.

Josh: I end up saying "Do this because it's a good thing for other use cases" and I thought we could include that.

Katie: Good practice, but not in our scope and not our problem.

JF: When you need to get into abstract land and talk about things, I always bring up seniors, to make the point of a gradient, a range of impairment.

Josh: Please do post on-list about success criteria and such.

<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/undue/un-do/
WARNING: Bad s/// command: s/msg/ AWK http://parkerhiggins.net/2013/01/writing-the-prince-symbol-in-unicode//
Found Scribe: Lauriat
Inferring ScribeNick: Lauriat
Default Present: AWK, EricE, Kathy, Laura, jeanne, KimD, alastairc, JF, Joshue108, John_Kirkpwood, SarahH, Makoto, David_MacDonald, Mike_Elledge, John_Kirkwood, Greg_Lowney, kirkwood, MichaelC, Katie, Haritos-Shea, patrick_h_lauke, Elledge, MacDonald, Katie_Haritos-Shea, wayne, jon_avila, marcjohlic, Rachael, BM, Shawn, Lauriat, adam_solomon, Davidmacdonald, Shawn_Lauriat, [Steve, Repsher], JamesNurthen, Steve_Repsher, steverep, Sarah_Swierenga, Steve, Andrew
Present: AWK EricE Kathy Laura jeanne KimD alastairc JF Joshue108 John_Kirkpwood SarahH Makoto David_MacDonald Mike_Elledge John_Kirkwood Greg_Lowney kirkwood MichaelC Katie Haritos-Shea patrick_h_lauke Elledge MacDonald Katie_Haritos-Shea wayne jon_avila marcjohlic Rachael BM Shawn Lauriat adam_solomon Davidmacdonald Shawn_Lauriat [Steve Repsher] JamesNurthen Steve_Repsher steverep Sarah_Swierenga Steve Andrew Mike
Regrets: Kathy_Wahlbin Sarah_horton
Found Date: 31 May 2016
Guessing minutes URL: http://www.w3.org/2016/05/31-wai-wcag-minutes.html
People with action items: 

WARNING: Input appears to use implicit continuation lines.
You may need the "-implicitContinuations" option.