AGWG teleconference -- 02 Jun 2020

<alastairc> COGA Usage re-review https://www.w3.org/2002/09/wbs/35422/2020-05-content-usable/results/

<alastairc> Focus visible updates https://www.w3.org/2002/09/wbs/35422/focus-visible-enh-issues2/results

<Jennie> Scribe: Jennie

Alastair: If you would like to volunteer to scribe please do

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

<laura> Scribing Commands and Related Info https://www.w3.org/WAI/GL/wiki/Scribing_Commands_and_Related_Info

Alastair: Please add your name to get into the minutes.

Small Conformance Challenges update

<alastairc> https://github.com/w3c/wcag/compare/conformance-challenges-update-ac#diff-69bcb62a2983f03a480aafe1cc4bf336L75

Alastair: As part of our publication process, someone was looking through and thought something should change that had not.

<alastairc> While a useful methodology for providing confidence in either a prior claim of 100% conformance across a website or as part of an internal process to help an organization assess their progress toward 100% conformance, in and of itself it doesn't address the challenges in making every last aspect of every page conform 100% to every success criterion.

<alastairc> Changed to:

<alastairc> While WCAG-EM provides a practical method for claiming conformance for a website, it doesn't fully address the challenges in making every part of every page in a large, dynamic website conform to every success criterion.

Alastair: The problem was we didn't notice this was replicated further down in the document.
... With the same text - it wasn't changed in the 2nd place.
... We think it is now good to go
... Is that summary correct?

Judy: The parts I heard sound accurate.

Mike G: I did not get prompted for a password.

Michael: It is built into the URI

Alastair: We think it will go live on Thursday

Michael: It could be as far as next Tuesday or in between.

Alastair: Any questions or comments on that?

Redesign of support materials https://www.w3.org/2002/09/wbs/35422/redesign-requirements/

Alastair: We are joined by Shawn today.
... We are going ahead with this. It is a chance for the group to review, comment, and we will take positive results from the survey as a positive response.
... It is running through Github, so you can put in comments or issues there.

Shadi: Yes, I appreciate the amount of work the group has had in the last few weeks.
... The next phase will be for Hidde to start creating mock ups and prototypes.
... Each stage will get more difficult for fixing things
... Would it be possible to extend the survey for 2-3 days?
... I hope it is a quick skim to see issues jumping out at you, so we can avoid more costly fixes later.
... Maybe that's a good compromise?

<Chuck> +1 to extending

Alastair: Sure, it will be extended to the end of the week.
... Hopefully people can have a look.

Bruce: I didn't see this one.

Alastair: It was posted on Friday about 10 minutes before the agenda.
... If people have things that need discussing they can always become an agenda item.

RESOLUTION: Leave open

COGA Usage re-review https://www.w3.org/2002/09/wbs/35422/2020-05-content-usable/results/

Alastair: This request is to put this up for wide review.
... 9 responses
... David had a few comments which Bruce agreed with and Rachael replied

<alastairc> https://www.w3.org/2002/09/wbs/35422/2020-05-content-usable/results

Rachael: we had made changes on the abstract based on the conversation
... I understood that the Design Guide portion did not have sufficient language

<Rachael> "...The Objectives and Patterns presented here supplement the Success Criteria presented in the WCAG accessibility guidelines and address those user needs that are not fully met in accessibility guidelines...."

Rachael: This is the language that was in there
... David M had suggested some wording, Laura made a similar suggestion

<Rachael> PROPOSED CHANGE: "The Objectives and resulting Patterns presented here are not intended to replace or add requirements to the WCAG accessibility guidelines. Rather, they are intended to address user needs that may not otherwise be met so that more people with disabilities can use websites and applications. This guidance is not included in the current normative WCAG 2.x specification. "

Rachael: this is the proposed change from COGA

<Rachael> Proposed change from David: "...The Objectives and Patterns presented here are not intended to replace or add requirements to the WCAG accessibility guidelines. They are patterns that could not be included in the normative WCAG 2.x specification and are intended as advice to help address user needs that may not be met otherwise..."

