<ChrisLoiselle> scribe: ChrisLoiselle

TomasS: Joins Group and introduces himself on behalf of FiServ.

Silver timeline discussion

Chuck: Asks to have others introduce themselves. No other new people on call.
... Talks to Silver timeline plans and first public working draft being published. Each call over next weeks, presentations will be made on conformance models.

Presentations will be reviewed and commented on. In August, there will be a deep dive into conformance models.

Judy: The co-facilitators are not currently on call at moment, are they aware of this timeline?

Chuck: Yes, we had this discussion in Silver call this morning as well.

Judy: WCAG 2.2 is on a good track. We are looking forward to that.

I've been talking to Michael and the Chairs. The milestone for the first public working draft for Silver was in February. The working group expected something more comprehensive including conformance model.

Current concern is that there is not an updated timeline on first public working draft. Transparency is needed by W3C Process, for AC, and public. Balance with challenging issues TF is addressing.

Chairs were asked on what were the biggest barriers. Three timeline barriers include 1) WG familiarity--planning updates in WG meetings; 2) conformance model -- planning Deep Dive; 3) conformance model complexity—planning distillation.

Judy: Opens up her comments to questions.
... For schedule purposes, we've talked to various optimal schedules. My request to the chairs was can we get an updated schedule with Silver ? Then we'd be able to plan around timeline challenges.

<Rachael> Conformance proposals presented at the beginning of the next two meetings and a deep dive on August 11th

<Chuck_> July 28: Rachael Presents. August 4th, JF presents. August 11th, deep dive.

Chuck: Dates presented are for conformance model presentations

Revisit reflow question: Include 'down to' or not

Chuck: Shares screen on results of questionnaire on reflow updates for wcag 2.2.

Thanks Judy!

<Rachael> Survey results are at: https://www.w3.org/2002/09/wbs/35422/reflow-updates/results

<Chuck_> Jared at WebAIM: "We support the "down to" change because it addresses a notable gap that can impact some users with disabilities.

<Chuck_> Jared at WebAIM: "We support the "down to" change because it addresses a notable gap that can impact some users with disabilities.

<Chuck_> Jared at WebAIM: The vast majority of sites have at most a few breakpoints that would impact this - and if responsiveness is properly implemented to support a variety of devices and resolutions, it's likely that failures will not be present.

<Chuck_> Jared at WebAIM: For testing, I recognize that "down to" provides a nearly innumerable number of possible sizes that could/should be conceivably tested, but defining specific sizes for testing instead would still leave gaps, and would not really change the testing procedures or effort.

<Chuck_> Jared at WebAIM: Simply scaling the browser down slowly (or increasing zoom) will typically provide a highly sufficient test that would capture the vast, vast majority of possible failures.

<Chuck_> Jared at WebAIM: I suspect (and hope) that most entities and experts that do comprehensive accessibility testing are already testing "down to" as opposed to just "at". WebAIM certainly is.

<Chuck_> Steve Faulkner at TPG: "no pushback from me on the change, it has always seemed like the definition being 320 X 256 pixels only was a mistake.

<Chuck_> Steve Falkner at TPG: As far as tools are concerned if the definition is changed then tool developers will need to update to reflect."

<Chuck_> Alastair: It seems like the ‘how hard to implement’ aspect is a wash. You’re assuming (or seeing) that people who meet ‘at’ also meet ‘down-to’. (This is backed up by Nicaise’s statement.)

<Chuck_> Alastair: The crux seems to be the testing burden, for which I’d really like to hear from people who do lots of testing.

<Chuck_> Alastair: For us, we’re already testing it, we just can’t fail the in-between stages. It does come up though, I’d estimate that most issues caught are bugs or assumptions about portrait orientation, rather than bad-actors.

<Chuck_> Alastair: They are things that affect real users though, which is why we report them.

<bruce_bailey> thanks, that is very helpful to my personal comfort level

Rachael: Others were going to take action to gather data, did anyone do that?

Brooks: I have implemented a full testing procedure for reflow earlier this spring. I don't have any particular data to share. I absolutely agree I see the value of the down to. For implementation though, production teams had issues at first.
... I'm concerned on time to test and training etc. Has anyone else done this as well on the call?

<Zakim> Wilco, you wanted to mention upper range

AWK: On Jared's comments. We originally talked to testing two breakpoints but decided on one. In the webaim comment, I hear that people are already testing this. There are numerous breakpoints that someone could test for. Do vendors that companies work with do this already? I.e. breakpoint 2 of 6 fails, we'd fix it. However do we test every breakpoint on every page? What's the return on it?

