AG meeting -- 04 Aug 2020

<laura> Scribe: Laura

Silver presentation update

AC: we were going to have a presentation from JF.

<Chuck_> https://www.w3.org/2017/08/telecon-info_silver-fri

Chuck: JF will present on Friday instead.
... please attend.

<Chuck_> https://www.w3.org/WAI/GL/wiki/Meetings/Silver_Deep_Dive_2020-08

Chuck: deep dive next week.

WCAG 2.2 issues https://www.w3.org/2002/09/wbs/35422/2020-07-CWA/results

Review and approve response to Issue 1156 "Loophole in SC2.4.11 allows almost invisible focus indicators"

ac: lots of surveys today.
... response to an issue.

<alastairc> Proposed reponse: https://github.com/w3c/wcag/issues/1156#issuecomment-664425314

ac: mostly approvals. This is an updated version.
... awk said, “Notes are non-normative - why isn't this in the understanding document instead?”

<alastairc> https://raw.githack.com/w3c/wcag/wcag22-focus-visible-enh-updates/understanding/22/focus-appearance-minimum.html

<alastairc> Latest understand doc ^

ac: awk not present.

<alastairc> Note: These enhancements complement the requirement in 1.4.11 Non-text Contrast that the focus indicator achieves a 3:1 contrast against the adjacent background color

ac: any other comments?
... pasted in note.

awk: wondering why it was needed.
... not sure thing that was added. Not sure what the gap was.

sukriti: micheal wanted the note.

ac: Michael = MG

awk: I can live with it. But better in the understanding doc.

ac: we already have 2 notes.
... any one object to not adding it?

MG: concern around creatively reading the SC.
... want to make it more infatic

ac: could be ringing alarm bells.
... suggest we put out the line.

MG: then would like it to be in understanding doc then.
... I can do a PR then.
... any objections?

JA: trying to understand what we are saying.
... several issues on cross references.
... haven’t addressed how it fits into other SCs

ac: it doesn’t leave a loophole for this issue.
... I updated the comment.

RESOLUTION: Approve respose, but instead of a note, the understanding document will be updated to reflect commentary currently in note, and present to group for later review and approval.

Dragging movement glossary definition: Deleting reference to intermediate point

https://github.com/w3c/wcag/issues/1195

ac: PR removing the reference. https://github.com/w3c/wcag/pull/1214
... Detlev created the PR

<alastairc> Dragging: https://w3c.github.io/wcag/understanding/dragging.html

awk: wanted to see it in context.

<alastairc> Andrew suggestion to add "or until the dragging operation is cancelled"

awk: it can be cancelled
... dragging definition needs "or until the dragging operation is cancelled" at the end.

mg: could end at “follows the pointer.”

ac: that keeps it simple.

<alastairc> Dragging movement: "an operation where the pointer engages with an element on the down event and the element (or a representation of its position) follows the pointer"

ac: the definition needs to work in context.
... not hearing any alarm bells.
... I may be hearing them.

…MG: anything we are missing?
... I’m fine.

<Zakim> AWK, you wanted to ask if dragging always requires a down event

awk: does dragging always require a down event?

<kirkwood> 3 finger dragging?

awk: any downside to leaving it at the down event?

ac: not sure it has the same issues.
... haven’t dealt with multiple pointers.

<kirkwood> sorry mic issue3s

<jon_avila> I do see 2 finger gestures to pan maps

sc: gives an example.

<kirkwood> sometimes embedded maps use it, but i’d have to check

ac: multiple fingers as 1 pointer?

mg: SCs compounding.
... don’t we have it covered from both perspectives?

ac: I feel we do.
... SC uses single pointer.

<alastairc> "an operation where the pointer engages with an element on the down event and the element (or a representation of its position) follows the pointer"

<kirkwood> “New Google Maps two finger embedded move and zoom”

<alastairc> https://github.com/w3c/wcag/pull/1214/files#diff-8c0e9ad76dafdaba2b22e75a981e0f65

RESOLUTION: Accept new definition for Dragging movement: "an operation where the pointer engages with an element on the down event and the element (or a representation of its position) follows the pointer"