Rachael: that was the major change I saw from the 1st set of comment
... Thoughts on that?

David M: It is from a theme you may hear from me.

<shawn> [ Shawn sees minor copyedits, but not worth discussion ]

scribe: There is a balance. With the previous document, the challenges, there were a number of things which could undermine the credibility of WCAG
... I get concerned. I won't put "I cannot live with" on this but I am concerned
... "to help address user needs that may not be met otherwise" - people could still come away wondering why this wasn't included in WCAG
... I will throw out my concerns and let the group decide what they want to do with it.

Andrew K: David said a lot of what I am feeling. Where it says "not included in the 2.x" puts expectations that it will be included in the future.

<Chuck> +1 to DM's change

scribe: This is aspirational. We would like to include what would be helpful but feels like there is a slant to it. I like David's earlier proposed text.

<Zakim> alastairc, you wanted to say that WCAG talks about supplemental guidance, which this was supposed to be

<alastairc> "We encourage authors to refer to our supplemental guidance on improving inclusion for people with disabilities, including learning and cognitive disabilities, people with low-vision, and more."

Alastair: In WCAG we talk about supplemental guidance in the background section, close to the top
... This is something we put in, so I am not speaking to that exact sentence, but I would not be worried about supplemental.

Rachael: The goal of some of the rewording by COGA was to make it more readable.
... If something got included, it wouldn't automatically be taken out.
... I want to express appreciation to David for his thorough review.
... Can we just come up with wording that works for both readability, and addresses David and Andrew's concerns.

David M: I think we lost "patterns that could not be included" in the COGA rewording, is that correct?

Rachael: I think we have "this guidance is not included"

David M: We spent hundreds of hours trying to including them.

<Fazio> Why couldn't we get them in?

Raachael: I find "is not" better than "could not" - but that is speaking as myself.

<AWK> The Objectives and Patterns presented here are not intended to replace or add requirements to the WCAG accessibility guidelines. Rather, they are intended to address user needs that could not be included in the normative WCAG 2.x specification but are provided as advice on how to address user needs that may not be met otherwise.

<kirkwood> afree with Rachael don’t like ‘could not’ seems strong

Alastair: I think that is important - how does it read to those outside the group

David M: I was hoping to include what was considered, and here's why it could not be included

<bruce_bailey> FWIW, I like "could not be included" better than "is not included"

scribe: COGA did not want to do that. So we are left with they are not in WCAG...
... I don't know that is the voice the working group should have.
... We are working to make the standard great, and this is the best it can be right now

<mbgower> I prefer "could not be included" as well

<bruce_bailey> ... "is not included" does sound like we just didn't think about it

David F: I understand the concern that we don't want to mislead people. But we offer a few techniques for each guideline

scribe: This is guidance, to help meet the user needs of individuals with particular needs
... These are samples that will help designing things that will be helpful
... To me it falls within a grey area and should be fine

<Zakim> AWK, you wanted to point out alternative text proposed.

Andrew: I had put in text at 22 past the hour

<shawn> [ offering simple wording suggestions: The objectives and patterns in this document do not replace or add requirements to WCAG. This is guidance beyond what is included in WCAG 2. ]

Alastair: does that satisfy David and Rachael?

Rachael: I think we need the "may not otherwise be met..."
... I think that was important from the COGA conversation

David F: +1

Andrew: That doesn't make much difference to me. We are talking about end users that have user needs.

<Rachael> The Objectives and Patterns presented here are not intended to replace or add requirements to the WCAG accessibility guidelines. Rather, they are intended to address user needs that could not be included in the normative WCAG 2.x specification but are provided as advice on how to address user needs that may not be otherwise met so that more people with disabilities can use websites and applications.

<Zakim> bruce_bailey, you wanted to suggest "For various reasons, this guidance is not included in the current normative WCAG 2.x specification."

<mbgower> That's a long sentence now :)

Bruce: I'm ok with Andrew's edit.

