<AWK> +AWK

<Lauriat> Scribe: Lauriat

<AWK> Scribe: Shawn

<AWK> Scribe: Lauriat

New SCs from Feb 7th https://www.w3.org/2002/09/wbs/35422/SC_20170207/results

SC Proposal: Graphics Contrast (Issue 9)

Josh: From the top, we'll talk about the SC proposal for graphics contrast.
... 18 accepted as drafted, some flagged as needing some changes.

<AWK> https://www.w3.org/2002/09/wbs/35422/SC_20170207/results#xq1

Andrew: Two surveys, starting here with the first, from the 7th.

Kim: I think I was concerned, as I wasn't sure how this would work with complex sites. As I said in the comment, I'm not really sure how this impacts zooming and complex sites.
... more that I didn't know the impact, rather than having changes in mind.

Josh: Any comments on that? (crickets)

<shwetank> All my comments are in stated in github actually

Josh: I don't think this would present any issues with adoption of this SC.

<Zakim> David-MacDonald, you wanted to ask Alestair can you comment on whether all the lines of the icon is it just the ouside or all of them such as a printer icon

<Glenda> See examples at github at https://github.com/w3c/wcag21/issues/9

David: That brings up a good point. If you have an icon of a printer with a circle around it, does this apply to the printer, the circle around it? What does the language of this suggest?

<laura> Alastair’s has responded to survey comments in the pull request: https://github.com/w3c/wcag21/pull/100#issuecomment-278184960

Glenda: The key to this one is: is that visual cue essential? Is the picture of the printer use to indicate that you can print? Is that the only part of that image that is essential to understanding it?

David: Okay, that makes sense. So it's not the circle around it necessarily, but the printer in the icon itself.

JF: A number of comments on the survey for editorial changes, but what's the next step?

<Glenda> Thicker = CSS Pixels

<Glenda> The browser-calculated value of pixels, which may be different from the physical device pixels. Browsers set the measure of 1px in CSS as closely as possible to that of the reference pixel, which takes into account the assumed viewing distance. For example, 1px on a TV display at 3.5m away is much larger than 1px on a phone 30cm feet away. The CSS pixels on a high-resolution screen create text and objects that are the same size as a low-resolution screen if they

<Glenda> both use CSS pixels.

<Glenda> Thicker = 3 CSS Pixels

JF: also, we're talking about things that are thicker, but there seems to be a lack of clarity here. Looking at the UI for the webex meeting center, with icons for the different actions, would the icons across the top of this pass in terms of thickness of the arrow and circles around the icons?

Josh: We really want to see whether these generally get over the line of being SC, first.

Glenda: Responding to Kim earlier, the definition of "thicker" of 3 CSS pixels as you can measure.

<David-MacDonald> PS i agree with Adam Zerner the threshold grey is #767676 not #777777

<laura> https://github.com/w3c/wcag21/pull/100#issuecomment-278184960

Laura: Alistair has responded to all of the comments on the survey and on the pull request as well. (linked)

James: Still having difficulties with the 3 CSS pixels side it. With the printer: some of it is thicker than 3 pixels, but some isn't. Would you then judge the icon as though that circle wasn't there?
... not sure that the 3 css pixels really works, though I don't know what really will.

Glenda: I think we can spend the whole hour and a half talking about this, so I think it'd be better to say: is it worthwhile to apply color contrast to essential images? Next up, do we need a SC for images that contain essential information that isn't text.

<jamesn> +1 to that

<MoeKraft> +1

<KimD> +1 to that - agree we need images to have a contrast requirement.

Andrew: Similar to James' question, thinking about images and having to introspect the images isn't clearly conveyed. How does this line up with other SC we'll have looking at specific sizes for images?
... in response to JF, I think in terms of the process for this, we have a pull request. If everyone says this is great, then we have a draft. If we have minor editorial issues, we can easily address those as well. We just don't want to discuss these for an hour. Will this take us more than ten or fifteen minutes on the call to address?

<Glenda> +1 - need a SC that requires color contrast in graphics that contain essential information (that is not text)

Andrew: if it'll take longer and we have more substantial issues (beyond editorial) that'll take longer than ten or fifteen minutes, then we should take it back for comments and move on.

JF: To Glenda's larger question around color contrast requirement for images, I'd say "actionable" images. If a button or wrapped in an anchor, as a call to action.

<AWK> AWK: Yes, "send back" is "work outside of call to address identified issues" not "reject"

JF: for other monochrome images, etc. where does the contrast need to be? For a photograph, I'd say the boundary should lie at the edges in contrast to surrounding background.

