<Brooks> scribe: brooks

<AWK> https://www.w3.org/WAI/GL/wiki/Scribe_List

Survey: https://www.w3.org/2002/09/wbs/35422/technique-approvals5/results

<kirkwood> present

Understanding update Non-text Contrast

dm: I'm a little bit confused about the 1-5 star example that was provided as an example of something that was likely to fail. Is that because of the use of color?

<alastairc> Example 22 here https://alastairc.uk/tests/wcag21-examples/non-text-contrast.html

ac: The filling of the filled one doesn't contrast with the filling of the empty one, doesn't pass contrast.

dm: The contrast of one state doesn't meet minimums when compared to the previous state.
... Maybe need to clarify by adding a note that makes it clear what's in scope in the Understanding text for this scenario.
... not sure whether changing from one color to another refers to previous state or if the comparison is with the background color

<Detlev> I would move previous state considerations into a separate SC (as proposed)

<alastairc> Non-text information within controls that uses a change of hue alone to convey the value or state of an input

dm: in the list of focus indicators, I think it would be good to have two color focus ring as an example

ac: I think that would go under the Focus Visible Understanding document

<alastairc> David, have a look here: https://github.com/w3c/wcag/pull/583

<Chuck> +1 Chuck

awk: "For active user interface components" seems like clearer language to use.
... "Visual effects" may be confusing to some. "Visual information necessary to indicate state" may be clearer.

<alastairc> Current note: Non-text information within controls that uses a change of hue alone to convey the value or state of an input, such as a 1-5 star indicator with a black outline for each star filled with either yellow (full) or white (empty) is likely to fail _Use of color_, rather than Non-text Contrast.

<alastairc> Suggest: Making it not a note, and add a figure?

awk: I found the note confusing. We might need figure out a better way to say it is possible to pass 1.4.11, but fail the Use of Color SC. To make it more clear, we might need multiple examples that show failing just the Use of Color SC, then another that fails Non-text Contrast, then another example that fails both.

mg: I'd say let's use an example that fails both.

<alastairc> Examples: https://alastairc.uk/tests/wcag21-examples/non-text-contrast.html

<Detlev> wow

ac: That would be a fairly straightforward example. It would be a cross between multiple examples. Example 22, 23a and another I'd need to create.

awk: Maybe we should move this note into the Use of Color section, otherwise the note is going to get enormous.

ac: I'll move that paragraph into the relationship part and include an example.

awk: wondered if language should change where adjacent part was another part of the component. In other words, remove the word "with." The last question was about using the word check instead of tick.

<alastairc> All updates done apart from the note: https://cdn.staticaly.com/gh/w3c/wcag/non-text-contrast-updates/understanding/21/non-text-contrast.html?x=5

awk: any other comments about this topic.

mg: Show a fourth example that shows the selection of the star.

ac: And that would pass by showing a change in the form/shape.

mg: I think it is great to show examples that demonstrate ways of achieving.

<Rachael> no objection

<Chuck> None

awk: any objection to accepting pending the edit?

<Detlev> *1

<Detlev> +1

+1

<JakeAbma> +1

RESOLUTION: Accepted as amended pending final edits by Alastair

jon: I thought the active column in the tables of examples in Alastair's page was something that wasn't supposed to be included.

ac: In practice, what I was finding was that there was no difference between active and selected.

jon: just wanted to make sure that the active state wasn't supposed to part of this SC, correct?

ac: correct

JF: When I look at the second visual example with adjacent colors, I still struggle saying that the anyone can see the one with the silver background.
... my concern is that how do we measure the right colors for contrast? Does it have to be measured manually?
... the silver against the blue is what should be measured.
... I'm looking at the section "Adjacent colors" in the Understanding Non-text contrast page.

ac: focus indication is essentially separate from this.

jf: if it is separate, I don't get that from reading the document.
... I can't accept that the dotted outline against the background is sufficient as a focus indicator.

<jon_avila> I don't think Firefox using a dotted rectangle on inputs -- only a caret.