<shawn> more simple wording version idea -- The objectives and patterns in this document do not replace or add requirements to WCAG. This is guidance beyond what is included in the normative WCAG 2. It addresses user needs that may not otherwise be met, so that more people with disabilities can use websites and applications.

Bruce: As long as we stick to factual statements I think it is ok, but I agree that it is not in the current standards is more judgemental than "could not be"
... I think Andrew's phrasing works.

Shadi: From the observer seat, rather than could not do, could we turn it positive using "beyond" or something like that to build upon and fill in gaps?
... I share David's concern

<Chuck> The Objectives and Patterns presented here are not intended to replace or add requirements to the WCAG accessibility guidelines. Rather, they are intended to add techniques and suggestions build upon the normative WCAG 2.x specification and are provided as advice on how to address user needs that may not be met otherwise so that more people with disabilities can use websites and applications.

<Chuck> The Objectives and Patterns presented here are not intended to replace or add requirements to the WCAG accessibility guidelines. Rather, they are intended to add techniques and suggestions that build upon the normative WCAG 2.x specification and are provided as advice on how to address user needs that may not be met otherwise so that more people with disabilities can use websites and applications.

<AWK> The Objectives and Patterns presented here provide additional advice beyond the requirements of the WCAG accessibility guidelines. They are intended to address user needs that could not be included in the normative WCAG 2.x specification but are provided as advice on how to address user needs that may not be otherwise met. This advice will help more people with disabilities use websites and applications.

<AWK> Tried to make a more positive version

Shawn: There are a lot of copy editing fixes needed.

<Chuck> The Objectives and Patterns presented here are not intended to replace or add requirements to the WCAG accessibility guidelines. Rather, they are intended to add techniques and suggestions that build upon the normative WCAG 2.x specification and are provided as advice on how to address user needs that may not be met otherwise so that more people with disabilities can use websites and applications.

Chuck: I am just throwing out a suggestion that builds upon what Shadi was recommedning

Andrew: I was trying to build off of Shadi's as well. Mine says what they do, rather than what they don't do

Alastair: We have lots of different ones

<kirkwood> Strongly to spin toward being more “inclusive” rather than ‘beyond’

Shadi: I'm curious - how does this approach work for Rachael and the other COGA members?
... I think Shawn mentioned using wording from the document.

John K: We should really be talking about including more people rather than going beyond.

scribe: More inclusive rather than going beyond.

Jennie (as Jennie) +1 to John K

<shadi> +1 to John K

Rachael: I don't have a strong feeling either way, and I agree with John's point

Alastair: It is supplementive, which is going beyond, but the inclusive isn't being addressed.

David M: WCAG is a consensus document, not an advocacy document.

scribe: If not included in WCAG, there are always user needs not included in WCAG
... In the last month there have been 2 documents that have come into the group that folks want us to put our voice on
... Both are critical of WCAG

<bruce_bailey> Friendly edit to AWK:

<bruce_bailey> The Objectives and Patterns presented here provide additional advice beyond the requirements of the WCAG accessibility guidelines. They are intended to address user needs that could not be included in the normative WCAG 2.x specification. This guidence is provided as advice on how to address user needs that may not be otherwise met and this advice will help more people with disabilities use websites and applications.

Alastair: You are correct in that. It is a perception thing in how people are taking the documents. It is difficult to predict how it will be taken by people.

<AWK> +1 Bruce

Alastair: I don't think it is intended to be critical. In Appendix C there is language that indicates this

<stevelee> +1

Alastair: It is almost relevant to this point

<alastairc> https://raw.githack.com/w3c/coga/changes-from-ag-meeting-may-2020/content-usable/index.html#appendix-considerations-for-uptake-in-different-contexts-and-policies

Alastair: There is a reason why it is extra

David M: Unfortunately it is kind of like movie reviewers. Sentences will be pulled out of the document, and reported by different stakeholders with competing goals.

scribe: It is worse to have a statement, than being more conservative in general.