Mike: I heard Glenda's point that we should focus on. Also, has this developed enough for a FPWD? It doesn't need to be perfect, but good enough for a draft, and a process around that would help.

<Ryladog> +1 to last speaker

Josh: To that point, can anyone not live with this going to draft? Are we generally happy with this going into the editor's draft or not? That's what I want to do now. Anyone object to this going in?

Andrew: I think we need a little more time, I'm debating this, myself. I agree with the principle of this, but wary of the details.

Josh: We need to work out, is this going in the right direction?

<Zakim> MichaelC, you wanted to say ednote

Katie: This should definitely go into the FPWD, having this go in will help us define some of the issues that we need to work out. This is what we're thinking, do you see problems with this? That's the point of the FPWD.

<laura> +1 to Katie

<Glenda> +1 to what Katie and MichaelC just said (adding editorial notes)

Michael: Here's what we have now, but we see x, y, and z issues with it, we can have editorial notes like that in the FPWD.

<Ryladog> Thumb up for this one from me

<Zakim> AWK, you wanted to say that I would expect that we would have the editorial note in place for the group to approve

Josh: We need language right now, and we need the ability to say that we agree with the direction.

Andrew: If we go that route, I'd like to see the editorial language that we'd include in place. Even if the WG says today, we'll put this in, but we want to see that editorial language, that feels like a fair expectation.

<David-MacDonald> How about language such as: "The AG approves this draft sc for FPWD pending confirmation of editorial language

Josh: Do we want to say: resolution: the WG is positively disposed…?

Katie: I understand that the first thing we've put out in so many years has to be awesome! But we should drop some of the weight. We've skewed ourselves and I think we need to look at this as FPWD and that's it.

<gowerm_> +1 editorial must meet bar

JF: We need to have some kind of editorial "meets the bar" as we go through these surveys, because otherwise we might as well just put them all in the draft and go from there.
... Nobody disagrees that we need color contrast requirements for actionable images. But we need a higher bar and to address the comments and concerns that people have about these SC to whittle them down to something better.

<Glenda> How did they do this for WCAG 2.0?

<gowerm_> 18:6:1 for accepting, accepting with changes or needing more discussion. Speaks for itself.

Josh: Looking to do that now. Going through these now, "Three are awesome, two need more work." That sort of level. We'll have plenty more discussion.

David: I just dropped some language in there.
... I think we can just say something like that. We're eyeballing it, we know we need to do more work on it, and we have a year for that. We should just move forward with that. We have 65 SC to work through and a draft due in 14 days and CSUN in there.
... We should use that for our criteria. I think this one has good momentum, and we should move on.

Katie: How did we do this in 2.0?

David: We didn't have the same kind of pressure that we have here. We just published them when ready. The old way just doesn't work in the new charter.

<gowerm_> If we have a clear majority for accepting or needing more discussion, that should guide us.

Josh: Andrew, what're your issues particularly with this?

<gowerm_> 24:1 in favour of accepting!

Andrew: A bunch of issues were raised. With additional work, I think it could be ready, but I don't like putting it in as it is right now.

<Glenda> +1 to gowerm saying 24:1 in favor of accepting

<JF> disagree with the 24:1 measurement, I see 18 for, and 7 with some level of reservation, or roughly 30%...

Josh: Chair has spoken. This particular SC aside, we'll stick with the overall approach of substantial support for a given SC should indicate ready to go in. This particular one, it seems we've some substantial issues to work through before it's ready to go in.

<Glenda> Alastair has been the strongman on this one. He helped me understand CSS pixels.

Andrew: The concerns I have around this are not with the principle of it. I do think there's going to be some amount of testability concerns once we talk about graphics that are complex.

<Glenda> Think back to when color contrast for text was first proposed. I’m sure it was a lot to think about then too!

<Ryladog> There was

<Glenda> Remember when color contrast on text had to be done with a dropper?

Andrew: This may be talking about 40x40 pixels square, on the small end of graphics. Getting to larger images and graphics, there's more that has to be done. I've got questions about whether this is reasonable and achievable from that perspective. Clear enough, yes, in terms of a graphical object.
... I think it's close, but I would favor further review.

<David-MacDonald> +1

Mike: If we're talking when we have 18 agree, 6 agree with changes, and only one against, do we really need to go with the rest of this list? This is one of the higher ratios.
... Do we need to wait for everyone to accept before we discuss these?