AC: mg SC is AA

WCAG 2.1 issues https://www.w3.org/2002/09/wbs/35422/wcag21-issues-2020/results

will have more 2.2. issues as we have published more SC.

Clarity on Understanding 1.4.11 regarding hue #868

<alastairc> https://github.com/w3c/wcag/issues/868#issuecomment-541944551

ac: Detlev not here. lots of comments in the survey.

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

ac: fstorr, are you okay with the answer?

fstorr: yes.

ac: inclined to leave open

<mbgower> Figure 7 Two examples which fail a success criteria, the first fails the Use of color criteria due to relying on variation in color alone (yellow and white hues, without adequate contrast). The second example fails the Non-text contrast criteria due to the yellow (#fff000) contrast against the white ratio of 1.2:1.

mg: proposing different wording.
... explains more about which is the white.

<mbgower> Figure 7 Two examples which fail a success criteria, the first fails the Use of color criteria due to relying on yellow and white hues. The second example fails the Non-text contrast criteria due to the yellow (#fff000) to white background of 1.2:1.

ac: makes sense to me.

ac: Francis can you update?

FS: yes.

<alastairc> propose: Accept response and update the caption to figure 7 as above

<GN015> which wording to we agree to now?

gn: I like the first example.

mg: that’s fine.

RESOLUTION: Accept response and update the caption to figure 7 as above.

exception for logos (1.4.3, 1.4.11) #902

ac: issue 902

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

ac: proposed response is: The exception for logos is a well established exception from WCAG 2.0 that during the discussions on non-text contrast we decided not to call it out separately.
... Gundula commented on infographics in Figure 14 have been understood as logos.

GN: original logos were different colors than these.

ac: agree. but is a secondary point.

GN: It might be good to add an example providing the same information as Figures 14 and 15, but using the logos.

ac: does anyone disagree with the core concept and response?

<Chuck_> +1 agree

<jon_avila> I raises a good point when logos are used in an infographic rather than just as a logo.

ac: awk doesn’t agree.

jon: difficult for us to include logos in some cases.

<jon_avila> Seems so

ac: are we leaning on “required for understanding”?

awk: I think so.
... it should trigger a failure.

<jon_avila> I agree that text beside it that is not part of logo could be a solution if you can't change it.

jennie: cognitive overlap on this one.
... both visual and cognitive. Something to consider for personalization.

chuck: let’s address the question that was asked for now.

ac: if we lean on required for understnding we may ge some varying results.

<Zakim> Chuck_, you wanted to ask for scribe change

<Rachael> scribe: Rachael

alastairc: Justine points out that logos logically fall under the exception. They don't always though as they are links.
... Not applicable if we don't use ...I didn't mention the essential exception. I just said it was well established from WCAG 2.
... Does anyone have a better response or a variation on it?

<alastairc> Proposed response: "The exception for logos is a well established exception from WCAG 2.0 that during the discussions on non-text contrast we decided not to call it out separately."

Chuck: I like the way you've written it because the more we try to lean on the other, the more we will face challenges with the exceptions and alternatives that I woudl like to address separately.

alastairc: I'm looking at AWK's comment and trying to see if there is anything to incorporate
... does anyone object to going back with that response?

RESOLUTION: accept Alastair's proposed response and close issue 902

Meet 1.3.5 via name attributes mapping to schema.org? #935

alastairc: Issue 935, Is it possible to use schema.org to meet identify input purpose? Proposed response was that it doesn't require autocomplete so other taxonomies can be used if there is accessibility support for it.
... GN proposed adding to understanding document. Looks like everyone agrees.
... it would be interesting to see what the Understanding document currently says about that.
... we could add part of the response about accessibility support to the understanding document. Will that suffice GN?

GN015: Yes. My main point is that if we clarify something we should also make it available to everyone (and ourselves at a different time) through the understanding document.

alastairc: ... would anyone take that on as a quick pull request?

<laura> s/emphatic /emphatic/

alastairc: propose we accept the response with the action to incorporate the response into the understanding document
... any objection?

RESOLUTION: Accept response and update understanding document for later review, close issue 935.

Cross behavior between focus and hover (1.4.13) #1196

alastairc: This was where someone was asking about 1.4.13 focus and hover. Particularly the persistent point. What happens when you hover over a button and mouse out, should that close it? Or should tabbing out close it?
... I suggested a draft response that the additional content remains visible so that the hover or focus trigger is removed. That way if the mouse triggers it then it stays until that is removed. If it is triggered by keyboard focus, the content stays until the keyboard focus is removed.
... reads a comment.

Chuck: I think you've used trigger in a way that encompasses either. He's drilling down into details that you've already covered.

alastairc: If its something that is triggered by space or enter that isn't covered by this SC.

<laura> s/understanding we may ge /understnding we may get /

Ok: The thing is if you use interaction relies on the last use. If you switch from mouse use to keyboard and keep on navigating the tooltip should likely disappear. If you reach other elements with the tooltips then you would need to display. One should be able to trigger it or and the other should also be able to remove it.

alastairc: That could cause a number of mistakes if you are a keyboard user and the mouse moves accidentally.

Ok: I wouldn't want to move back to a mouse to remove a tooltip.

mbgower: Oliver beat me to it. I think this is about interoperability. I don't think the dismissing action should rely on the triggering action. I think that ultimately whether the mouse triggers it or not, if I tab off of it, it should dismiss. I get what you are saying, that you can have the mouse move and trigger something unintended but that is the nature of keyboard use in that configuration.
... if I keyboard to something that has my mouse over it and then remove the mouse, it should dismiss it.

Ok: If we make it trigger centered, we could end up with two overlaps in parrallel.

jon_avila: What if you focus with the keyboard and the move the mouse when the mouse is Not on the keyboard, what happens?

alastairc: I think there are two ways forward. One is what I suggested which is that the triggering focus is removed. The other is that when either is removed it removes the content.

<Chuck_> https://docs.google.com/document/d/1TYJW3WcMoiMSX3339JqXM7k_LdhypsSMAXmoysS8rOA/edit

<sukriti> https://docs.google.com/document/d/1TYJW3WcMoiMSX3339JqXM7k_LdhypsSMAXmoysS8rOA/edit

sukriti: I think it adds complexity but I do think its documented. See link
... it was an initial proposal for how to make it clear when the two types of focus controls interact.

alastairc: I think there is another column to add since it was about the crossover. What I couldn't work out was if I tab to it and then hover over it and remove the hover, should that trigger the content to disappear?

sukriti: That was the first case when both are interacting. When either moves away, the content is dismissed.

alastairc: reads from document.
... I think what we are saying here is no. One is tab out, one is move mouse out. Are we saying that any apply? Anytime you move your mouse out of the trigger or tab out of the trigger it causes the content to disappear?
... I think we need to come up with a new response based on either hover or focus being used to close the new content.

david-macdonald: ... Are we going to allow cross testing to open it up with the keyboard and then mouse over and see if its still there?

alastairc: Sukriti has the whole table. I think that when you trigger new content on hover or focus, either can open or either can close.
... if you open it with a mouse trigger and then focus on it and remove focus, it should close.
... if you open it with keyboard focus and hten move your mouse focus on it and away, it should close.

david-macdonald: So no matter how it opens, if you move away from it, it should close.

sukriti: correct. The mouse focus is sometimes unintentional but the keyboard focus is typically intentional.

<sukriti> it is not

<sukriti> it would be an addition - you're right

alastairc: The table on the link is detailed but it is a tricky route to go down as its not supported by the current SC text.

david-macdonald: If someone is working with a mouse, it should work as expected when working with a mouse. If someone is working with a keyboard, it should work as expected when working with a keyboard. This increases testing to ensure conformance.

GN: I have seen users switch continuously between keyboards and mouse. If something is focused by keyboard it appears. If this means that once you use the keyboard you can't use the mouse, that is not the way to go. Same with the other way.

<Zakim> mbgower, you wanted to say is this an implementation decision?

mbgower: I'm wondering if this is really an implementation decision. When we ran into the calculation for name which ended up being a spec that needed to be written up. This seems to be beyond the control of the author and more on a user agent. I'm not trying to back away from the decision but am suggesting there is enough complexity here. I think the current language is specific enough while allowing some decisions by the browser and content

creator.

david-macdonald: What would be the way that most implementations would happen? They would have to listen to the onblur and then decide which one takes precedent. If we prescribe a way to do this, it gets into a pretty complex matrix pretty quickly.

<sukriti> thank you

alastairc: Do we get into that complexity and how easily can we forsee the differences? Sukriti's has a preference towards keyboard.

sukriti: I agree it gets into a little more of the prescriptive nature that we'd like to be. We can change this to give mouse and keyboard equal preference but the SC needs to be simple to understand so complex tables may not help.

<sukriti> 100%

alastairc: We may need to summarize but may struggle with the simple one. We have a difference between must and should. We could in the understanding document state "we recommmend..." and then include it. We could also state how we interpret the SC. In the SC text we could ignore the second part. We could state that if it triggers on hover, it must dissapaer when hover is removed and leave focus ambiguous. Use must for the triggering event and

should for the other focus type

<CharlesHall> regrets. have to drop early.

Chuck: I like the either option. That covers the situations.

<ok> +1

alastairc: It leaves things open and doesn't ban someone from doing something. I get the impression from the call that people were leaning towards either. Either is that no matter what triggers something to appear, removing Either hover or focus would cause the content to disappear.

<Chuck_> +1 either

<alastairc> Poll: +1 for either, -1 for the triggering input

<Ryladog> +1

<david-macdonald> +1 either

<laura> +1

alastairc: the other option is that whatever triggers it must be removed to cause the content to disappear

<jon_avila> -1

<GN015> either

<Brooks> I want to know why Jon is giving a -1.

jon_avila: My concern is the use case for low vision users when they focus something with the keyboard and they move the mouse and it is dismissed. Would this change impact the use case for why we created this criteria.

<Raf> +1

alastairc: I thought the use case was more mouse use so that if you hover over something you have more control about getting into it or moving over it. Its the problem of switching inputs. Did you mean to move the mouse or just accidentally hit it. Either is the more flexible option.

jon_avila: So if I trigger with focus and move the mouse elsewhere unrelated to the content, does that do anything?

alastairc: If you move hte mouse into the triggering element and out of hte triggering element, the content should dissapear?

jon_avila: But if I move the mouse elsewhere it should stay up?

alastairc: yes

jon_avila: I am more comfortable with that.

david-macdonald: Over the hover area?

alastairc: I don't think we are defining that.

<Brooks> If you have content that appears on mouse hover, which contains focusable elements, are we not going to allow users to Tab into that content that appeared on hover?

mbgower: Jon, your preference woudl be that if I take my mouse and go and do something with it you want the content to remain?

<alastairc> Pertinent SC text: "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."

jon_avila: yes. I am trying to understand the implications. If I bumb the mouse, I dont' want the content to go away.

mbgower: My takeis that as long as your mouse doesn't trigger something else, it won't interfere. I think if you trigger something else, it would disapear.

jon_avila: If you are using zoomtext or other magnification software and use the mouse to pan the screen, I want to make sure the content stays.

<sukriti> I can do it

alastairc: This gets more complicated because if you open a menu and then hover over another menu, the first should disappear when the other shows up. I think what we are getting to is that we need a new response. Would anyone like to write such a response?
... thank you sukriti.

RESOLUTION: Amend response based on either hover or focus applying, and review amended response later.

alastairc: Left that open but made progress

SC 1.3.5 fields with correct autocomplete inside form with autocomplete="off" #1197

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

alastairc: For input purpose, and we are generally using autocomplete for input purpose, you can have a form with autocomplete off but with autocomplete values on the inputs. Is that compliant? The proposed response is that it is ok but not desireable.
... slight editorable suggestions.

Chuck_: I've always intpreted that this standard is not about making autocomplete work but that the goal is to make the input identifiable. I think the conversations about how autocomplete behaves is out of scope.

alastairc: There is a question of if autocomplete is off, are the child attributes available. We tested and even if autocomplete is off, then the values are available. So for folks who want to keep autocomplete off for security reasons this might be a valid approach.

jon_avila: But even if its off, chrome still prompts for the content.

alastairc: but it still works. We have several editorial comments on the response.

<alastairc> Response: It is ok (but not desirable) to use autocomplete=off on a form, so long as the relevant fields have autocomplete with the appropriate value. The local autocomplete values on each input are still programmatically available.

alastairc: Any objections?

RESOLUTION: Accept amended proposed response and close 1197.

alastairc: no objections.

Removing application as a landmark from ARIA11 #780

alastairc: I think the application landmark got pulled from the aria spec. Someone raised this issue. From 2015 so we're not quick. Most agreed. Question of what is the alternative to reach content. I'm not sure there is a direct alternative in that way. The changes were to remove application. Landmark main is an alternative but the change is to remove application from the list.
... does that answer your question?
... any objections to approving this pull request?

<david-macdonald> +1

alastairc: no objections

RESOLUTION: Approve pull request and close issue 780.

Remove misleading/incorrect statement from 1.4.11 understanding #1058

alastairc: This one is around non text contrast. Everyone who has answered has agreed.
... for issue 451 its about adding a note that the SC doesn't directly compare the focuses nad unfocusted states of a control. There is a confusion that has come up so this seems like a good change. Any objections?

RESOLUTION: Accept proposed response and close 1058.

alastairc: 541 was already close. no objections so merging.

Changes to examples in Understanding 1.4.11 #1065

alastairc: this is a pull request prompted from issue 1014. Patrick suggested was "for a text input focus style a focus indicator is required. While in this case the additional gray outline has an insufficient contrast..." Remember this is applying to 1.4.11. It is removing an example and adding a checkbox with a subtle focus style. This helps differentiate it from focus visible.
... everyone who responded agreed with the update. Are there any objections or concerns?
... no objections

RESOLUTION: Accept proposed change and close 1065.

Removing Flash Techniques #1142

<mbgower> +1

alastairc: Removing flash techniques. AWK raised this. Flash is end of life so lets remove the techniques. Provided a pull request to remove these.
... no objections from the people who answered. There will be more work to remove the flash directory entirely. They will be there in 2.0. Do we want to remove from 2.1 or just from 2.2?

chuck: Safest approach would be to remove it from 2.2.

alastairc: Did the techniques change between 2.0 and 2.1?

AWK: no, they didn't change after 2.0 I don't know how easy it is to have techniques that apply to 2.0 but not 2.2.

alastairc: In progress

AWK: Either way. The use of flash is on the decline. It is end of life this year. I rarely run into flash content on web pages. I can't think of the last time I ran into it when there was a claim on accessibility. I wouldn't argue either way but want to take it out of the WG of list. Easiest approach is to remove.

alastairc: I agree that they are in 2.0 if you want to refer to them.

<mbgower> +1 2.1 and 2.2

david-macdonald: agreeing with everyone.

Chuck_: I have no objection to remove them

david-macdonald: We don't want people to use flash so I'd remove from 2.1 if I had a choice.

alastairc: any objection to removing flash techniques from 2.1 and 2.2?
... no objections. There is a bit of work before merging. I will do that later.

RESOLUTION: Agreed to remove flash techniques from WCAG 2.1 and WCAG 2.2, close #1142.

Update link-purpose-in-context.html #1164

david-macdonald: Regarding backwards compatibility. removing and adding techniques doesn't affect backward compatibility. People can meet an SC without us publishing techniques.

alastairc: start the next topic. The original request was to change purpose "to help users of assistive technoloiges" and removing some content.
... Patrick was suggesting 2.4.4 and 2.4.9 are fairly focused on AT and some parts of the understanding documents go beyond the SC. There was a fairly lengthy discussion
... suggestion to update the benefits.
... we are at time. We will resolve to leave open.

RESOLUTION: Continue conversation for proposed response to 1164 at a later date.

alastairc: thank you very much. We got plenty resolved today. We have John's presentation on Silver on Friday. See minutes for details. The deep dive is next week and the agenda will be out tomorrow.

- DRAFT -

AG meeting

04 Aug 2020

Attendees

Contents