<alastairc> The objectives and patterns in this document do not replace or add requirements to WCAG. This is guidance beyond what is included in the normative WCAG 2. It addresses user needs that may not otherwise be met, so that more people with disabilities can use websites and applications.

<Chuck> The objectives and patterns presented are intended to add techniques and suggestions that build upon the normative WCAG 2.x specification and are provided as advice on how to be more inclusive of user needs so that more people with disabilities can use websites and applications.

Alastair: I would suggest starting with Shawn's
... Is there anything this one is missing?

Chuck: I don't know if it is missing in mine. I tried to include all points as brief as possible, and hope I am not missing what COGA intended.

Alastair: Thank you Chuck for working to build things in, and shrink it.

Steve: Stepping back, it seems that there is a slight conflict of interest.
... As a group, including the task force, we want to say that there isn't intention that these things will become WCAG SC,
... but we also don't want it to be looked at for a reason why it is not there

Alastair: Without taking time to explain why they are not there

Rachael: This one is from the Design Guide introuction

<Rachael> This guide provides assistance making websites and applications friendly for people with cognitive and learning disabilities by providing guidance for designs and the design process.

<Rachael> The Objectives and Patterns presented here supplement the Success Criteria presented in the WCAG accessibility guidelines and address those user needs that are not fully met in current accessibility guidelines.

<Rachael> This guide is divided into design themes. Each theme includes user stories, testing methodologies, and design checkpoints. Just understanding the themes and user stories may help designers make content more accessible to some users with cognitive and learning disabilities. Please see the section on user testing for guidance on how to perform cognitive accessibility user testing.

* Thank you Rachael for pasting those in!

<Rachael> https://raw.githack.com/w3c/coga/changes-from-ag-meeting-may-2020/content-usable/index.html#introduction

Steve: I almost feel like just changing "supplement" could help

Alastair: As key words, supplementary being in 2.1, this would be the 1st one
... potentially one from low vision
... there are tutorials and things, but they stick fairly closely to WCAG

David M: There was a question a few minutes ago about why wouldn't we say why they weren't included

<shawn> [ wording in WCAG is "supplemental guidance" (in 'We encourage authors to refer to our supplemental guidance on improving inclusion for people with disabilities, including learning and cognitive disabilities, people with low-vision, and more.')]

scribe: It is a good question to ask if you were reading this document

David M: If we include it, you don't have to worry about nuance

scribe: In #7 in the survey, Rachael's comments
... there is a suggestion of the reasons why they weren't included, I think those are accurate
... If we want to include reasons, we could add those. That's my suggestion

<Zakim> bruce_bailey, you wanted to say @chucks suggestion uses "techniques" and "builds" -- so i like it less than other suggestion

Bruce: I appreciate David bringing this whole issue up, but I don't think the document has to go through the very valid reasons of why they weren't in WCAG
... Techniques makes me think of sufficient techniques...I would like to go back to the suggest that fits into the longer piece that Rachael pasted in

Rachael (as AG member): I'm concerned about documenting where WCAG falls short, even though those reasons are valid. I'm not sure we want them documented in a note that

<Fazio> Why not say the Objectives and Patterns are intended to provide helpful guidance, beyond WCAG (or committing reference to WCAG) to make web content more usable for...

scribe: talks about the needs of those with cognitive disabilities

<kirkwood> +1 do Rachael,

Rachael: that may be worth including in Silver

<Fazio> removes any implication that it relates to SC's

Alastair: Whatever change we make would be in both places

Chuck: I'm also concerned about having the justifications in this document, but for different reasons

<stevelee> +1

Chuck: it seems contradictory to include them, say why we didn't, but then saying but here's how you include them

Alastair: Several people are speaking against including the reasons. Bruce was speaking to his preference of language
... Bruce can you post the most recent version of what you like?

<bruce_bailey> The Objectives and Patterns presented here provide additional advice beyond the requirements of the WCAG accessibility guidelines. They are intended to address user needs that could not be included in the normative WCAG 2.x specification. This guidance is provided as advice on how to address user needs that may not be otherwise met and this advice will help more people with disabilities use websites and applications.