Wilco: Since it is not a percentage, then we have a bound range. If it any bigger than 320 number, then it becomes an infinite number of tests.

<kirkwood> +1 to Wilco

DavidM: On testing, it increases liability in a big way. It is easy to miss if we need to test every break point. I think we need to go outside of the working group for comments on this as well.
... Lot more work on testing and not that many new faults found. Increased liability for testers would be a concern. We looked at this last go around too.

<Zakim> mbgower, you wanted to say Jared acknowledges this changes the effort for dev and test. It's not just a language clarification. Breakpoints?

MikeG: There would be strange behavior on scroll bars appearing at certain break points when they weren't needed. Reflow as it stands allows for issues getting through. Perhaps Jared could include this in next survey that goes out?

Chuck: For WCAG 2.2, we don't have time for getting more data and including in WCAG 2.2 release. Perhaps the next version could look at this.

<Chuck_> Straw Pull: +1 if you support changing "at" to "down to", -1 if you do not.

<david-macdonald> -1

<Brooks> -1

<mbgower> -1

<JustineP> -1

<Fazio> +0

<MarcJohlic> -1

<AWK> -1

<JakeAbma> 0

<Rachael> +1

<Mike_Pluke> 0

<Chuck_> -1

<Wilco> -1

<Sukriti> 0

<bruce_bailey> -1 on down to, base of last two commenters

<Nicaise> +1 for down to

<JF> -1

I see 2 positives, 9 negatives with 4 0's

<GN015> +1

<Zakim> bruce_bailey, you wanted to ask DavidM about tester liability

Bruce to DavidM: On testing on liability against level AA , is that what you are stating ?

DavidM: This could be a new area of exploiting criteria. If budgets don't increase, increased liability would result due to limits in testing.

RESOLUTION: Consensus is to not change "at" to "down to", and to review possible research and date for a later version.

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

DavidM, let me know if I wrote that as you stated ?

Question 1 - Adding fstorr's updates - border note in focus-visible-enhanced

<Chuck_> https://www.w3.org/2002/09/wbs/35422/2020-07-CWA/results

Chuck: 9 support, 2 asking for changes.

AWK: The sentence makes it difficult. I.e the border as a perimeter of a control's edge...perimeter can be around the interface or control. CSS has a border property, can this control that? Explaining each CSS property changes our position on explicitly stating things.
... I could live with it, but believe its not a good idea to do.

MikeG: I don't think we have to define border. The bigger the visible change, the easier it is for someone to see. I talk to stating that border does not reference the same CSS property of the same name.

FrancisS: I worked on Alastair on it , if there are changes we need to be made, we can look into it. It was based on feedback we got.

MikeG: I worked off the diff and made changes off the diff.

Chuck: I like what you are recommending here.

<Chuck_> Poll: +1 if you support MG's proposed changes. -1 if you do not.

<Mike_Pluke> +1

<bruce_bailey> +1 for MG proposed changes

<Chuck_> +1

<Francis_Storr> +1

MikeG's comments: Recommend: The bigger the visible change, the easier it is for someone to see. Authors are encouraged to make the change as large as possible, for example, by designing a thick border around the element, or significantly changing the background color.</p> <p class="note">A border is the perimeter of control, and defines its shape. A border is not a reference to the CSS property of the same name.

<MarcJohlic> +1

<kirkwood> +1

<Chuck_> The bigger the visible change, the easier it is for someone to see. Authors are encouraged to make the change as significant as possible, for example, by designing a thick border around the element, or significantly changing the background color.</p>

<AWK> -.25

<Chuck_> <p class="note">A border is the perimeter of the control, and defines its shape. A border is not a reference to the CSS property of the same name.

<JF> 0

<Jennie> +1

AWK: If we kept this , I'd vote for MikeG's however I don't think it is needed in general.

JF: I'm ok with the grammatical change. However, I don't think it is actionable or measurable. I.e what is measurable? Larger / bigger?

<bruce_bailey> agree with JF that "bigger the visible change" is a little awkward

RESOLUTION: Accept MG's proposed changes to focus-visible-enhanced.

Question 2 - Focus appearance rewording of bullet 2 #1212

<Chuck_> "Change of contrast: The color change for the focus indication area has a contrast ratio of at least 3:1 with the colors of the unfocused state."

Chuck pastes in MikeG's comments

MikeG: Talks to specific change of "Change of contrast:

<Chuck_> POLL: Do you accept Alastair's proposed text for question 2? "Change of contrast: The color change for the focus indication area has a contrast ratio of at least 3:1 with the colors of the unfocused state."

<Chuck_> ac dav

DavidM: I'm wondering about if we have a button. White background with black focus indicator , does contrast have to be present on focus?