<alastairc> Sufficient techique for focus visible: https://www.w3.org/WAI/WCAG21/Techniques/general/G165

jf: when one color changes, you have to re-assess the contrast.

mg: I was concerned with the same example that JF mentioned. It seems to me like this example is an outlier, and wonder if it would be better to exclude this one or change it.

dm: Is the component being changed in this example?

ac: changes of color are not covered by this except that they have to maintain minimum contrast.
... We should add techniques to the Focus Visible Understanding document.
... We have a technique related to using the default focus indicator.

<jon_avila> Alastair mentioned that the focus indicator is based on current color. I changed the color of a button and the dotted outline color did not change.

jf: we already have language that says if the focus indicator is styled by the author, it must meet the 3:1 color contrast minimum. Many sites are designed so that the focus indicator is styled by the site designer.

<alastairc> Jon- sorry, that was specific to links

dm: My question earlier is whether about whether or not the blue background was part of the component or is it part of the page.

jf: to me it all hinges on the difference between "and" or "or". Right now, the language reads "and states".

awk: I think what JF is saying is correct, in that if someone doesn't measure the contrast after changing a color, there's a problem. I think that the piece here that needs clarity is whether or not the component, if unmodified, requires a new sampling of contrast.

<david-macdonald> user interface component a part of the content that is perceived by users as a single control for a distinct function

awk: The Understanding document needs to support the SC text, not the other way around.

<Detlev> Just noting that we have had this *very same* discussion already, with the same positions... I think Alastair's argument that we'd have to revoke G149 then is strong.

<david-macdonald> https://www.w3.org/TR/WCAG21/#dfn-user-interface-components

JF: The problem is that if you modified the background, you are still breaking the color contrast.

jon: I agree that this is how we initially wanted for this SC. But I guess the question is really about whether or not we can say that if the border comes outside of the control, then the exception doesn't apply because we still have to compare it with the background.
... I think this is can more complicated, partially because how we define a component is not clear.

dm: Component is defined as part of the content that is perceived as a control.
... the complications involved with this starts to spiral.

ac: what is key for me is that this SC not to spiral in complexity, needs to avoid triple color comparisons. So for example, a hover style that subtly changes color, shouldn't be considered in the color contrast measurements. Saying that every state has to contrast with every other state just doesn't work.
... We all agree that focus styles should be very visible. But we already have a technique that covers this. The group has said that the user agent has some responsibility in ensuring that high visibility.

jf: Alastair has bolstered my argument. My real concern is that in the Understanding document, we are weakening what is obvious, but not explicit in the SC. We should make it very clear that when the author changes one color that's factored in measuring color contrast, they are compelled to measure it agains the other color.

ac: how about we take out the focus examples from the table?

jf: if you aren't aware of these repeated discussions as we are in this group, there may seem to be contradictions in the Understanding document.

<JF> http://john.foliot.ca/demos/focuscolor.html

awk: I think we need a concrete proposal written up that covers these issues so that we can review and consider the key points. I don't want to try to do this analysis on the fly today. I also don't want to kick the can down the road. If someone wants to write up a proposal, they should that so that we can approach this in a systematic way.

<alastairc> "or where the appearance of the component is determined by the user agent and not modified by the author;"

chuck: I agree with JF's take on this, except one thing I'm not clear about. Does the language which exempts the user agent's behavior cover JF's concern or not?
... If it does not cover, I agree with JF - If you change one color, you own the responsibility of measuring and ensuring the contrast of the new color combination.

mg: I haven't had a chance to review the example that JF introduced fully. But, why don't we simply remove this example as a way to handle his concern?

ac: It's not intended to be a focus style.

mg: This example is very nuanced, and I don't think it serves its intended purpose.

<AWK> Scribe volunteer?

<AWK> Scribe: Rachael

Alaistairc: the document should cover the nuance.

<Chuck> alastairc - I know it's not that simple, but I feel if we answer the question of whether or not that language covers John's scenario makes all the other dominoes fall in place.