David F: To the task force, it was obvious we weren't trying to create new guidelines, we were talking about creating content more usable for people with cognitive disabilities

scribe: Usability is a separate issue.
... We are just saying it is guidance to help make content more usable - useful information
... I also think it is problematic to go into the reasons of why they weren't included

<laura> +1 to Bruce’s

Alastair: Bruce posted a longer paragraph. Is there anyone that cannot live with that?
... The first 2 sentences would also be used in the abstract.
... If we are using it in one place, we should try to be consistent.

<david-macdonald> I'm ok with it

<Rachael> I'm OK with it

<Chuck> +1 ok

<Fazio> 0

<Brooks> +1

<AWK> +1

<kirkwood> +1

Alastair: I will take no one being negative to be a win for this

<JF> +1

<Rachael> I believe the abstract would then read: "The Objectives and Patterns presented here provide additional advice beyond the requirements of the WCAG accessibility guidelines. Following the guidance in this document does not affect conformance to WCAG, but will increase accessibility for people with cognitive and learning disabilities. The Objectives and Patterns build on the:

<Rachael> +1

<bruce_bailey> looks good there too, +1

Alastair: We will need to take that as a proposed change as well
... We will take that one as done

Rachael: We don't need to address the other suggestions. Another comment in the survey asked what changes had been made.

David M: I want people to do these things.

Rachael: We really did try to address them.
... Alastair, your changes, if I can go through. The COGA facilitators have discussed them
... You suggested changing do or don't to void. We are split. Issue 116 is now change to active voice once in wide review.

Alastair: That makes sense. I'm fine with using do or don't if the rest of the language is changed

<david-macdonald> https://docs.google.com/document/d/1nPBQU-K8yXij9QhXU1AjDUwrwmr-Od-1lug5LbO1xqw/edit

Rachael: We didn't have a strong opinion either way.
... Can it be addressed in wide review?

Alastair: I think it doesn't make sense right now as you try read it through.

Rachael: Our preference is to change it to "use and avoid"

Alastair: OK, the 2nd one is straight forward.

Rachael: we agree

Alastair: The next is the use of must

Rachael: we missed that one
... and then (missed the 1st 3) we will remove d

Alastair: OK, that's allof mine

David M: I just posted a link to a Google doc, and from what I can tell, this is the basis for my sentence saying I had a number of concerns that weren't addressed

Alastair: OK while you are providing access let's look at Andrew's ones
... Rachael have you looked at those?

Andrew: In Appendix C it refers to the following table in the 2nd numbered bullet, and there is no following table.
... It is trying to point to the now linked table in critical services
... Which is the one we probably need to look at more because any document that is a note or spec linking out to something out
... We should be indicating that this is a draft in the link, and on that document when you get there, we should have a note in there that is like the Content Usable document, like publication
... of this does not imply endorsement...
... other than a work in progress.
... I worry that it will be side linked and misconstrued.
... And for #4, which is just a wording change. I don't understand what "clear conformance" is

<Fazio> 0

Rachael: I personally have no problem with any of those changes. Does anyone in COGA have concerns?

<kirkwood> no

<bruce_bailey> +1 good catch

Alastair: In terms of what we do next, David M did you get a chance to look through Rachael's list?

David M: I just looked at Rachael's document, and pasted into the Google doc - maybe I missed something

scribe: #1, 2 were not addressed; 3rd was slightly addressed, 4th same thing.
... That's what gave the basis of my comments in the survey
... I remain concerned that in the last couple of months we have had these documents come in and I think they can be used against WCAG

<laura> Jennie are you ready for me to start scribing?

* Thank you Laura!

<laura> Scribe: Laura

RM: Patterns can actualy stop somebody.
... hard change for coga
... coga push back on first 2 DM suggestions.
... if we missed the mark on #3 we should talk about it.