MikeG: Focus indicator needs 3:1 . DavidM: I received my answer to the question.

Sukriti: The color of the button is same color as focus indicator, this would pass based on 2 pixel size. Maybe we can look at other use cases to decide that.

<Chuck_> POLL: Do you accept Alastair's proposed text for question 2? "Change of contrast: The color change for the focus indication area has a contrast ratio of at least 3:1 with the colors of the unfocused state."

<mbgower> +1

<Sukriti> +1

<bruce_bailey> +1 for Alastairs edit

<Chuck_> +1 if you support the change, -1 if you do not.

<Nicaise> +1

<kirkwood> +1

<JustineP> +1

<Brooks> +1

<Chuck_> +1

<Mike_Pluke> +1

<JakeAbma> +1

<david-macdonald> +1

<Rachael> +1

<Francis_Storr> +1

RESOLUTION: accept Alastair's proposed text change for question 2.

<JF> +1

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

Chuck, I lost you.

<Brooks> scribe: Brooks

<ChrisLoiselle> Thanks, Brooks.

Rachael: 11 approved, and one person who said they'd like something else

mbgower: think that change to second bullet should be part of this issue. The contrast/thickness seems like an exception to SC 1.4.11. I suggest a note to clarify.

<JF> +1 to *focus indication*

mbgower: the focus indicator change could make it not visible against the background color

<david-macdonald> +1

Sukriti: Black button on white background. Black button grows three pixels against the background. That would pass. I like "against the adjacent background color" and not just "against the adjacent color."

Rachael: Mike Gower, what are our thoughts?

mbgower: change to second bullet, and add the note

<Sukriti> I will condense + add 2nd bullet change + note

<Rachael> Straw Poll: Accept this with a change to the second bullet, some condensing and addition of Mike G's note

<david-macdonald> +1

<mbgower> +1

<Rachael> +1 if you are comfortable, -1 if you want to see this edited response back

<bruce_bailey> +1 with edit, do not need to see response

<JakeAbma> +1

<Mike_Pluke> +1

<JF> I'd like to see final language

JF: Generally in favor of the direction we are headed. But, want to see the final language.

<Sukriti> yes

<Sukriti> my pleasure

RESOLUTION: Leave Issue 1156 "Loophole in SC2.4.11 allows almost invisible focus indicators" open and revisit next week with revised text

Question 4 - Review and approve response to GitHub issue 1067 "2.4.11 Focus Visible (Enhanced) Remove F78 and F55"

<bruce_bailey> is proposed response on GitHub or just in survey?

<bruce_bailey> Question 4 URL: https://www.w3.org/2002/09/wbs/35422/2020-07-CWA/results#x952

Chuck: The issue is about how it is written, F78 and F55 don't apply to SC 2.4.11. Everyone seemed to support excluding these in survey. Any objections to removing?

RESOLUTION: Accept response to GitHub issue 1067 "2.4.11 Focus Visible (Enhanced) Remove F78 and F55"

Question 5 - Review and approve response to GitHub Issue 1049 Language of 1.4.10/Reflow exception seems broader than intended

<bruce_bailey> https://www.w3.org/2002/09/wbs/35422/2020-07-CWA/results#x1064

<Chuck> "Examples of content which requires two-dimensional layout are images, maps, diagrams, video, games, presentations, data tables, and interfaces where it is necessary to keep toolbars in view while manipulating content. [ins]It is acceptable to provide two-dimensional scrolling for such parts of the content.[/ins]".

Chuck pastes Mike Gower's response into IRC.

<david-macdonald> +1

Chuck: Detlev commented, but isn't on the call.
... JF, do you want to respond to your comment?

<Chuck> "Examples of content which requires two-dimensional layout are images, maps, diagrams, video, games, presentations, data tables, iFrames and interfaces where it is necessary to keep toolbars in view while manipulating content. [ins]It is acceptable to provide two-dimensional scrolling for such parts of the content.[/ins]".

JF: If you are navigating a multirow, multicollumn table, you are navigating in two dimensions. The content inside of an iframe may also have 2 dimensional scrolling, as well. Want to be more explicit and inclusive as possible.

<JF> minor editorial suggestion: s/which requires two-dimensional layout/which may require two-dimensional layout

<Zakim> mbgower, you wanted to say that data tables is already there

mbgower: The data tables part is already in there. I don't think we have to make the exceptions list exhaustive.

<kirkwood> +1 to Gundula

GN015: If we add iframes as an exception, people can get around the intent of this SC by putting everything inside of an iframe.

JF: I like to include "may" include 2 dimensional layout. iframe seemed to be missing from this list.