awk: Who is interested in/ able to write up a proposal for what we need to do?

jf: I will write something up and we can discuss it. Where does the silver rule come from?

Alastair: Lets discuss it offline

awk: Willing to give feedback. Anyone else who wants to assist, let jf know.

jf: I feel like this remains an issue.

general agreement that there remains an issue

<Detlev> There could be a case an explanation about 'adjacent' (thin line color 2) in cases of strong contrast between color 1 and 3, where having that silver line (color 2) makes no difference and measurement should basically ignore it. There might be a slippery slope as the line gets fatter...

chuck: agreement that there remains an issue

awk: any last comments?

Technique Border Contrast

awk: 4 say its ready, 5 need changes, 1 need discussion.

Example requested.

https://github.com/w3c/wcag/pull/576

awk: Does the technique need it? We can end up with a single technique and it ends up gathering more issues and becomes difficult to test.

david: What I was thinking the lines themselves be two colors. You can chose any colors you want. So not pulling the pie pieces out but a two colored border. I am not going to fall on my sword. You would just fix it in the image by shrinking it back.

one black line, one white line.

<Chuck> awk chuck

Detlev: I think I made my point in the github comment. It seems unnecessary to have good contrast between a border if the areas themselves have contrast. May be addressed by revised test text.

JF: I like the example. I think Detlev's point is good. To David's point, I wasn't sure if you were talking about a double line or a single line.

<AWK> s/examplle/example

<Detlev> Honest, who would want to use a double line? Would make the design very busy...

David: I think that example would lead to an easy way to put a single thing on everything and guarantee contrast.

JF: If you're talking about a double line, I have no issue. If you were talking about a dotted line, I would have an issue because of low vision users' needs

David: Yes a two color, solid line.

JF: a Zebra outline.

<Zakim> gowerm, you wanted to say use of "below" in figcaption is confusing

gowerm: I think the word below should not be in the caption. "The color contrast..." remove the word "below"

Jon: I agree with David that the situation with a white and black line will together create a good boundary and clear distinction. Things don't have to be adjacent but the boundary itself is enough of a contrast.

Alastair's example is also relevant here. When you look at the example of the darker gray can disappear. In the pie chart, you could have sufficient contrast but have a gray line and that could still pass. I think we should address both situations.

Detlev: I think there are many cases where the line doesn't have to have sufficient contrast but the colors in the areas are sufficent and you ignore the line.

<jon_avila> I think the challenge is getting around the word "adjacent"

The test should measure the things that are relevant not just adjacent. If its a 1 px outline, it wouldn't be important except in cases where there isn't sufficient contrast between the boundaries.

<Detlev> +1 exactly

<Detlev> automated testers will hate that...

Rachael: Adjust test so that you test areas with adjacent areas. If passes, disregard border if present. If not sufficient, then test border if present with adjancent colors.

awk: This isn't just about borders is it?

Rachael: No, we discussed merging the adjacent colors into this and that added complexity.

?: Some of the wording is confusing (surrounding vs adjacent)

awk: Jake, it sounds like you are highlighting the same gap I was highlighting. Nowhere does it state the border needs to have sufficient contrast.

Jake: We talk about it having a border and I added a small editorial. Needs to say "at least 3:1"

Specifically #3, we need to make it smarter. Its not about a border is present. It needs a small editorial update to fix the test procedure.

awk: Ok.

detlev left comments on github and they have already been addressed.

Rachael suggested revised test text: "1.Measure the contrast ratio of each color compared to the adjacent color(s) or to the surrounding border (if present). 2.Check that the contrast ratio of each is equal to or greater than 3:1."

<Detlev> we need a perceptual definition of 'adjacent'

jon put in that we need to clarify if both sides of the border need to pass. We still have the adjacent color challenge. Is the color contrast sufficient to understand the shape?

<jon_avila> Thank you for putting this together Rachael.

awk: It sounds like people are happy with the description. They would like to have the additional example of a two color border. The procedure requires a bit of work. We need to account for the scenario of a map with no border/boundary it can still pass.