<Zakim> bruce_bailey, you wanted to ask about status of "6.1 Guidance for policy makers"? Will it be incorporated or standalone note or stay a google doc?

bruce: Is the not going to be a google doc or a note?

ac: converted to an html page?

bruce: a wiki is too fluid.

mc: create a separate web page.

ac: it will be taken care of.

chuck: doc is going in the right direction.

rm: like putting “draft” on it.

<bruce_bailey> i think it needs a stable date rev

rm: wiki with a warning may be the answer.

<david-macdonald> https://docs.google.com/spreadsheets/d/1XShLFX8fxHYYLn8A6avDwu37w9JfnZCGWvAKBpK9Xo4/edit#gid=264773938

bruce: wiki is better than a google doc.

dm: going into 2.1 we had a requirements table similar to https://docs.google.com/spreadsheets/d/1XShLFX8fxHYYLn8A6avDwu37w9JfnZCGWvAKBpK9Xo4/edit#gid=264773938
... I’m concerned.

rm: that may be a mistake.
... I will take an action to investigate.

bruce: I was surprised to find the link.
... we won’t link it from this doc.

<alastairc> "table of design patterns and policy criteria"

<alastairc> link will be removed.

<kirkwood> ok

<bruce_bailey> +1 to keep it a work in progress, +1 to deleting link

sl: it was an oversight.

DM: it is a long document. Don’t know what other chestnuts are in it.
... doesn’t sound like WCAG’s voice.

RM: it has been published as a working draft for some time.

<Fazio> +1Rachael

RM: we have the best of intent.

dm: I am concerned. Long history.
... 2 recent docs may hurt WCAG.

<bruce_bailey> Sentence will need editing without a hyperlink:

<bruce_bailey> A policy for critical services might require any design pattern with a medium to high user need level, as reflected in the table of design patterns and policy criteria.

dm: we need to hear their voices but if we can’t get something in…
... wcag is a consensus doc.
... I will trust that it will be okay.

chuck: to dm- are you getting a feel of a wcag critique?
... I think it could be seen that way.

ac: it is a large document.

<Fazio> WCAG is equally criticized for lack of COGA specific guidance and SC's

ac: df may have a point. WCAG is equally criticized for lack of COGA specific guidance and SC's

<Fazio> wasn't it a 2.2 mandate also???

jf: what dm was saying has a resonance with me.
... wcag testable measureable, and repeatable.
... be clear that it is supplemental guidance.

<Fazio> we are

jf: it vetted is best practice. beyond bronze level.

<Fazio> in functional needs

<Fazio> subgroup

rm: coga appreciates the wg’s review of the doc.
... we should take more time if needed to review it.

ac: intent was to publish it as a note at the same time as 2.2.

<Fazio> I think it's ready

ac: do we need more time to review?

<Fazio> +1

<Rachael> +1 with the edits that were suggested today

<bruce_bailey> +1 i am happy to have it go out for wide review

<JF> "wider" review? +1

<david-macdonald> +0 I've done what I can

<kirkwood> +1

<JakeAbma_> +1

<Jennie> +1

<Fazio> +1

<jon_avila_> +1

<Chuck> 0

<Raf> +1

ac: not seeing any -1s

RESOLUTION: Ready for CFC after today's edits are made

sl: I am concerned by dm’s comments.
... don’t understand what would be a criticism.
... doc provides extra information
... plus 1000 to rm

df: silver tf is using this doc a lot.
... don’t think we are criticizing wcag.

jf: looking at draft doc. Supplement guidance is helpful.
... wondering if we were hastly in removing it.

ac: make the edits and then give people a chance to review it.

dm: confident in group decisions

jf: repeating the supplemental part would be good.

<kirkwood> no objection

jf: not a hill I will die on.

<Jennie> +1 to repeating.

ac: we will have a fresh version to review soon.

Focus visible updates https://www.w3.org/2002/09/wbs/35422/focus-visible-enh-issues2/results

Sticky headers/footers violation of SC 2.4.7