Chuck: Is the iframes an issue you can't live without, JF? Right now, this list is only excluding iframes. It seems to me a matter of completeness.

mgbower: The language around 2 dimensional content seems redundant. Less is more. A couple of examples is fine with me.

<Zakim> mbgower, you wanted to say this is all existing text. We are debating an addition.

Francis: Not all images are required for understanding.

<Chuck> +1 mb

mbgower: want to focus on this additional sentence I requested?

<bruce_bailey> +1 w/ francais comment to drop "image" and list types of informative images where x/y scrolling really is needed

<bruce_bailey> +1 to mb comment to focus on addtion

Chuck reads Detlev's comment in the survey.

Chuck: Does anybody object to mbgower's sentence addition?

<Chuck> "Examples of content which requires two-dimensional layout are images, maps, diagrams, video, games, presentations, data tables, and interfaces where it is necessary to keep toolbars in view while manipulating content. [ins]It is acceptable to provide two-dimensional scrolling for such parts of the content.[/ins]".

<JF> I can live with that

<bruce_bailey> that is a nice clarification

RESOLUTION: Accept response to GitHub Issue 1049 Language of 1.4.10/Reflow exception seems broader than intended

Question 6 - Update to reflow exception

Chuck: I think this topic needs to focus on the additional note that needs to be discussed on this topic.

<Chuck> Complex data tables have a two-dimensional relationship between the headings and data cells. This relationship is essential to convey the content. This Success Criterion therefore does not apply to whole data tables. However, cells within data tables should fit within the size requirement unless the cell contains types of content that also requires two-dimensional layout for usage or meaning.

Chuck: JF, are you supportive of the idea of just talking about this additional paragraph.

JF: Yes

Chuck: Is there anybody on the call who objects to accepting this paragraph, and only this paragraph. We had already address the other paragraph prior to this topic.

<Chuck> Complex data tables have a two-dimensional relationship between the headings and data cells. This relationship is essential to convey the content. This Success Criterion therefore does not apply to whole data tables. However, cells within data tables should fit within the size requirement unless the cell contains types of content that also requires two-dimensional layout for usage or meaning.

JF: In this one, there was the inclusion of individual cells, which I don't remember being in the previous topic.

mbgower: Acknowledge what JF just said.

JF: Want to make sure that we fully address the text that is parenthetically included in the previous paragraph, which was part of Question 6.

<Chuck> "Examples of content which requires two-dimensional layout are images, maps, diagrams, video, games, presentations, data tables (not individual cells), and interfaces where it is necessary to keep toolbars in view while manipulating content. [ins]It is acceptable to provide two-dimensional scrolling for such parts of the content.[/ins]".

Chuck pastes in newly combined text into IRC.

<Chuck> ac Bruce

<Zakim> bruce_bailey, you wanted to ask that we drop "images"

Chuck: If we were to accept the second paragraph, with the combined text, are there any objections?

Bruce: Shouldn't we drop "images" from the language?

<Rachael> Examples of content which requires two-dimensional layout are complex images, maps, diagrams, video, games, presentations, data tables (not individual cells), and interfaces where it is necessary to keep toolbars in view while manipulating content. [ins]It is acceptable to provide two-dimensional scrolling for such parts of the content.

<Rachael> option 2: Examples of content which requires two-dimensional layout are maps, diagrams, video, games, presentations, data tables (not individual cells), and interfaces where it is necessary to keep toolbars in view while manipulating content. [ins]It is acceptable to provide two-dimensional scrolling for such parts of the content.

<mbgower> option 2 +1

Rachael: The first option as "complex images" the second option has "images" taken out.

<Chuck> +1 option 2

<JF> Option 2 +1

<Rachael> option 1: Examples of content which requires two-dimensional layout are complex images, maps, diagrams, video, games, presentations, data tables (not individual cells), and interfaces where it is necessary to keep toolbars in view while manipulating content. [ins]It is acceptable to provide two-dimensional scrolling for such parts of the content.

<Rachael> +1 Option 2

<Francis_Storr> Alternative: "images required for understanding, for example: maps and diagrams".

<bruce_bailey> i am glad to see we are addressing franis earlier concern

<bruce_bailey> any of the choices are improvements

<Rachael> option 3: Examples of content which requires two-dimensional layout are images required for understanding (such as maps and diagrams), video, games, presentations, data tables (not individual cells), and interfaces where it is necessary to keep toolbars in view while manipulating content. It is acceptable to provide two-dimensional scrolling for such parts of the content.

Rachael pastes in Francis' third option.

<Chuck> +1 option 3

<bruce_bailey> +1 to option 3