Josh: It comes down to issues that are substantial, really.
... If I feel, personally, that it's a substantial issue, then I'll listen to that one person bringing it up and I think we should listen to that and discuss it.

Shwetank: I raised a few issues on that issue, and it seems Alistair will take those into account. Have those already been taken into account, or will they be fixed later on? He has agreed with those issues, but it isn't clear to me whether they'll be included now vs. later. If now, then thumbs up from me.

Glenda: I don't have enough in-depth knowledge to respond to that, but what did we know about measuring color of fonts before? I used to use an eye dropper, very laborious. We have some labor involved in this now, but it's mathematically sound.

<Zakim> AWK, you wanted to say that on thinking about this more with the discussion that I can live with this in the FPWD. I do think that it will require further edits, but expect that

<Ryladog> +1 to Glenda

<Glenda> change is good :)

<Ryladog> Yeah!! AWK

Andrew: The chairs we need to ask people and myself: can we live with this in FPWD? I don't think we'll see this exact form in the final wording, and I don't think anyone else expects that either, so I think with that I can live with this in the FPWD.

<Ryladog> Why dnt we vote now

<gowerm_> +1

<AWK> We haven't really used "voting" in the past.

David: Thinking about the overall process, I think we should move forward on this and we should have a threshold on the FPWD and work through the rest like this in order to get to FPWD on time.

Josh: We need a resolution on this. Michael, what kind of language do you suggest?

Michael: No magic suggestions.

<gowerm_> " Accept this SC into the Editor's Draft with concerns noted"

RESOLUTION: Accept pull request into editor's draft

Josh: Next one! Number two, interruptions.

SC Proposal: Interruptions (minimum) (Issue 47)

Josh: we have 15 thumbs up, four accepted with changes, and three more discussions.
... Make that 15 thumbs up, five accepted with changes, and five more discussions.

JF: I'm struggling to stay on top of this massive flurry. Reading all of the comments and everything in github, there were questions posed in the thread that I didn't see responses to.
... between visual users and screen reader users. AAA vs. AA vs. A?

<Glenda> Pull Request for this one is here https://github.com/w3c/wcag21/pull/98/files?diff=unified (and it is set to AA)

Mike: These comments are in the issue thread. What is an interruption? Do all four of those bulleted items constitute interruptions? Additional text unclear as to whether it goes into this SC.

James: Do they want the tooltip to come up? Unsure as to whether the examples all make interruptions.

Lisa: One of the comments - "emergency" is defined in WCAG. I would be happy adding an editor's note to clarify this around warnings. Maybe we should add warnings, if tightly defined.
... In terms of JF's comments, the comment itself: the background is that the COGA TF has struggled with the process overall, working out how to close things out after responding to a pull request.
... Maybe it does need some extra clarification? I don't think that comment sounded like someone had a substantive comment, it seemed like a next-stage comment.
... Michael's wording change, I'd okay with as well, if everyone else is.
... Tooltips. In terms of interruption defining, WCAG already defines it. Happy to define it, but I don't think that should hold us up. Because other places uses that term, though, others should also work on the definition, not just COGA.

<gowerm_> +1 jamesn

Lisa: In terms of tooltips, it is initiated by the user. For the sake of completeness, some people find tooltips stop them from using components. So, add a mechanism for disabling the tooltips. But these would come from a user-initiated action.
... If you're doing personalization, then include them. If not, then we consider them user-initiated actions.

JF: Thank you for that. I tend to agree with you, it really stems from a process thing. We have a number of SC coming to a state of maturity, managed in github, and then combined into a massive file and modified from there.
... These questions just kind of hang out there without a resolution. Maybe what we do: is this mature enough to move forward? A pull request happens, it still has questions, and they don't come along with the pull request.

<Glenda> +1 to concern about how to best manage these changes. all of these proposed SC dropping into a single file…is going to make this even more difficult to follow. Even in separate threads, this is very difficult for all of us to follow.

Lisa: We find it very difficult to follow all of these threads and the pull requests.

JF: You were right, the question raised wasn't a substantial issue, but I do want to make sure that we address all of them.

Josh: We're aware of the limitations and overhead of the new tools that we have, and I don't want to keep cycling around on process and tools.

Mike: I don't see a definition of "interruption" (I do see one for "emergency"), so I think we need that defined better.

<AWK> The Word interruptions was in 2.2.4 (AAA) in WCAG 2.0 (and only in that SC)

Lisa: That was in 2.2.4, and was originally in others as well. We can't really go back and make a definition. We've, in the pull request, tried to include wording around this.