ac: 1st one is sticky headers
... In a scenario where the visible focus indicator is temporarily obscured by a sticky footer/header, does that fail 2.4.7 now?
... impact on new SC in a couple of ways.
... last time 50/50 if it should fail.
... add extra bullet point.

anyone have opinions?

RESOLUTION: A sticky footer/header which temporarily obscures the focus indicator does NOT cause a failure of 2.4.7

<bruce_bailey> https://www.w3.org/2002/09/wbs/35422/focus-visible-enh-issues2/results#x952b

Understanding addition about mode of operation

<bruce_bailey> https://www.w3.org/2002/09/wbs/35422/focus-visible-enh-issues2/results#x301

<alastairc> “Mode of operation”, accounts for platforms which may not always show a focus indicator, or only show the focus indicator when the keyboard is used. User agents may optimise when the focus indicator is shown, such as only showing it when a keyboard is used.

ac: suggested response: “Mode of operation”, accounts for platforms which may not always show a focus indicator, or only show the focus indicator when the keyboard is used. User agents may optimise when the focus indicator is shown, such as only showing it when a keyboard is used.

<jon_avila_> focus-visible

ac: mostly agreement with the response
... patrick suggested adding a positive techique using focus-visible

mg: Patrick's suggestiion makes sense as a way to provide clarity. Better approach
... somewhat nervous of refining what's covered by this too much.

ac: we will be using the same phrase in the SC.
... anyone think that it is problematic?

<alastairc> Proposed text to explain: “Mode of operation”, accounts for platforms which may not always show a focus indicator, or only show the focus indicator when the keyboard is used. User agents may optimise when the focus indicator is shown, such as only showing it when a keyboard is used.

mg: seems kind of like a get out of jail free card.

<alastairc> “Mode of operation”, accounts for user-agents which may not always show a focus indicator, or only show the focus indicator when the keyboard is used. User agents may optimise when the focus indicator is shown, such as only showing it when a keyboard is used. Authors are responsible for providing at least one mode of operation where the focus is visible.

<alastairc> Proposed: “Mode of operation” accounts for user-agents which may not always show a focus indicator, or only show the focus indicator when the keyboard is used. User agents may optimise when the focus indicator is shown, such as only showing it when a keyboard is used. Authors are responsible for providing at least one mode of operation where the focus is visible.

ac: any objections?

<alastairc> Any objections?

RESOLUTION: Accept new text as amended

Changing the level of SC 2.4.7

ac: we agreed to this last year.

<bruce_bailey> https://www.w3.org/2002/09/wbs/35422/focus-visible-enh-issues2/results#x1041

ac: raised as an issue by wilco
... (reading survey results)

<Zakim> bruce_bailey, you wanted to ask that we postpone this discussion

bruce: jf has been concerned i the past about changing.

<Zakim> mbgower, you wanted to say this doesn't break backward compatibility

bruce: may bring this up again next week.

mc: doesn’t break backwards compatabilty.

<bruce_bailey> i agree this does not break backward compatibility

<bruce_bailey> i am all for some minor normative corrections

ac: complication that it may be a tooling issue

<bruce_bailey> i just think our first normative change needs full deliberation

<Chuck> +1 to discussing next week

<alastairc> https://github.com/w3c/wcag/issues?q=is%3Aissue+is%3Aopen+label%3A%22WCAG+2.2%22+-label%3A%22Technical+%28bug%29%22+-label%3A%22Survey+-+Ready+for%22+-label%3A%222.4.x+Focus+visible+%28enhanced%29%22

ac: list of normative changes at: https://github.com/w3c/wcag/issues?q=is%3Aissue+is%3Aopen+label%3A%22WCAG+2.2%22+-label%3A%22Technical+%28bug%29%22+-label%3A%22Survey+-+Ready+for%22+-label%3A%222.4.x+Focus+visible+%28enhanced%29%22
... 12 issues in there likely to come up soon.

- DRAFT -

AGWG teleconference

02 Jun 2020

Attendees

Contents