Meeting minutes
<sajkaj> New web page is at: https://
<Chuck> https://
<ChrisLoiselle> I can help whenever needed on scribing.
Chuck: We have two individuals who can scribe
… New topics?
<AWK> +AWK
JakeAbma: I have been working with people who have been learning WCAG. It might be good to spend time on Github issues/incomplete Success Criteria or Techniques
… When it is time to do something about these issues? There are hundreds of issues/pull requests. It helps people understand the criteria better if we address them.
Chuck: I don't want us to delve into that topic right now, but we'll address it in tomorrow's call
TPAC is Oct 2021, breakout sessions? https://www.w3.org/wiki/TPAC/2021/GroupMeetings (5-10 min)
Chuck: Clarification -- in our planning call
<Zakim> mbgower, you wanted to say I put a comment in the review of the Explainer, but it's really a 'new topic' for 3.0: Reporting transparency
<JF> a HUGE +1 to Mike
mbgower: This is a new topic. There's a new area of that should be covered in 3.0
<alastairc> Bruce - we'll discuss at the planning meeting tomorrow, not much more to say now
Chuck: Technical Plenary Advisory Committee (TPAC) has announced that this year's event is remote
… Do we want to host any breakout sessions? Do we want to join any other groups' breakout sessions.
<Zakim> sajkaj, you wanted to say APA will likely ask for joint
sajkaj: There are Accessible Platform Architecture working group will likely want a joint session.
Chuck: Do we as a group want to meet with the other teams and host a breakout?
<Zakim> JF, you wanted to ask about EO?
mbgower: Should we be thinking about anything related to 2.2 release?
<Zakim> jeanne, you wanted to say WCAG3 and Immersive Captions
<JF> @Ben Education and Outreach - another work group under the WAI umbrella
<jeanne> +1 to meeting with EO
<alastairc> alastairc: Not anticipating much to do on 2.2 at TPAC, it is more backlog-type work.
JustineP: Should we work with COGA? They have a subgroup on mental health.
Chuck: Other suggestions?
<jeanne> +1 to meeting with COGA mental health group
alastairc: Are there any groups or individuals that are experts on how audio affects individuals?
WCAG 3.0 Explainer survey https://www.w3.org/2002/09/wbs/35422/WCAG30-Explainer/ (20min)
<mbgower> You may want to ask about musicogenic seizure
Chuck: Any other ideas? Moving on
<Chuck> https://
WCAG 3.0 Explainer survey
<laura> Getting "Not allowed" for link
<bruce_bailey> Any one else having trouble opening results link?
<Chuck> https://
Chuck: Explainer for WCAG was drafted. Please review the editor's draft of the WCAG 3.0 explainer. Let's review recommended changes
<laura> I'm getting "You're not allowed to see the results of this questionnaire."
<ToddLibby> Also getting a "Not Allowed" page here.
<jeanne> +1 to Justine's comments
<sajkaj> I believe Explainer would be entirely informative by definition.
JustineP: One point of feedback is something we don't need to review at this time. Content is informative explanation added.
<JF> WFM
<laura> Works now thanks!
<johnkirkwood> it is working
Chuck: I granted access to everyone to view results.
<ToddLibby> Yes, thank you Chuck.
Chuck: Anything you want to call out Bruce?
bruce_bailey: When I make edits, I see that I may not be aligned.
Chuck: How can we help you understand?
… Is there anything here you wanted to call out specifically, Bruce?
<mbgower> I would not call Bruce's changes 'editorial' in the sense of being typos. They are substantive
<Zakim> jeanne, you wanted to comment on Bruce's edits
jeanne: My understanding of what Bruce is saying is that the outcomes are not in passive voice because of recommendation from COGA to use plain language. Bruce wanted to add passive language to make things more testables.
<Zakim> alastairc, you wanted to ask whether it "explains" the current status
<sajkaj> Are we sure about "passive?" Do we maybe mean "modal?"
<bruce_bailey> i agree with avoiding passive voice
alastairc: They strike me as questions for the spec and not explainer.
<sajkaj> e.g. modal "can, would should, etc"
Chuck: I think the comments you made have been addressed. Did you want to discuss anything else?
bruce_bailey: It's still less clear than it would be in passive voice
Chuck: You had some suggestions
alastairc: We have some broken links, definitions that need to be fixed etc.
mbgower: I tried to make a separate branch. I couldn't find this branch when I was editing. Other than that, my comments are self-explanatory
Chuck: Would it be faster for you to make changes, Jeanne?
jeanne: Mike should be granted editor access.
<mbgower> I don't think that's the issue, Jeanne. I can create a branch in that repo
New Errors Guideline https://raw.githack.com/w3c/silver/srayos/error-prev-index-2/guidelines/index.html#error-prevention
Chuck: New Errors Guideline: Sarah -- what we're hoping to do is get an introduction to the process used to get the new guideline. We'll put out a survey to have team review new guideline.
<jeanne> https://
sarahhorton: How we got here is a little bit of a complex process. This is the first formal errors document shared by the Silver Task Force. This is the content that will go in the next working draft. It has a guideline and outcome. Chuck has the pull request. We'd love to have suggestions and feedback.
<Chuck> Juanita: Could you send a non google docs version? Google docs is blocked by my company.
sarahhorton: Happy to explain how we got here later. There's a method we followed. We were able to base it off of previous guidelines. Text alternative guideline has an outcome with methods. So now if I go back to the Google doc, we have the same sections we're working on with several sections, following a template. We're looking at web technologies and to summarize the method, we have a list of ways this method is actuated.
… In the section about user needs, we describe how this solves user needs.
… So those are some bits of content from that initial tab panel. In the description tab panel, we talk in more detail about what's needed.
… And then the third tab in that tab panel component, we provide examples.
… The next component is tests, where we break down the method into specific tests.
… With this method there are four tests. And then the last section is scoring--
<jeanne> Link to the MS Word document version that I mailed to the AG list. https://
Chuck: I had a question. I remember our last TPAC where we were talking this.
sarahhorton: This isn't clearly defined in WCAG 2x
<Zakim> mbgower, you wanted to say can Sarah comment on challenges of precision versus understandability? e.g., "Instructions available at the source of input"
Chuck: Mike has a question
mbgower: This is interesting work. Question about the challenges of precision versus understandability? e.g., "Instructions available at the source of input." Did you find this to be a challenge?
sarahhorton: I think we went with what made sense. Striking a balance.
Chuck: Let's get into scoring
sarahhorton: We have identified many user needs and will work on them in addition to the one shown.
… Scoring is a calculation of total possible credits.
… Score is a calculation of total credits/total possible credits
<Zakim> AWK, you wanted to ask about adjacent requirement
Andrew: Question about adjacent requirement -- How did we come to the conclusion that the error has to be adjacent vs. sufficiently linked?
sarahhorton: The reason that adjacency became what we addressed is because adjacency is a user need that needs to be met.
Andrew: Do we have research on this?
sarahhorton: I would say yes. We have people who have completed research and testing. These are the conclusions we came to based on that research. We haven't tested every pattern.
alastairc: From Andrew's comment, I think we need to provide evidence for new content. We should keep that in mind.
Chuck: Point of order: Bruce pointed out a concern with something being reviewed next week. Alastair to respond.
sarahhorton: You can have multiple outcomes in a guideline. There's a link that will go to that method, and information about errors. There are two for this requirement.
… We also have instructions regarding sensitive information. This is where the scoring comes in. The rating is for the outcome and there are different ranges of scores for different ratings.
<Zakim> JF, you wanted to ask about "Purpose of Inputs"
JF: Question about "Purpose of Inputs": The techniques we have for this also may apply, so can we integrate that with this?
sarahhorton: Yes, but we haven't incorporated them yet.
JF: That could have an impact on your score.
sarahhorton: Yes, this score is just for the one method.
JF: When we talk about it being an additional method, is that added to the total score? How would this work?
sarahhorton: As we build out the content, do all of the methods need to be enacted or could a developer pick one and cover them all?
… There are 52-53 user needs.
<ChrisLoiselle> too fast, thanks Mike
David MacDonald: I want to confirm our current process. Right now, we are examining an example of how we could proceed?
Sarah: We're not thinking about success criterion. We're doing guidelines, outcomes and methods. The structure is quite different.
Sarah: The way the silver group has presented this work is also a departure from 2.x. It's not looking at 2 and figuring out how to rejig. It's going back to user needs and flows, and building from there.
Chuck: What you said is true plus... We are trying to make it work. The goal is that this particular guidance will make it into the next draft. It is both an experience in doing the process and producing content for 3
David MacDonald: I get there are new ways we're doing this. I'm just wondering: what is on the table to explore in terms of changing. Is it everything? Has the train left?
David MacDonald: As an evaluator, if I'm spending time documenting what they've done properly, then I'm using a lot of my time and their money that doesn't improve things.
<Zakim> jeanne, you wanted to talk about ships sailing
<Chuck> +1 to jeanne
Jeanne: Particularly on scoring and counting, the ship (or train) has not sailed.
Jeanne: We're spending time building up the value of 3, so it isn't just opinions, it is data.
Jeanne: This also helps us identify flaws.
Jeanne: We are using 5 metrics to evaluate the scoring, taken from research symposium, one of which is complexity (how difficult is this to test). But we need more data to assess.
Jeanne: We need more SCs migrated over so we have more data to evaluate the scoring. That's why i've wanted to work more on actual content.
David MacDonald: This is a proposal and we're evaluating it. is there a secondary? What would be great would be 'here are 3 ways of doing it': count, not count, a third way.
David MacDonald: The more we talk about exploratory, the more those become hardened.
David MacDonald: I love a lot about 3, including tagging. I am just worried about the testing.
<Zakim> alastairc, you wanted to highlight next week's exercise
Alastair: We have a meeting next week on headings. That is proposed as a critique of that.
Alastair: The one aspect that is there to be iterated on is a 0-4 rating as what a guideline wraps up to, however under that it could be quite different..
Alastair: We can review multiple proposals to get there.
Chuck: Silver examined a number of scoring methods. We are trying to emphasize that any past decisions get honoured, and we not open those up again.
<Zakim> Chuck, you wanted to answer the question of different proposals
David MacDonald: Can you clarify on that?
Jeanne: We're talking about from last summer.
<Zakim> mbgower, you wanted to say is a list of those decisions somewhere?
<ChrisLoiselle> MG: Is there a list of decisions , regarding context of feedback?
<Zakim> AWK, you wanted to say that until we finalize the conformance model and scoring I wouldn't regard anything as carved in stone.
AWK: Those are good questions. David I have the same.
<jeanne> Silver Decisions page
AWK: There was a lot of work done. I would say until we have the conformance model at the point where we're all in agreement of how it works and the scoring works, just about everything in the standard is going to cascade.
AWK: I wouldn't worry about things that can't be commented on.
Chuck: Sarah, anything else you want to discuss?
Sarah: I'm glad we made it through all the components. It is in more ways more understandable through the web interface, and Chuck was going to share that?
<Chuck> https://
Chuck: This is what is in the PR in the same format.
Chuck: Since time is short, we will be putting out a survey seeking feedback.
<MelanieP> Is the Outcome link supposed to work? I get a 404
Chuck: I came to Sarah yesterday about this. I appreciate what you put together on short notice.
Introduce the new group homepage (5 min)
Chuck: We are working on addressing the links that don't work.
<MelanieP> thanks!
<Chuck> https://
Chuck: Michael had an emergency and is unable to attend.
Alastair: I think the idea was that rather than the WAI homepage, this is essentially an automatically updated version.
Alastair: I've asked if we can get our wiki home page more prominent.
<Chuck> mike: I don't see it stating when we meet. Needs to include that information.
<bruce_bailey> very nice, seems to be pulling photos etc from github
Jeanne: The calendar tab is where we would have our meetings. i think there's a new w3c calendaring tool, and this is an automated way of pulling that.
<ChrisLoiselle> MG: Silver has idea of highlighting participation , is there any plans for AGWG?
<Chuck> mg: Silver has this idea of highlighting participation in a more granular fashion. Any plans on that for our group?
<Chuck> mg: We have chairs, staff... any notation of active participation?
<ChrisLoiselle> MG: I.e. chairs, staff, participants vs. active participants ?
<Zakim> sajkaj, you wanted to note Calendaring includes agenda
Sajkaj: Calendaring also includes agenda planning. You may want to make sure you can look ahead.
Alastair: It appeared it would email everyone in the group, even for testing.
Sajkaj: There should be a test mechanism. This is all beta. It's worth commenting on.
<ChrisLoiselle> calendaring issue tracker https://
<sajkaj> Cheers, all!
WCAG 2.x issue resolutions (Q1-4) https://www.w3.org/2002/09/wbs/35422/WCAG22-Misc-items/ (30 min)
Chuck: there are four questions
<Chuck> https://
Question 1 - Does the adjacent color clause of SC 1.4.11 apply inside components? #1775
Alastair: We didn't get too many people replying, which I think suggests not too many got through the issues.
Alastair: Jon Avila raised an issue about non-text contrast
Alastair: We went through a lot of discussion, and nearing publication, we came to a decision that a button with a light background shouldn't fail.
Alastair: We don't distinguish contrast between states, because they aren't adjacent to each other.
Alastair: Jon brought up an interesting case... [sharing screen]
Alastair: We haven't covered a situation where inside the component there is a change in appearance with adjacency which can be measured.
Alastair: I came up with examples where people can agree whether it fails.
Alastair: Another one came up on 1.4.1 Use of Color
Chuck: I've never identified use of color and focus visible in the same context. it's not one I've been failing.
Chuck: That's one opinion.
<alastairc> 1.4.11 if they are adjacent to the background of the component.
Alastair: Because people haven't survey, maybe we can have a couple of quick polls?
<alastairc> +1 if it is covered, -1 if not, 0 if not sure
<david-macdonald> Yes
<david-macdonald> +1
<Ben> +1
<Chuck> 1
<JustineP> +1
<Jaunita_George> +1
<AWK> 1
<JakeAbma> 1
<Francis_Storr> +1
Alastair: These are all about the focus indicator
<JF> 0
<KarenHerr> +1
<laura> 1
<bruce_bailey> 0
<ToddLibby> 0
<alastairc> Is the focus indicator covered by 1.4.11 if the change provides an adjacent color to compare inside the component.
+1
<david-macdonald> no, because the Focus indicator becomes part of the button
<Ben> +1
<bruce_bailey> +1
<JustineP> +1
<AWK> -1
<MelanieP> -1
<laura> 0
<Chuck> 0
<johnkirkwood> 0
Alastair: We have a mix of results. David, can you expand on your comment?
<Jaunita_George> 0
<JustineP> changing my response to a 0, I need to give it more thought
<Francis_Storr> 0
<Regina> +1
David MacDonald: My understanding is that as soon as the focus indicator is inside the button, you're only talking about the button's contrast.
<ChrisLoiselle> I believe figure 5 on https://
<Chuck> mg: I would argue against, the actual wording is <reading wording> 3:1 against adjacent colors.
<Chuck> mg: If the focus indicator is inside the button, the adjacent colors for that state are the background colors of the button itself. I believe it's in scope.
Alastair: I'm being devil's advocate... All states... Where the entire background changes, it doesn't fail.
<Zakim> AWK, you wanted to cite "For user interface components 'adjacent colors' means the colors adjacent to the component. For example, if an input has a white internal background, dark border, and white external background the 'adjacent color' to the component would be the white external background."
Alastair: It seems a bit strange, either way we go.
<Chuck> mg: Andrew covered what I remembered. That's why we came up with the definition of focus appearance. I do think we've got ourselves covered in focus appearance if not in scope for non text contrast.
Alastair: There are people who have been failing this under Non-text Contrast (since Focus Appearance in 2.2 isn't out yet).
AWK: I think the thing this all hinged on was the contrast was being evaluated for each state against adjacent colours of the component. That's why this made it more challenging. Part of me still doesn't buy that.
:)
MG: Thinking about this , focus visible is an option to use 3:1 ratio by cross citing 1.4.11
MG: We cross referenced this in the intent.
Alastair: Talks to 2.4.7 focus visible must have sufficient contrast against the adjacent background when the component is focused.
… other people may not read it that way.
… If looking at the checkbox, the tick of checked is the state of the control , figure 4
DavidM: Echo what Alastair stated. My understanding was around component level. For checked state, yes for sure.
MG: The checkbox is a real grey area on this, i.e. is it a graphical object?
Can you see the check graphic ? Is that a fail of 3:1 , a cake and eat it too scenario.
<AWK> I'd say no to checkbox being graphical object. Clearly a UIC to me.
Alastair: Option would be to refine the understanding documentation , regarding state such as checkboxes, down arrows, accordions etc.
<johnkirkwood> +1 to AWK
If it is within the component, it is not within the scope
We'd need to also update focus appearance
Chuck: We can vote on what to update if you'd like
<Zakim> JF, you wanted to also circle back to default styling of focus indication when the user has modified the background color
JF: Alastair and I talk to this . I continue to struggle with user keeping the native tab focus (blue halo) on chrome and allow for this to pass .
Alastair: We talk to default indicators , talking to browser needs in user agent and talk to it in 2.2 in focus appearance. I don't think revisiting in non text contrast is an issue.
JF: Fair enough.
Alastair: Do we include focus indicators within the component , within the scope of non text contrast?
<JF> yes
<alastairc> Poll: Do we include focus indicators that are within the component within the scope of 1.4.11?
<Chuck> Yes
<Francis_Storr> +1
DavidM: When we read the text, the text provides argument for JF's position. I.e. inside a box. Without understanding that this becomes part of a component is a strong argument.
Melanie: Do I understand that the proposal of this discussion would contradict 1.4.4 ?
DavidM: The reason it would fail would be between the pre and post focus state. The adjacency of the control would be the fail.
Melanie: If you change the colors, doesn't that affect it?
<Zakim> mbgower, you wanted to say the following exists: "For visual information required to identify a state, such as the check in a checkbox or the thumb of a slider, that part might be within the component so the adjacent color might be another part of the component."
MG: Talks to adjacent contrast and that it is required .
<alastairc> Poll: Do we include focus indicators that are within the component within the scope of 1.4.11?
Chuck: Poll, Do we include focus indicators within the component , within the scope of non text contrast?
<Chuck> Yes
<david-macdonald> no (based on previous interpretation)
<MelanieP> No
<mbgower> Yes "In combination with 2.4.7 Focus Visible, the visual focus indicator for a component must have sufficient contrast against the adjacent background when the component is focused, except where the appearance of the component is determined by the user agent and not modified by the author."
<johnkirkwood> No
<laura> no
<Ben> No -
<ToddLibby> no
<bruce_bailey> no
Chuck: No seems to be prevailing answer. Does this provide you with enough to update this Alastair?
<Zakim> mbgower, you wanted to say another Understanding doc reference (posted) is explicit about this. Where it is in Focus Visible or not is a question.
Alastair: Anything that doesn't have a "done" label is available to review in a future conversation.
MG: Talks to explicit visual focus indicator text .
DavidM: Focus on the button or the background?
MG: I think combined with the adjacent color, it isn't just the outside edge we are talking about.
JF: I believe what we are dealing with is the focused state is part of the component , at the core issue. If a component takes focus , is that part of the component?
MG: I know what my answer would be.
<mbgower> +1 to David
DavidM: I think this shows why we did another SC. It has issues. We realize we needed to work on it.
rrsagent make minutes