<Glenda> Wow, Lisa has a point. Interruptions is 2.2.4 in WCAG 2.0 at https://www.w3.org/TR/2008/REC-WCAG20-20081211/#time-limits-postponed

<jon_avila> It would have been helpful to have input from broader group much sooner in this whole process

<marcjohlic> https://github.com/w3c/wcag21/issues/47

Mike: I don't see that, so please point that out. I don't see whether those bullets constitute interruptions.

<marcjohlic> https://github.com/w3c/wcag21/pull/98/files?diff=unified

<David-MacDonald> There is no deefinition in WCAG of Interruptions but it's in 2.2.4 2.2.4 Interruptions: Interruptions can be postponed or suppressed by the user, except interruptions involving an emergency. (Level AAA)

Lisa: Okay, I can see that the original wording had a lot more, but then we made it more concise, but need to explain "interruptions" in there.

<Ryladog> We can infomation that Interuptions needs to be defined after the FPWD

<Zakim> MichaelC, you wanted to suggest include files and / or branches

Josh: I think that's useful and reasonable.

<Greg> I'm not sure why an edit to 2.2.4 should be held to a higher standard than the existing version in terms of definitions. 2.2.4 is already "broken" in this regard.

Michael: Not to rathole on process, we can look at the editorial process. We could use and include files as ways of making it easier to have proposals in easier to maintain places.

<AWK> One reason is that AA SC were held to a higher testability standard in WCAG 2.0

David: I've put my comments in there, changed from needs more discussion to accept with changes. I think it needs editorial work, but they all need it. Just not sure how we can say "easily" in the SC.

<JF> +1 to vague terms such as "easier" "clearer" "common", etc.

David: How can a tester know what is possible ("as wide a scope as possible"), so I don't know how I can just that.
... That makes it hard to give them a level for "as wide as possible"
... "Where available" also falls into that testability question.
... More editorial things. We can move on with the first draft and handle those later.

Andrew: I'll resist talking about the process. No matter what we do, we'll have a lot to follow, and it'll be hard. We don't really have a way to make that easy.
... I share some of David's concerns, and would feel better if we just say "available" rather than "easily available" or "readily available"

<Joshue108> +1 to AWK

Lisa: Just going with "available" isn't good enough. If it isn't available to people with cognitive disabilities, then it isn't available.
... Just saying that the feature is available, but you need to know these keystrokes, then it isn't really available. It shouldn't be that every time you go somewhere you have to change this setting, but it has got to be easy to find and relatively quick to do.
... If there are interoperable settings, like browser settings, then that's the better way to do it. We could add those words. It does need explanation and clarification.

Andrew: The reason for my comment, too, is looking at the comment for "easily available" would allow your example of what shouldn't happen.
... Of course, I'd love to have this available at the browser level, but we don't have that, yet. WCAG applies at a page-by-page level.

Lisa: I'm comfortable saying that the definition needs work, but I'm not comfortable losing the word "easily" and then having obscure mechanisms available.

JF: I have a larger, overarching concern about these terms - "easier" or "clearer" or "simpler" - we need a way to measure that.

<shwetank> +1 to that

JF: We need something that a tester in Boston, Tel Aviv, etc. can each understand and measure, rather than an assumed definition.

Lisa: Not assumed, it's in the glossary and we need to clarify everything within there.

<Zakim> just, you wanted to say an interuption can be a phonecall, which can be diferent from an emergency Tornado warning...

Katie: Obviously there's levels of interruption (phone call, tornado). The other thing: measurable and testable today. All of this language is going to change. We know that we'll need to work on glossary comments. We need to point these things out, but we have a long way to go and it doesn't have to be perfect for the FPWD.

Josh: We do have a few things that we know now from this discussion, and this has more work that needs to happen.

<Glenda> Glossary definitions should be attempted now. We are doing it in LVTF.

<jamesn> exists but not defined......

<Wilco> +1 to Lisa's comment

Lisa: No, because we just need to handle the glossary terms.

<AWK> "easily" does not appear in WCAG 2.0

Lisa: I think it's a bad idea to push them back over glossary definitions.

<Glenda> “easier” only appears in the guidelines of WCAG 2.0. “easier” is not in any SC in WCAG 2.0.

<jeanne> +1 to work on glossary after we have a better idea of all the SCs that will use them

<jeanne> Lisa, I will help work on coordinating defintions.

<JF> +1 to Glenda's point - "easier" is a non-normative term

<Glenda> I’m very worried about the phrase “easily”…it looks like user testing to me