Chuck: We have three options. Please +1 to any option you like.

<JF> +1 Option 3

<MarcJohlic> +1 to Option 3

<Rachael> +1 option 3

<Sukriti> +1 option 3

<Nicaise> +1 on 3

<JakeAbma> +1 option 3

<kirkwood> +1 to 3

<Mike_Pluke> +1 to option 3

+1 to option 3

<Raf> +1 to option 3

<StefanSchnabel> +1 to 3

RESOLUTION: Accept first sentence as amended and second paragraph in the question response.

Question 7 - Dragging movement glossary definition: Deleting reference to intermediate point

<bruce_bailey> +1

Chuck: The survey respondents overwhelmingly agree with the proposed update.
... Any objections to moving forward with the update?

<bruce_bailey> mb making a good point

<JF> I'm with Mike here

<bruce_bailey> drag-and-drop different than path-based gesture

mbgower: The reason why the "dragging movement" was in there to define a path-based gesture, when going through an intermediate point. Could cause confusion by removing this, which is part of a definition.

RESOLUTION: review and address next week.

<Rachael> Link to issues: 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%22Survey+-+Added%22

Chuck: Does anyone have a reponse you want to discuss with the group?

<bruce_bailey> https://github.com/w3c/wcag/issues/1213

Bruce: Just drafted a response to an issue related to color contrast. Issue 1213 related to New Color Contrast Formula.

<bruce_bailey> https://github.com/w3c/wcag/pull/1223

Bruce: want to make sure that I made the change correctly.

<bruce_bailey> https://www.w3.org/WAI/WCAG21/Techniques/general/G18

Chuck: I believe you've done what was expected.

<bruce_bailey> okay, expecting to see this on survey next week !

Sukriti: Waiting for response for commenters if it is OK to close issues based on our responses.

Chuck: Any volunteers for taking up additional comments for review?
... Any topics anyone wanted to address that we haven't discuss thus far?

mbgower: I have a had chance to look at the issue of removing "dragging motion." I'm OK with the language change. It's fine to exclude the idea of not dragging through an intermediate path, because this is a wider scope at the AAA level.

<Sukriti> I took this one - https://github.com/w3c/wcag/issues/392 (Timeouts) should be for all websites

rrs agent, make minutes

This is scribe.perl Revision of Date 
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: Irssi_ISO8601_Log_Text_Format (score 1.00)

Succeeded: s/The first public working draft/The milestone for the first public working draft/
Succeeded: s/Transparency is needed for broader view of what is needed for 3.0./Transparency is needed by W3C Process, for AC, and public. Balance with challenging issues TF is addressing./
Succeeded: s/One thing in particular was request for deep dive on conformance model to be aligned./Three timeline barriers include 1) WG familiarity--planning updates in WG meetings; 2) conformance model -- planning Deep Dive; 3) conformance model complexity—planning distillation./
Succeeded: s/Leave open and revisit next week with revised text/Leave Issue 1156 "Loophole in SC2.4.11 allows almost invisible focus indicators" open and revisit next week with revised text/
Succeeded: s/addressing francis option/addressing franis earlier concern/
Default Present: JakeAbma, Rachael, jon_avila, Nicaise, Raf, OmarBonilla, StefanSchnabel, Brooks, Gundula, ChrisLoiselle, Francis_Storr, Mike_Pluke, kirkwood, JF, JustineP, Sukriti, bruce_bailey, Fazio, MarcJohlic, Jennie, david-macdonald
Present: JakeAbma Rachael jon_avila Nicaise Raf OmarBonilla StefanSchnabel Brooks Gundula ChrisLoiselle Francis_Storr Mike_Pluke kirkwood JF JustineP Sukriti bruce_bailey Fazio MarcJohlic Jennie david-macdonald
Regrets: Brooks_Newton Charles_Hall Laura_Carlson Detlev_Fischer Steve_Lee Alastair_Campbell
Found Scribe: ChrisLoiselle
Inferring ScribeNick: ChrisLoiselle
Found Scribe: Brooks
Inferring ScribeNick: Brooks
Scribes: ChrisLoiselle, Brooks
ScribeNicks: ChrisLoiselle, Brooks

WARNING: No meeting title found!
You should specify the meeting title like this:
<dbooth> Meeting: Weekly Baking Club Meeting


WARNING: No meeting chair found!
You should specify the meeting chair like this:
<dbooth> Chair: dbooth


WARNING: No date found!  Assuming today.  (Hint: Specify
the W3C IRC log URL, and the date will be determined from that.)
Or specify the date like this:
<dbooth> Date: 12 Sep 2002

People with action items: 

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