Meeting minutes
Rachael: We will need a scribe for hour 2
Rachael: Welcome. If you are just joining, please add yourself using present plus. And we are still looking for a scribe for hour 2 today.
*I wish I heard the snoring!
Rachael: We still need a scribe for the 2nd half of the meeting
new members and topics
Rachael: Welcome. Glad everyone made it!
… New members, and topics people want us to address.
Rachael: Has anyone here not been here in a while or is new and would like to introduce yourself?
Rachael: Does anyone have something we need to talk about that should be added to the schedule?
Mike G: Do we have any kind of discussion on an update on timing for 2.2?
<AWK> +AWK
Rachael: It is not on the agenda. Alastair - talk about it today or next week?
Alastair: Next week. We are trying to arrange an all day meeting (3 sessions). If you have interest in this, please respond to the survey in the list.
… We will get to CR around Christmas, which puts publication probably around March.
Michael C: From a process standpoint that sounds correct.
GreggVan: There is an Amazon Advisory committee all week, so most of the week I will be tied up.
<bruce_bailey> https://
Rachael: When you cannot make meetings, please send regrets.
… And when you are unavailable, please continue to respond to surveys, and you can participate asynchronously
Queue management reminder
Rachael: This is a reminder on how we are managing the cue.
… We are relying on surveys more.
… Thanks to everyone that is using the surveys.
… We will summarize the results, talk about comments that are supporting, then go through each comment individually
… We will then go through comments 1 by 1, ...then open topics
… We want to be sure we do not miss people that participate asynchronously
WCAG 3 Process discussion https://www.w3.org/2002/09/wbs/35422/approach_nov_2/results
Rachael: If you have feedback on that process, please email the chairs.
Rachael: Next item is for 60 minutes
… We are discussing the WCAG 3 process, a proposal
<Rachael> https://
Rachael: In addition to this document, there is also a visual version of it
… That's the processs
<Rachael> https://
Rachael: This is the workflow diagram in case visuals work better for you
Rachael: Survey results - whether or not to maintain a 3rd formal document within the process
… 2 options in the survey: I don't feel the need for a 3rd, and the opposite
… Starting with the 6 that did
… Rain stated "I'm concerned that 3 versions will lead to mistakes because there is more to track."
<Rain> I can't find unmute
Rain: I think that is my only concern. The more versions we have if a 3rd version is added, but if there is a way to easily move between the 3, and really clear delineation
<kirkwood> +1 to Rain
Rain: Otherwise it might get really confusing
Rachael: Sean also supported not having a 3rd document. Greg said to clear up ambiguities
… All levels 2-5 need to include pros and cons and items needed to make it to maturity
GreggVan: 1. Please substitute pros and cons with needs and issues. I think it should be all of the levels, including level 1.
… there should be the needs to why it should be in there. Having the issues will allow us to get placeholders in easier.
… If we all agree on the needs and issues, it will be ok to put it in.
… Some reference to what is needed to get to the next layer. If we did that, I think we can get by with the 2 documents.
… 2. If we have the ability to collapse things down, I think we can get by with 2.
Rachael: We will make sure we come back to those comments in the next conversation.
… Jeanne, you also felt we did not need a 3rd document. In the W3C general use of tools it is intended to be the sandbox. (continues reading from comment).
… Jeanne (you are muted) if you would like to talk, please let me know.
Jeanne: I do not have more to add.
Rachael: David M did not vote 1 way or another, but I spoke to him.
… (reads from David's response)
<JF> +1 to David's observation - the key is "public to the world"
Rachael: Is David here?
<GreggVan> Summary of my comments: would review my comments in the survey as follows: substitute Needs and Issues for my Pro and Con. I used the wrong words. It was needs and issues that needed to be included at each stage.
<GreggVan> In fact I would amend my comments to say — they should even be there for placeholder text. What good is placeholder if the need is not expressed - and issues can help focus work for the next stage. No need for a placeholder if there is no known need. And adding issues can help make placeholders more acceptable - and get them in sooner.
Rachael: He does not have a strong opinion one way or another as long as we address that concern.
… 2 people do feel we need a new draft: Laura C
… Laura's response (reads Laura's response)
Laura: I have the same concern as David has about getting consenus on what goes into the draft.
<JF> +1 to Laura
Rachael: Melanie had the other support for the 3rd version. (Reads Melanie's comment)
Melanie: I do not have anything more to add.
Rachael: I just refreshed the survey results. Andrew has added that he does not feel a 3rd version is needed
… Cybele adds that Github is not accessible for everyone
Rachael: I am not opening the cue until we go through survey results.
Andrew: I am sensitive to the concern about the increase in effort for the editors and chairs
… But we already work with includes so a document can be created and pulled in through a drafat
… draft. So if there is proposal 1 in a written form somewhere
… And proposal 2 that is relatively easy way for documents to be generated, which then pulls in additional items
… Each item gets edited independently, but there is a simple way for that document to be generative.
… This would reduce error and effort.
… My concern is in line with Laura's, and there should be a way to reference proposals, and to make them visible
<JF> +1 to AWK
Andrew: But I think there is a way to do so without them going into the editor's draft because I feel that removing them later would be more difficult
Rachael: Topics based on those survey results - where is the sandbox?
… Is it in the very documents or pull requests people create, or is it it's own document.
<Rachael> Topics: Where is the sandbox
<JF> I think you are asking the wrong question - it's not how many, but rather who can see it
Rachael: Are there other specific topics people want to talk about in order to make a decision as to whether we need another document or not?
Rachael: John points out that the 2nd topic is who can see the sandbox
<GreggVan> and how hard is it for someone to put something in
Rachael: 2nd topic: how visible to we make it?
<Rachael> Topics: Where is the sandbox, How visible/how much access, how hard is it to use
<GreggVan> to the sandbox
Rachael: 3rd topic: how hard is it to put something in?
<Zakim> alastairc, you wanted to say that we should link to github issues for the details / conversation, have a brief summary in the main document notes.
Alastairc: On Greg's point on having the needs and issues in the document
… I think we should have a summary and link through to github issues, or those tagged for that topic
… That balances between showing that there is work going on about that thing, and here is where you can comment
… How visible things are: there is no such thing as non-public, just how obvious we make it.
… The subgroups can prototype things separately, I haven't really seen a reason in people's comments about what the document would achieve
… The working draft is what the working group is approving
… Is the one before that an editor's draft or a sandbox
… If the editor's draft term gives too much weighting, maybe we don't call it that
JF: Personally I think we are asking the wrong question. We should be asking who has access to what.
… We have a bunch of subgroups working on content, and they have a desire to integrate it into the document we have
… If I understand Laura and David M, and me: it is hard to get things out of the working draft.
… How do we integrate content that came from 3-4 members, to the place of building consensus
… I struggle with making it so public that those unfamiliar with the weekly group happening with this group
… It telegraphs the wrong message
… I see that members of the working group seeing, but those checking in every 6 weeks or so - at what point do we expose things to a larger group (public) that is not part of the other conversations
<Zakim> GreggVan, you wanted to say "I don't think we should have 3 GitHub docs -- but we should encourage the use of separate sandboxes for topics (in a wiki for example) that allow discussion and working out of ideas before we try to do them in our working group meetings. The overhead to add each new thought or option would be too great. "
GreggVan: First, I share John's view
… The renaming the draft is an interesting thought that we had not talked about
… Editor's draft does sound like it is editorially different from what is coming out - that is how it is in other standards groups
… Linking to the GitHub - whatever this document is, if we put information in, and the information is in GitHub
… Cognitively and other ways it is not accessible
<alastairc> My suggestion was to summarize it in the document, a link to more (in github).
GreggVan: We can link to information there, but it can be hard to find what is the consensus of this is
… I think it is not available to many due to the accessibility issues
… I think the issues and needs must be right with the item
… I don't like the idea of another Github document
… Part of my concern of the editor's draft (or renamed sandbox) - how do they get it in there?
… Do we give everyone access to the editor's draft?
<jenniferS> For example, for screen reader users Github is unusable unless they are command line users. That is the blocker, imho.
<alastairc> We should clarify, the "github document" is the fully rendered spec version. The complexity is putting it in, not reading it.
GreggVan: When a new issue needs to be added, we don't want a long process
… The purpose of a sandbox is to have something that is more flexible, dynamic
… Then once it is in a better shape, it can go to the outside world
… Then we have additional layers. That is when I think it should go in the document that goes out, instead of each week having a new block.
<Rachael> ack: Rachael
Rachael: Alastair pointed out that his suggestion was to summarize the issues and needs, then link out.
GreggVan: That's find
… fine
Rachael: Part of the markup was to address the concerns - give visibility to those following along, but make it clear that it is not finalized
… What I am hearing the group say is that this is not enough
… If we called it sandbox, and clearly marked it up - is that sufficient?
<Zakim> Rachael, you wanted to speak to ask if marking up content does not meet the need
<Zakim> AWK, you wanted to say that "Editor's Draft" is the name in the Process document but it is optional, so renaming would address the concern better than integrating sandbox content into editor's draft. Also to speak about GitHub versions.
<GreggVan> that addresses most things but not access to the doc
AWK: The Process document does refer to an editor's document, but it says the working group "may provide"
… If we don't call it the Editor's document, I think that still follows this
<laura_> Need to give a warning too: something like: "WARNING: This document has been renamed Sandbox as it is not an Editor's Draft in the same respect as previous WCAG Editor's Drafts. In the past, the Working Group had consensus of what went into the Editor's Draft. This new Sandbox only not does not have Working Group consensus, the sand in the sandbox is shifting at varying rates."
AWK: I want to also speak to Github versions
… The document that someone reads, that is created through Github, still looks like an HTML version of the spec
… If you want to edit it, there is the complexity of learning how to do that
<Rachael> Topics: Where is the sandbox, How visible/how much access, how hard is it to use
AWK: It should be straightforward on how to read it, depending on the content
<Zakim> ShawnT, you wanted to say "Could we use the Github API to list issues related to certain topics"
AWK: But the pull requests involve that complexity
Shawn: Using the Github APIs in our document to point to issues that are open to make it more readable? I agree with Greg that Github is not accessible for working with it
… Linking the document to what is going on in Github
… There is an API that can list all the labels in the document
Rachael: In the process document on the wiki I have a list of things to work out
… Does anyone object to this going on that list?
Jennifer S: Because of the audience we have here
… Github is not accessible to people who use screenreaders unless they use the command line
… The desktop app, the UI..
… Unless we configure truly accessible processes for early version, then an able bodied team works on the next part
… It is not just the cognitive load, or the learning of the tools
… The Github tool itself is so inaccessible, this is a barrier
… We are not focusing on the needs of those with disabilities in order to be sure they can participate
<Rachael> ack: jenniferS
<jeanne> +1 Jennifer
Rachael: You are not objecting as long as we take that into account, is that true?
Jennifer S: That's correct.
<Fazio> COGA got chastized during a TPAC session because we missed a Github issue due to us having difficulty with git
Action: Rachael, work out how best to clearly state issues, needs, etc and link to github
Rachael: Any objections to moving that conversation off?
<trackbot> Error finding 'Rachael,'. You can review and register nicknames at <https://
Rachael: I have captured that for the wiki, and you will see it next week
JF: Again, to my mind, it is not how many documents we have
… It is about who has access to the versions we are working on
… There were issues when one group tried to merge some information into the document, without the larger group had difficulty reviewing before it goes into the public component
<Fazio> There's a lot of small silver groups working on content
JF: Every week I have to log in to view the call information
… We can restrict aspect to the working group
… It is important that before something is visible to someone that is not a member of this working group, it has to have consenus
… All these task forces want pieces so we can see it along with the wider whole
… It is the process of getting it exposed to a larger audience
<Fazio> Silver is wide open to the community which makes it more complicated
<Zakim> MichaelC, you wanted to note we are chartered public
<MichaelC> https://
MichaelC: The charter specifies that we do our work in public
… We can request a charter that allows us to use the member wall, but this is against the trend
… I'm not sure this would be granted
David-Macdonald: The big thing for me as a person using the drafts for years and years
… When I go to a W3C version that says latest editor's draft
… If we relabel the editor's draft, but the biggest thing that exposes it to the public
… If this link goes to the sandbox, it would be the same exposure
… I'm not against the relabeling, but we wouldn't want it to be the first link at the top of the page
<Zakim> bruce_bailey, you wanted to ask for more clarification on GitHub inaccessiblity
<bruce_bailey> i agree that GitHub is barrier to contributing to work , but i understood the barrier to be as more about useabilty than accessibility
<GreggVan> good point - we need to relabel it there too and not call it "latest version"
Bruce: I want to check in with what Jennifer said about Github accessibility - I agree it is a barrier to contributing
… I also understand that some that use screen reading software prefer the command interface
… I did not realize it was due to Github needing this
<jeanne> Bruce, it's a big learning hurdle to learn the command line interface if a screenreader user doesn't already know it.
Bruce: We use Github for the work we have been doing, but we may need to pay more attention to that
<david-macdonald> https://
Bruce: What we are doing is more simple than what the working group is doing
Rachael: This is an important topic, but I am struggling to be sure that go through the agenda
Janina: I am aware that some people have trouble with Github - so did I when I started
… I use both the web interface, the command interface (heavily)
… I have done things in Github branches
… I find it as accessible as editing HTML
… There is a learning curve - it is not obvious
<david-macdonald> https://
Janina: Just like learning to use a word processor there are things you need to know
… Are there multiple avenues into it? Absolutely
… The web interface is just a snapshot of some of the features in the command line
Rachael: Thank you Janina. I would like to move this part of the conversation to a separate meeting - Github as accessible
… We do have to reach concensus
<bruce_bailey> @Jeanne , yes I agree that CLI is big learning hurdle -- and that expecting a screen reader user to use CLI is not acceptable
GreggVan: Janina's description of what she had to do to access information in Github is exactly why we should assume this is not accessible information to the public
<Fazio> She is a rockstar
<alastairc> tanget alert...
<alastairc> tangent even
GreggVan: 2. Janina is at the high end of digital (missed word) - If we are trying to make this accessible we need to provide things that work better
Rachael: This is an important tangent
<Zakim> JF, you wanted to note that the same could be said about Google Docs
Rachael: We have spent meetings just on tool problems - this is not that meeting
Rachael: I am requesting we come back to topic
… We don't have that time
… I will put a straw poll out
<Rachael> straw poll (all options include marking): Option 1) Three documents, Option 2) Two documents but rename with warning, Option 3) Two documents with warning on editors draft
GreggVan: Don't we have to look at the next survey question to answer this one?
Rachael: We can, I was just trying to see where we were
<Zakim> JF, you wanted to note the issue is consensus
GreggVan: As long it is just a straw poll
Rachael: All 3 questions are related, I am just trying to bring us back
GreggVan: OK, proceed
<jeanne> OPtion 3
Rachael: From a straw poll perspective, not a final decision
… Not everyone speaks, and I want to be sure everyone has a chance
… Option 1: 3 documents
<Rachael> straw poll (all options include marking): Option 1) Three documents, Option 2) Two documents but rename with warning, Option 3) Two documents with warning on editors draft
*Thank you for pasting that in!
<Fazio> no change?
<JF> Option 1: 3 documents, with differing levels of consensus
DM: I would suggest the ammendment: if you change the name of the editor's draft
… All the things pointing to it in the TR, we need to pay attention to this
<Rachael> straw poll (all options include marking): Option 1) Three documents with differing levels of consensus, Option 2) Two documents but rename both document and link with warning, Option 3) Two documents with warning on editors draft 4) no change
<bruce_bailey> s/We use Github for work we have been doing/We use Github for web work we have been doing at my agency/
<david-macdonald> OK with 2 documents as long as there is a high profile, easy to access way for entire group to vet and comment.
<mbgower> 1-3, I have no strong feelings on this
<alastairc> 2, could live with 3
<jeanne> 3
Rachael: Did I miss anything else?
<kirkwood> 3
GreggVan: When you click on the link in the working doc it would show you a filtered version of the document with just the latest things which had consensus
… To the public, it would look like 3 documents
… The last 2 documents would technically be in the same document
<JF> +1 to Gregg
Rachael: I am not sure they would look like too documents
GreggVan: filtered.
<Fazio> This is getting way too overcomplivated. We're going to have mass confusion
GreggVan: A realtime compilation
Rachael: OK, I will add it to the list
GreggVan: then you would only have 2 documents to maintain
… But would also allow for a sandbox
… You would like as editors to the full sandbox
Rachael: I am not sure how we would do that, but ok
<Fazio> "sandbox" term gives me the impression that it is an editable document
MichaelC: We can make it happen, but my reaction right now is that how we achieve this should not be the focus of the conversation
<Rachael> straw poll (all options include marking): Option 1) Three documents with differing levels of consensus, Option 2) Two documents but rename both document and link with warning, Option 3) Two documents with warning on editors draft 4) no change 5) Three documents with filtered content
GreggVan: One of the arguments earlier was how much work it would be to maintain
<Fazio> 4
<Wilco> Options 2, 3, or 4
<sajkaj> +1 to option 4
<alastairc> 2, could live with 3 or 5
<jeanne> 3 or 4
<mbgower> 1-5
<JF> In preferred order, 1, 5
<david-macdonald> Gregg's filtered
<garrison> 3 or 4
<AWK> 1, 5, 4 in order
<ShawnT> 2,3 or 5
<Jaunita_George> 2, 3 or 5
<Lauriat> 3 or 4, could live with 2
<JakeAbma> 1 5 4 also
<Detlev> can live with any - want to move beyond meta discussion
<kirkwood> 3 or 5
<jenniferS> 3
<GreggVan> option 5 -- only one document to maintian -- but public sees Editors and Sandbox versions
<laura_> Prefer option #1, Can live with option #2,
<Rain> 3 or 4
<bruce_bailey> 3 , but 2 or 5 good too
<Breixo> all ok for me
<MelanieP> 1 5
Process approval
Rachael: The process approval - these questions are all interrelated
… Going to the survey
<bruce_bailey> 4 or 1 also akay with me , just not my preference
Rachael: 4 agree, 4 agree with changes, 2 disagree
… People with agreement with changes: Rain said it would be helpful to see how those accommodations will be managed.
Rain: no need to add anything further.
Rachael: (reads Laura's comment)
Laura: that's it, thanks.
Rachael: (reads Cybele's comment)
… Cybele is not here to comment further
<Fazio> MM?
Rachael: The maturity model is in the schedule
… There are 2 people who disagreed
… Greg, but then said it can work with changes made to make it clear what is going on
<Fazio> What about the Maturity Model?
Rachael: (reads from Gregg's comment)
GreggVan: I think this coupled with the idea of having the split between the sandbox and others as a path going forward
… Key point: things show up in the working draft when things are getting more mature, to help people identify them (to distinguish from acceptable)
Rachael: Did I miss anyone's comments?
AWK: this question is very related to the previous one
<bruce_bailey> +1 to Gregg comment wrt to word choice of "mature"
AWK: I would say if the process is adopted I certainly will use it, whether or not it is the one I want
… I think we need to carefully define the process for removing something from the editor's document
… Otherwise it will be a very heavy document
<JF> +1 to AWK
<alastairc> From the process page: "In order to be included in the final Candidate Recommendation (CR), content must be at the Stable level. By default, anything else that has not reached Stable will be removed before moving on to CR."
AWK: We should remove the things that are unneeded and get back to something more manageable in size
*Scribe change?
Rachael: I have 4 topics for discussion
<Rachael> Topics for discussion: How do we remove content, relabeling levels, Changing Editor's Notes, When does content go into the editor's or working draft
Rachael: We have 5 more minutes for these conversations
… Let's talk about relabeling levels
<Zakim> alastairc, you wanted to speak (later) about including placeholders in the WD
Alastairc: Speaking to Gregg's comments about placeholders in the working draft
… We have lots of guidelines showing those as placeholders
… That is very useful for showing the shape of the document as a whole
<Zakim> GreggVan, you wanted to say things should have to progress at some point or they are referred back to subgroup for further work
Alastairc: There is a good reason, but for that part of the process we would have to agree to put those placeholders in
GreggVan: We should probably have something in there to say that if something is in the sandbox and it doesn't progress over a long time, it naturally comes out without requiring a vote
<alastairc> We did include that anything not stable does not make it to CR
GreggVan: Then it could be referred back ot the working group
… It would allow things to get in easier, but without the worry that it would not get out
JF: I think Alastair identified the problem for me - we need to agree to get the placeholders in
… I see content coming in from subgroups, then it comes to the larger group and we get pushback
… At what point will it go into the document without broad consensus from the larger group?
… It is not how many documents it is when does something get added? When and where do we measure consensus for what can be publicly read
<JF> The general public does not know or care about W3C process, they go look to see what
Alastairc: we do say that if something does not reach stable, it will be dropped. We could add that in terms of things not going through - about it automatically getting dropped after a period of time
<JF> s happening
* Rachael Scribe change?
Alastairc: we can lower the bar. We could have a shared version we do not send out for public feedback
… We should be more confident as a group that we could put things in it.
… If it doesn't at least get to mature, it is going to come out anyway.
<JF> which is why I asked about restricting a view to the WG - the pre-concensus stage
*Rachael on mute?
<GreggVan> ok
<mbgower> sorry, my RSI just can't handle today, and I've lost my SR technology
WCAG 2.2 Focus appearance (1 new question added) https://www.w3.org/2002/09/wbs/35422/wcag22-focus-appearance-enhanced2/results
Focus appearance
Use of the word “state” is not sufficiently consistent #2049
<Rachael> https://
Rachael: Bruce raised this issue, regarding how the word "state" works with 4.1.2. The question whether to update the text should avoid the word state, or leave it as is.
… [reading comments]
<bruce_bailey> i agree with rain
<bruce_bailey> i agree with that comment too !
<bruce_bailey> m.gower
<alastairc> I think the lack of link to the definition of state was just the editorial style of only linking the first instance, although it's before my time
Rachael: Don't know if I'll raise an objection. Will to share this is the sort of thing, why Access Board should take its time adopting 2.2.
<JF> +1 to Bruce
Rachael: Shifting defined terms is a problem. In my reading this is more about presentation.
… I don't understand why we'd take the risk.
<Rachael> Topics: Concern of ambiguity, risk of shifting definitions
Gregg: Agree with Bruce, between states is a very technical term. In this case I don't see a need for using the term.
<Zakim> alastairc, you wanted to say that focus is a state
Gregg: I think it's a good change, and a non-technical wording of a non-technical issue.
Alastair: Don't understand why it's redefining things. State has a dictionary definition, so I don't see the problem.
<Zakim> mbgower, you wanted to say I'm not sure unfocused is a state
<Fazio> objection to reading level = plain language
Mike: I'm not sure that "unfocused" is actually a state, maybe everything has an implicit unfocused state. There is no focus="false" state.
… It's a non-trivial task. We've had 2.1 with this kind of problem as well.
<Fazio> If an ordinary dictionary meaning works than it should be ok
Mike: I don't think changing the wording will address the problems I see with it.
Rachael: Let start with a straw poll.
<Rachael> straw poll: 1) updating the wording to avoid state 2) option 2 leaving it alone 3) deep dive into the term "state"
<GreggVan> 1 - Contrast: The area has a contrast ratio of at least 3:1 between the colors when the component is focused and when it is not focused.
<Fazio> 2
<david-macdonald> +1 (I think we need to listen to access board
<alastairc> 2
<ShawnT> 2
<bruce_bailey> 1
<Rain> 2
<JF> 1
<Francis_Storr> 1
<Breixo> 2
1
<JakeAbma> 1
<Jaunita_George> +1
<mbgower> 2
<Fazio> Access Board is just 1 of many entities in the world
<mbgower> or 3 (but post-wcag 2.2)
Rachael: We may have an even split
<Francis_Storr> (I'd also be happy with 3)
<JF> @Fazio, true, but without broad adoption it becomes fiction of the worst kind
<bruce_bailey> i do regret not being able to articulate my deeply felt concern in the GitHub issue
Mike: We have something in the editors draft now. Unless we have consensus to change it, leaving it as is is the default action?
<Rachael> Who can not live with leaving it as it is?
Rachael: Yes
<alastairc> Contrast: The area has a contrast ratio of at least 3:1 between the colors when the component is focused and when not focused.
Mike: My suggestion would be, Bruce to take away what he's heard and come up with a proposal.
<Fazio> paste it?
<kirkwood> can we put the exact proposed language of Aliatairs in IRC?
<alastairc> it was, just above
Bruce: Alastair has a proposed version, it's a little more awkward, but I don't think it's that big of a change.
<mbgower> Sure, i can live with that.
Rachael: Anyone who can not live with that wording?
<GreggVan> right
<Fazio> I feel like it makes the same point
Alastair: 4.1.2 doesn't link to "state" as a definition, was that an editorial decision?
<mbgower> Sure, that's fine. I can live with it.
<alastairc> I can live with it.
Gregg: If it's the first instance, it should have been linked. That's an editorial oversight.
<david-macdonald> I can live with it
Rachael: Can anyone not live with the revised wording?
<bruce_bailey> as noted on GitHub issues , i agree use of "state" in 4.1.2 should be linked to defined term
<Rachael> proposed RESOLUTION: Adopt the revised wording "Contrast: The area has a contrast ratio of at least 3:1 between the colors when the component is focused and when not focused."
<GreggVan> +1
0
<jenniferS> +1
<mbgower> +1
<JF> +1
<bruce_bailey> +1
<Fazio> I can live with it
<ShawnT> +1
<kirkwood> +1
<Rain> 0 I can live with it
<Rachael> 0
<JakeAbma> 0
<alastairc> +1 to make progress.
Resolution: Adopt the revised wording "Contrast: The area has a contrast ratio of at least 3:1 between the colors when the component is focused and when not focused
Focus indicators for large editing areas #2017
<Rachael> https://
See PR link
Rachael: Discussed earlier
Alastair: A few week ago, we talked about situation with something like Google Doc where there is a very large editing pane...
… we did not want to add an exception, since that complicates a longer SC
… we had further discussion and decided we could better address by a little different scoping in the phrasing
… link provide in earlier version of survey was corrected Friday.
Rachael reads one editorial comment regarding "insertion point"
<GreggVan> insertion indicator
Mike Gower: I am happy to take action item, propose a new PR.
… insertion point is hard to replace, but i can add a bit more description
<Rachael> Propsed RESOLUTION: Adopt PR with slight addition to be made by Mike to explain insertion point
<mbgower> +1
Alastair: I would like to vote as-is, and an editorial improvement can be accepted later
<alastairc> +1
<Breixo> +1
<Rain> +1
<jenniferS> +1
<JakeAbma> +1
<Rachael> +1
<kirkwood> +1
<ShawnT> +1
<JF> +1
<david-macdonald> +1
<GreggVan> + 0 not fully grasping to abstaining
<GreggVan> so abstaining
Resolution: Adopt PR with slight addition to be made by Mike to explain insertion point
WCAG 2.2 Visible controls (questions added) https://www.w3.org/2002/09/wbs/35422/wcag22-visible-controls/results
<GreggVan> that is what happens when you keep focus ....
Exception may not align with understanding text #1980
Rachael: this Visible Controls..
<Rachael> https://
Rachael: 1st topic is that exception may not align with other content, pls see PR which addresses
… 13 agree, 3 requests for adjustment
… bruce has reply to Gundula which we might com back too
… JF had accept with adjustment
JF: Please see comment.
<david-macdonald> There is an exception for skip links
JF: It is not clear how to provide cues to UI which is hidden
Rachael: reads Oliver comment verbatim, paraphrase is that this is not a best practice
Oliver: as a signted keyboard user, a common approach with web pages is to make an estimate how many tabs to press to get to content...
with an invisible skip nav link, that can really throw a user off
Rachael reads Gundula comment: <li>If the control is to enhance keyboard navigation. For example, a link that skips from the top of the page to the navigation could become visible only on focus.</li>
<Rachael> Topics: Remove/replace skip link example, difficulty with hidden controls
Rachael: Bruce comment was to Gundula, and a skip nav link being invisible is common pattern
<Zakim> alastairc, you wanted to speak to skip links
AlastairC: I agree that invisible skip nav links are somewhat problematic, and we have discussed that before, but is a bit OT for this SC...
… this SC is oriented to mouse-over hover behavior. So the exception is important and would not be appropriate to just not include it.
DavidM: removing exception threatens this SC, because of its long history and appreciation by screen reader community
<alastairc> If people wish to ban skip-links, please raise a separate issue...
DavidM: some of the large companies I have worked with are very reluctant to include visible "skip to main content" link at the very top of the page
… between these two audience, and threat to skip nav, this is a risk
Rachael: Gundula is not on the call at the moment, so I will reach out to her, see if she want to raise a new issue.
<Rachael> https://
<mbgower> This is the Understanding document.
JF: I appreciate Oliver's lived experience as a sighted keyboard user, but I can't understand how you might accurately routinely estimate the number of tabs stops
Gregg: Is this SC text or Understanding change?
AlastairC: PR is just for Understanding -- but that is because issue was raised that there was conflict with SC text.
Rachael: Please submit PR for SC text if you can.
Oliver: I am not proposing that we change SC text, I am just asking that we not include SkipLink as example.
AlastairC: We had people reading this new SC as banning hidden skip nav links, so without example, readers are left with that impression.
… we need to have Skip Nav example in Understanding, else we can expect much confussion.
<Rachael> proposed RESOLUTION: Accept PR 1990 and adjust other areas as needed
Rachael: I think we have addressed all comments, less JF comment on hidden controls, which is a different topic.
<ShawnT> +1
<OliverK> +1
<Rain> +1
<GreggVan> +1
<alastairc> +1
<Breixo> +1
<Rachael> +1
<JakeAbma> +1
<Francis_Storr> +1
<jenniferS> +1
Resolution: Accept PR 1990 and adjust other areas as needed
The first exception is difficult to understand #1760
Rachael: suggestion in issue is for rewrite
<Rachael> Proposed response: https://
AlastairC: There is a proposed response, but that is only to this example.
… There is movement to rewrite , just not this exact suggestion.
… The rewrite is open.
Rachael reads comments from survey.
<Zakim> JF, you wanted to note I pointed out a concern as well in my response
12 agree, 4 with adjustment
JF: Please see that I include discprency, see my final comment survey
JF: But information needed to identify controls must be visible when the controls are needed >>without hover interaction or keyboard focus.<<
… that says one cannot use hidden skip nav !
<Rachael> Draft RESOLUTION: Accept the response and address the issues raised in issue #1840
Gregg: I think we can say in a simplier way
… the shortcut we want to expose are exposed. Hover exposes shortcut. Command-Option-G could be a shortcut...
… command keys are not visible. Some short cuts are not visually obvious, and that is okay.
… double click is another example we would not prohibit
<OliverK> present
we will tackle this question at the top of the next call
<Rachael> trackbot end meeting