We need to handle if there is a border. And we need to handle a two color border where you only test against one side.

awk: Do you have enough to work with Rachael?

Rachael: Its enough to get a 2nd round.

<Zakim> Brooks, you wanted to ask how does this technique compare with the work in progress in the CSSWG under issue 1172 - https://github.com/w3c/csswg-drafts/issues/1172

David: Agreeing with detlev. This would be a global way of resolving this issue without having to ever worry about the contrast testing. It would always be visible.

Brooks: I was going to ask, has there been any coordination between this technique (double outline) and the CSS Working Group?

David: The short answer is they say they are going to do it but the person who was going to be doing the editing got sick and hasn't had a chance to work on it.

JF: I think a gentle ping would be ok at this time.

Brooks: Would it have to be related to focus or can it be extended to non-interactive elements?

David: This wouldn't be done in html. You'd have to use Canvas. The CSS they are talking about wouldn't likely apply to this.

Alastair: Each of the images have the % in the pie so the borders aren't required for understanding. Can we remove the %.

RESOLUTION: Leave Open

awk: Rachael has some edits to do. We can hopefully move forward quickly at a future meeting.
... You added issues to review?

Alastair: These stood out as items to discuss.

567

<alastairc> https://github.com/w3c/wcag/issues/567

awk: You may have dimmed controls. Does anyone want to take that one on?

Jon: I can.

<alastairc> 574 Relation of 200% text resize requirement and 1.4.10 Reflow

<alastairc> https://github.com/w3c/wcag/issues/574

awk: This is the text size requirement and reflow. We can't assign it to detlev. Does someone else want to take this one?

Alastair: The question is can the text size be 200% bigger at some point? I think the answer is that it doesn't. Large headings don't necessarily need to be increased to be useful.

detlev: I think addressing the headings would be good to address. We really want the body text to increase. We should also address the issue of the breakpoints triggering but the body text is small.

maybe this is too far into the nitty gritty but I wasn't sure writing the test procedure how to handle this so wanted clarity.

Alastair: We discussed a test where you zoom to 400% and at some point during the zooming the text should be 200% bigger.

I haven't run across a case where it was bigger at a lower zoom but got smaller at a higher zoom.

awk: I thought we were in agreement that this was Ok.

detlev: I am ok with closing/withdrawing the issue. I haven't heard an outcry of need and I raised it as a technical point.

awk: Are you OK with this as an answer?

<alastairc> 581 Misleading info in "Understanding 2.4.4: Link Purpose

detlev: I am fine with it.

<alastairc> https://github.com/w3c/wcag/issues/581

awk: Glenda raised an issue and jon avila commented. Does anyone want to take responsibility for reading it and coming up with a proposal?

alastair: Glenda has a proposal to add the words "link text" to it.

Jon: I disagree which is why I commented on it.

alastair: Should we ask Glenda to reply?

Jon: The intent is not to tell everything in the link text. The aria-describedby is there to go beyond the intent of the SC.

<alastairc> 582 1.4.13 Content on Hover or Focus - hoverable requirement, clarification of point "persistent"

awk: We are waiting for Glenda

<alastairc> https://github.com/w3c/wcag/issues/582

awk: this is from detlev

detlev: The SC text says if point to hover triggers the content, then the pointer can hover over the content. This wording limits the hovering only to items triggered by pointer hovering. If someone tabs to it and it closes, it passes.

The wording should perhaps consider allowing hovering regardless of the trigger.

JF: I think it could be challenging because if you pointer device is nowhere near where your keyboard focus is it could trigger something else. The complex interaction is perhaps why it wasn't included.

detlev: I'm not sure if its a likely case that people are switching.

awk: I don't remember this being a use case we considered. The main one was high magnification when you are trying to see hover content.

detlev: that is the more important case for sure.

If this is what was meant, then this can stay and then Jon's scripting example can stay. Most of the issues with it were around the content disappearing.