Josh: I think you're right, and overall this SC has been largely well-received. The question then: those issues notwithstanding, is there anyone who could not live with this being added to the FPWD based on what you've heard and what you know that Lisa knows needs doing from this initial draft?

<Ryladog> I can

<AWK> +1

James: I'm not happy with it going in as it is today, because I think everyone will have the same questions that we've already raised here and that needs clarifying before it can go in.

<Ryladog> -1

Lisa: Could we add in an editors note that we know that we need to define these things?

<AWK> I could agree with a note to indicate that we want feedback on whether we need a definition for interruption, but the easily piece is a blocker for me

Lisa: We could use the original wording within the editor's note, around "No content should be added…"

<Ryladog> +1

<jamesn> -1

<Lisa_Seeman> +1

<Wilco> +1

<David-MacDonald> +1

<jeanne> +1 for editor's draft

<MichaelC> +1

<laura> +1

<Joshue108> +1

<marcjohlic> +1 but would really like some examples of interruptions (what is what isn't)

<Jim_S> +1

<Makoto> +1

Josh: Could people +1 for adding and -1 for not adding to the editor's draft?

<kirkwood> +1

Andrew: Could you clarify what you're asking us now?

<JF> -1 until definitions have been clarified

Josh: Put in a ±1 for whether you want it added to the FPWD as it is today.

<jon_avila> +1

<AWK> -1 I could agree with a note to indicate that we want feedback on whether we need a definition for interruption, but the easily piece is a blocker for me

-1 until definitions have been clarified

<JF> If we gewt the Editors Note into the PR, then I would change my vote

<Kathy> -1 we should have suggested definitions even if they will change or need to be revised based on the other SC proposed

<Greg> +1 because I don't understand why the new wording should be held to a higher standard than the existing wording. Is it only because of the proposed change from AAA to AA?

+1 to JF's note

<Glenda> -1 I need “easily” removed

<steverep> +1

<Pietro> +1

<allanj> +1

<shwetank> +1 as long as changes are defined further along making clarifications

Josh: People's concerns noted. I think this is overall moving toward accepted, with the understanding of definitions provided and editor notes.
... could anyone absolutely not live with this?

<JF> if things are "fixable", let's fix them please

<Kathy> can we put an editors note stating that this will be defined

Andrew: I think what's going to wind up happening, we'll need to make sure that these things are addressed in a way that people who have concerns will feel that we've spoken to these things. Whether by notes about "Yes, we know this is an issue"

<Zakim> Joshue, you wanted to say COGA will need to do due diligence to ensure that terms are met

Andrew: Josh: There will be a certain amount of due diligence done, and we'll have more to do.

JF: Part of the reason we'll go to FPWD is the first *Public* working draft. A lot of people will look at this and raise the same concerns.

<Glenda> I can live with it going to first public working draft (but I don’t see how “easily” could ever be defined so that we would get consistent results from the top 10 experts in the field)

Josh: We don't want that, and we'll address the issues brought up here before it goes out into the FPWD.

Lisa: What I wanted, to get "accept with this and that" so that we can go and do this and that.

RESOLUTION: Accept pull request into editor's draft

<AWK> trackbot, end meeting

This is scribe.perl Revision: 1.148  of Date: 2016/10/11 12:55:14  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Succeeded: s/vauge/vague/
Found Scribe: Lauriat
Found Scribe: Shawn
Found Scribe: Lauriat
Inferring ScribeNick: Lauriat
Scribes: Lauriat, Shawn
Default Present: AWK, mattg, jeanne, Greg_Lowney, David_MacDonald, JohnRochford, JF, Adam, Lund, Wayne, alastairc, marcjohlic, Lauriat, Makoto, Joshue108, MichaelC, KimD, lisa, seeman-kestenbaum, Laura, Kathy, MikeGower, kirkwood, Mike_Pluke, allanj, jon_avila, steverep, JamesNurthen, erich, Rachael, Wilco, Glenda, Jim_S, David-MacDonald, AdamL, MelanieP, MoeKraft, Katie_Haritos-Shea, adam_solomon, Pietro
Present: AWK mattg jeanne Greg_Lowney David_MacDonald JohnRochford JF Adam Lund Wayne alastairc marcjohlic Lauriat Makoto Joshue108 MichaelC KimD lisa Kathy MoeKraft steverep Katie_Haritos-Shea adam_solomon Pietro jon_avila
Found Date: 14 Feb 2017
Guessing minutes URL: http://www.w3.org/2017/02/14-ag-minutes.html
People with action items: 

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