Chuck: I have a way of thinking about this. Not sure its right. This topic sort of overlaps with 256. I've been thinking 256 is specific to mixed modality and the plain language of this is specific to the mouse. Is that right or does anyone know?

David: We were talking about the combination between mouse and keyboard. There is a way to close it via mouse

detlev: This is more about the issue of hover closing?

chuck: I think that the hover closing fails 256 leaving this one able to be limited.

alastair: 256 uses the word "restriction" so it is a limited scope.

detlev: It would be good to get input from low vision users. Is this a scenario?

Jon_Avila: This is a scenario that could happen. Perhaps we can talk about it and then circle back to see if this is the intent.

gowerm: I'm having trouble understanding the failure. For this to be a concern the mouseover must not be a trigger. The text is "...if it can be triggered by hover"

The way it is worded, the "if" covers the scenario.

detlev: I was wondering if it was a matter of scope.

Chuck: It sounds like Mike feels this is covered so the only action is to update the scripting example.

gowerm: It seems that the only way it is not covered is if the mouseover is not a trigger and that isn't a likely situation.

detlev: I still don't quite understand your point. Do you mean that regardless of the way its brought up it must remain?

gowerm: You are concerned that if I trigger it by keyboard focus...

Jon: Some low vision users would switch

gowerm: I am trying to think about a real world situation where this would happen. Usually the users have a keyboard or mouse bias.

awk: Jon can take this back to the low vision working group. The second half may count as an errata. It says "...until the trigger is removed" and the question is whether we meant "...until the hover on the trigger is removed."

<alastairc> Persistent: The additional content remains visible until the hover or focus trigger is removed, the user dismisses it, or its information is no longer valid.

awk: Detlev is asking whether we really mean that the trigger is removed or do we mean that the focus is removed from the trigger

detlev: I guess that what is meant is that the trigger is still there but the focus is removed.

+1 to errata

awk: With the first part of this, its using trigger as a verb. Its using it as a noun under persistent.

gowerm: You could still read it as a verb

I see what your saying. Its easy to follow how you would think you have to programatically remove the trigger element. That isn't the intent.

awk: Does anyone want to assign themselves to thinking about the errata for this?

david: It says until the hover or focus is removed. I think the or makes it a bit more complicated.

what would the errata look like?

<alastairc> Detlev suggested: "until the hover or keyboard focus on the trigger is removed".

awk: It may be removing the word trigger or it might be something more complicated. We don't know.

"on the trigger" could be removed. We aren't going to decide right now.

gowerm: This would be responding to 582. I'll take it.

I'm also working on the label in name request.

awk: 538 is the last one in Alastair's list.

<alastairc> 538 Clarify if modal dialog on page load is a failure of SC 3.2.1 + 3.2.5

I think there's been debate. Does anyone want to dig into that and see what they can detangle?

<alastairc> https://github.com/w3c/wcag/issues/538

detlev took this.

trackbot end meeting

This is scribe.perl Revision: 1.154  of Date: 2018/09/25 16:35:56  
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/awk/mg/
Succeeded: s/Alastiar/Alastair/
FAILED: s/examplle/example/
Succeeded: s/The restrictions in 256 are limited/256 uses the word "restriction" so it is a limited scope/
Default Present: AWK, Raf, alastairc, Chuck, Detlev, MichaelC, Rachael, Brooks, kirkwood, david-macdonald, JF, SteveRepsher, gowerm, MarcJohlic
Present: AWK Raf alastairc Chuck Detlev MichaelC Rachael Brooks kirkwood david-macdonald JF SteveRepsher gowerm MarcJohlic
Regrets: Laura_Carlson Kathy_Wahlbin Jim_Allan Mike_Elledge
Found Scribe: brooks
Inferring ScribeNick: Brooks
Found Scribe: Rachael
Inferring ScribeNick: Rachael
Scribes: brooks, Rachael
ScribeNicks: Brooks, Rachael
Found Date: 15 Jan 2019
People with action items: 

WARNING: IRC log location not specified!  (You can ignore this 
warning if you do not want the generated minutes to contain 
a link to the original IRC log.)