W3C

- DRAFT -

AGWG Teleconference

16 Aug 2022

Attendees

Present
Wilco, bruce_bailey, GreggVan, JakeAbma, Detlev, Caryn, MichaelC, maryjom, AWK, alastairc, Rachael, MelanieP, Laura_Carlson, ToddL, Fazio, Peter_Bossley, ShawnT, GN015
Regrets
Makoto Ueki, Azlan Cuttilan
Chair
Chuck
Scribe
Detlev, Caryn, AWK

Contents


<Chuck> meeting: AGWG-2022-08-16

<Chuck> Break...

<Detlev> scribe: Detlev

<AWK> +AWK

Chuck: There will be a ten minute break mid call
... any announcements, or new roles?

WCAG 2.2 Flash Definition Updates https://www.w3.org/2002/09/wbs/35422/PSE-updates

<Chuck> https://www.w3.org/2002/09/wbs/35422/PSE-updates/results

Chuck: (reading first survey question / flash update)
... content mainly added to Understanding doc

11 respondents agree with PR

Chuck: anyone with a comment wants to expand on it?

Gregg: opinion it should not be errata but content proper of WCAG 2.2

Bern: there is a change of technology, errata would change history, this is technology based - thats why the date seems old

Melanie: Can you give answer whether no content in a note is informative or normative - there where different opinions on that?

Wilco: Was confused by survey - update seems just to reove two brackets?

Rachael: COncern of not putting it back into 2.1 is that people will continue to refer to 2.1

<Zakim> alastairc, you wanted to clarify for wilco

<MichaelC> qq+ to address errata and notes

Alastair: @Wilco: there is an additional sentence (reads it) not so obvious in the PR

<Zakim> MichaelC, you wanted to react to alastairc to address errata and notes

<MichaelC> https://www.w3.org/TR/WCAG22/#interpreting-normative-requirements

<MichaelC> https://www.w3.org/2021/Process-20211102/#correction-classes

Michael C: Notes are informative, not normative - changes in notes via errata - these would be correction that would not affect conformance, so it would be easy to re-publish

Melanie: So updates to understanding docs no errata are necessary but notes in SC are informative but mist go through errata?

<Zakim> GreggVan, you wanted to answer ERRATA question

Michael C: correct

Gregg: Understanding is just informative notes, not part of standard proper

Question 1 - Approve changes from previous meeting

Gregg: you have to go through a process if you want to include errata to the normative parts of the spec

<alastairc> I think a confusion is that Gregg is talking about informative changes to normative text, i.e. don't change the meaning. ...definitions: errata mostly do not include normative changes

<AWK> Choices: 1) call it an errata even though it isn't really 2) implement in WCAG 2.2 only, affecting backward compatibility 3) Understanding document

<Zakim> alastairc, you wanted to mention WCAG 2.2/2.1 differences in understanding docs.

AWK: Our choices are as I indicated in IRC above

<Zakim> GreggVan, you wanted to say Maybe add to 2.1 but not 2.0

Al: there cna be differences between 2.0 and 2.1 but we try not to - should be errata to 2.1 to keep understanding docs aligned

<alastairc> Also, 2.1 was 2018 so not *that* long ago.

Gregg: Most people will refer to 2.1 today so that sounds OK

Chuck: so errata should be appleid just to 2.1 not 2.0 correct?

AWK: But 2.0 is the basis of section 508 and others - separating out 2.0 and 2.1 does not make sense - if it changed, it should be changed all the way back or just apply to Understanding doc

<Zakim> alastairc, you wanted to say this isn't normative text

MaryJo: Agree with AWK - there are different bodies using 2.0 still so it is not a good idea to make errata apply to 2.1 only

<Zakim> GreggVan, you wanted to agree with AWK and to argue for both 2.1 and 2.0 to confirm forward compatibility

Alastair: No problem to apply it to both - may highlight dated aspect of calculations - but if there is no understand doc change in 2.0 it may not be that helpful

<Chuck> proposed RESOLUTION: Accept PR 2567 and create an errata for WCAG 2.1/2.0 for the note update.

Gregg: Agree to treat 2.0 and 2.1 as aligned

<alastairc> +1

<Chuck> +1

<Wilco> +1

<maryjom> +1

Chuck: (reads out Resolution)

<GreggVan> +1

<AWK> +1

+1

<JakeAbma> +1

<MelanieP> +1

<laura> +1

<Rachael> +1

RESOLUTION: Accept PR 2567 and create an errata for WCAG 2.1/2.0 for the note update

<ToddL> +1

Question 2 - Update to the red-flash note on general flash and red flash thresholds

<Zakim> AWK, you wanted to suggest that we have an update note added to the WCAG 2.0 techs and understanding documents

AWK: The current understanding docs -there should be a link to amke it clear this is not the most current info
... it's for the chairs to discuss

Alastair: (summarising red flash aspect)
... a working definition - not a good definition, may no catch things flashing to and from red
... proposal to align it to def trhat ISO uses

Chuck: (reding out results of survey) - anyone wants to expand on comments?
... (reads Gregg's comment)

<AWK> +1 to Bern's/Gregg suggestion about moving the math to the U-doc.

<alastairc> I've created a PR for that proposal: https://github.com/w3c/wcag/pull/2619/files#diff-7d55230c0a1e745533159f1ec04838a8500acd8b56a530d66a3149101d0a7269

Bern: no additions avaliable for questions

Chuck: (reads Wilcos comment)

Wilco: elaborates on comment (too technicl for me to grasp / scribe :(

<Zakim> alastairc, you wanted to ask Bern about the XYZ aspect

Alastair: Question to Bern: about RGB...

Bern: When moving to color spaces you have to a lingua franca color space (cannot scribe that quickly enough)

<Zakim> GreggVan, you wanted to say change both to X and put in errata for past

Bern: explaining things about relative luminance and XYZ calculation...

Gregg: Most standards use Y instead of L
... bringing it in line with other standards makes it easier to read
... doesn't change any of the formulas, jsut labelling

Chuck: Doe sthat address your concerns, Wilco?

Wilco: We should not change the math - it is changing how we calculate relative luminance

Alastair: (reads the way it is phrased in the notes) - the proposal is to keept that similar but refer to ISO

<alastairc> The new working definition in the field for <strong>"pair of opposing transitions involving a saturated red"</strong> (from WCAG 2.2) is a pair of opposing transitions where, one transition is either to or from a state with a value R/(R + G + B) that is greater than or equal to 0.8, and the difference between states is more than 0.2 (unitless) in the CIE 1976 UCS chromaticity diagram. [ISO 9241-391]

Alastair: we are changing recommendation of how to calculate it but it will have hardly any affect on tools

Chuck: looking at an alternative PR (?)

Wilco: If most wnat this I can live with it
... cprrect it is rare in practice so hardly an impact

Alastair: needs to clean up PR a bit
... rest of calculation goes into understanding doc

<Chuck> proposed RESOLUTION: Accept PR 2619, review update L to Y at a later date

<Chuck> proposed RESOLUTION: Accept PR 2619 with the changed paragraph and the rest of the calculation goes into the understanding document. We come back with a change of L to Y later

<kirkwood> does that confliict with yellow?

<GreggVan> +1

<Rachael> +1

<Wilco> -.5

+1

<Chuck> +1

<ShawnT> +1

<bruce_bailey> +1

<laura> +1

<ToddL> 0

<Ben_Tillyer> 0

<alastairc> +1

<maryjom> +1

<JakeAbma> 0

<MelanieP> 0

<StefanS> 0

<kirkwood> 0

Melanie: Is the errata going straight into 2.2 or all of them?

RESOLUTION: Accept PR 2619 with the changed paragraph and the rest of the calculation goes into the understanding document. We come back with a change of L to Y later

Question 3 - Problems with WCAG 2.0 Flash Definition #553

Alastair: ANything we agree now goes straight into 2.2

Chuck (reads 3. Survey item)

<Chuck> proposed RESOLUTION: Accept PR 2591 as an errata for WCAG 2.1/2.0 (and include in 2.2)

CHuck: 11 people supported this

<Rachael> +1

<alastairc> +1

<Chuck> +1

+1

<maryjom> +1

<Ben_Tillyer> +1

<ShawnT> +1

<MelanieP> +1

RESOLUTION: Accept PR 2591 as an errata for WCAG 2.1/2.0 (and include in 2.2)

<GreggVan> 1

<laura> +1

<alastairc> Noting that the whole thing should be updated in 3.0, it's really hard to understand!

<GreggVan> +1

<JakeAbma> +1

<ToddL> +1

<Zakim> GreggVan, you wanted to say that we are working on an updated free PEAT tool so people don't have to worry about all the math

Gregg: we are working on an updated free PEAT tool so people don't have to worry about all the math

WCAG 2.x Errata https://www.w3.org/2002/09/wbs/35422/wcag21-errata

Question 1 - Updating the publication of WCAG 2.1

Chuck: (reading first question of survey on errata)

<Zakim> alastairc, you wanted to say we've done Melanie's comment, and answer Wilco

Chuck (17 people supported question 1)

Alastair: Melanies question has been addressed
... we will start a review period soon

<Wilco> Works for me, I'm very much on 0 there

Chuck: anyone wants to expand on their comments?
... Wilco, any comment?

Wilco: I'm good

Melanie: Change to to "agree"

<Chuck> proposed RESOLUTION: Re-publish WCAG 2.1 to include the errata

<Rachael> +1

<ShawnT> +1

<Chuck> +1

+1

<Wilco> 0

<bruce_bailey> +1

<alastairc> +1

<laura> +1

<MelanieP> +1

<GreggVan> +1

<Ben_Tillyer> +1

<AWK> +1

<JakeAbma> +1

<GN015> +1

<ToddL> +1

<Francis_Storr> +1

Gregg: 2.1 doesn't have any normative changes, correct? Asking since EN 301 549 refers to it

<bruce_bailey> https://www.w3.org/WAI/WCAG21/errata/#substantive

Michael C: We don't change the name and version number just a comment and a new date

Gregg: We don't want to mess up the EN folk's referencing

<jon_avila> I thought EN 301 549 pulled wording into the document rather than relying references to it.

RESOLUTION: Re-publish WCAG 2.1 to include the errata

<bruce_bailey> Substantive Errata: In the definition of relative luminance, the red threshold was updated from 0.03928 to 0.04045.

<alastairc> Each version has a unique URL

Question 2 - Target definition: Change touch target to just target #1485

<Rachael> I have added coordinating with the EN folks to teh chairs agenda

Chuck: (reads second question, change touch target -> target)
... no objections to this in survey
... any comments?

Wilco: We are updating notes i understanding docs, not the definition?

Alastair it is the note in the target definition, and some places in understanding doc

Chuck: (reading Mike Gower's comment)

<Chuck> proposed RESOLUTION: Remove "touch" from the definition of target and remove touch from understanding as an errata for WCAG 2.1

Alastair: came from Patrick, change is pretty constrained, def used in targe tsize - no reason to be concerns

<bruce_bailey> +1

<alastairc> +1

<maryjom> +1

+1

<Chuck> +1

<Wilco> +1

<Ben_Tillyer> +1

<JakeAbma> +1

<Rachael> +1

<MelanieP> +1

<iankersey> +1

<AWK> +1

<Francis_Storr> +1

<laura> +1

RESOLUTION: Remove "touch" from the definition of target and remove touch from understanding as an errata for WCAG 2.1

Question 3 - Expand/clarify "single pointer" definition #809

<bruce_bailey> https://www.w3.org/2002/09/wbs/35422/wcag21-errata/results#xq3

Chuck (reading question 3 - input device -> input from a device)

Chuck: anny comments

Chuch: (reads Wilco's comment)

Chuck: (reads Wilco's comment)

<Zakim> alastairc, you wanted to say that it is more in our scope to represent the input, rather than the device

Alastair: Agree with the proposal - interesting suggestion - if it is focusing on the device, it moves out of scope since we are focused on content

Wilco: don't feel strongly about it

<Chuck> proposed RESOLUTION: Accept PR 809 as an errata for WCAG 2.1

<Wilco> 0

<bruce_bailey> +1

<alastairc> +1

<Chuck> +1

<MelanieP> +1

<GreggVan> +1

<maryjom> +1

<Francis_Storr> +1

<Rachael> +1

<JakeAbma> +1

<ShawnT> +1

+1

<iankersey> +1

RESOLUTION: Accept PR 809 as an errata for WCAG 2.1

<Caryn> scribe:Caryn

Question 4 - Consistency: "Resize text" > "Resize Text" #1941

<Chuck> proposed Accept PR 1941 as an errata for WCAG 2.1

<Wilco> +1

Chuck: any objections?

<Chuck> +1

<ShawnT> +1

<alastairc> +1

<bruce_bailey> +1

<ToddL> +1

<maryjom> +1

<MelanieP> +1

<Detlev> +1

<Rachael> +1

<JakeAbma> +1

<Chuck> proposed RESOLUTION: Accept PR 1941 as an errata for WCAG 2.1

<GN015> +1

<AWK> "Any objections to approving with unanimous consent?"

<Ben_Tillyer> +1

<laura> +1

RESOLUTION: Accept PR 1941 as an errata for WCAG 2.1

Question 5 - Rewording of normative text for 1.4.2 Audio Control #1825

Chuck: anyone who made comment that would like to expand?

<bruce_bailey> https://www.w3.org/2002/09/wbs/35422/wcag21-errata/results#xq5

Chuck: reading comment from Michael Gower on https://www.w3.org/2002/09/wbs/35422/wcag21-errata/results#xq5

GN015: reading aloud their own comment on https://www.w3.org/2002/09/wbs/35422/wcag21-errata/results#xq5

Chuck: reading comment from Oliver Keim on https://www.w3.org/2002/09/wbs/35422/wcag21-errata/results#xq5

Rachael: would like to see a simpler change. supports comment from Michael Gower

Chuck: reading comment from Gregg on https://www.w3.org/2002/09/wbs/35422/wcag21-errata/results#xq5

<jon_avila> FYI - Some test process like Trusted Tester allow for browse mute and disable auto play feature being acceptable: https://section508coordinators.github.io/TrustedTester/auto.html

Gregg: a comment was made about audio interfering with other audio. feels like a bigger issue, not just an accessibility issue. saying that it should be separate from system audio is critical.

Chuck: reading comment from Wilco Fiers onhttps://www.w3.org/2002/09/wbs/35422/wcag21-errata/results#xq5

AWK: misunderstood the survey question, but disagrees for different reason
... the way we clear things up is with the understanding doc
... we aren't suggesting muting computer

Mary Jo: this isn't necessary in this SC. want to make sure we're not expanding definition to include something that wasn't originally intended

<Zakim> GreggVan, you wanted to say -- if it is not accessibility related - we don't speak to it -- and system audio is critical to keep that.

Jon: some test processes allow for browser mute

<Zakim> bruce_bailey, you wanted to change my survey vote in favor of something more obviously editorial (like maybe adding parenthesis)

<bruce_bailey> Disagree with adding this as an errata

<Zakim> alastairc, you wanted to suggest taking Michael's suggestion and Gregg's note https://github.com/w3c/wcag/pull/2621/files

<alastairc> If any audio on a Web page plays automatically for more than 3 seconds, either a <a>mechanism</a> is available to pause or stop the audio or a mechanism is available to control audio volume, independently from the overall system volume level.

<Rachael> +1 to the new revision

AWK: I don't want to change WCAG unless we absolutely necessary

<maryjom> +1 to what AWK said.

<Wilco> +1 to AWK, this isn't necessary

<alastairc> How about the note, "Muting the system volume is not "pausing or stopping" the autoplay audio."

AWK: the confusion expressed doesn't justify this

<laura> +1 @awk makes sense.

<jon_avila> +1 to AWK

<Chuck> +1 AWK

<AWK> How about that in the understanding doc?

Rachael: without losing the comma, is normative text conflicting with original intent?

Alistair: not against adding this to understanding doc

<Rachael> If it is either way, then I am fine with the understanding document. If we need to move the comma to reflect the intent, then I think we should move the comma.

<jon_avila> What does this all mean? Does it mean disabling autoplay can't be used?

<Chuck> Poll: add "Muting the system volume is not "pausing or stopping" the autoplay audio." to understanding document

<iankersey> +1

<AWK> +1 to understanding change to address this issue.

<jon_avila> -1 I don't know what that even means.

<Ben_Tillyer> +1 as mobile devices don't have that luxury

<Zakim> alastairc, you wanted to answer Jon

<Peter_Bossley> A user agent providing a mechanism is not conforming content. Agree that this confusion is not well-founded in my view.

GreggVan: do we have a policy as to when an author can rely on browser for audio?

<jon_avila> Yes, accessibility under conformance requirements.

GreggVan: is muting tabs supported in all browsers today?

<jon_avila> That's a conformance claim discussion - accessibility supported.

<Zakim> Ben_Tillyer, you wanted to say sites could have different audio streams

<alastairc> GreggVan - it's a grey area, you could in a conformance statement, but doesn't really tip the balance of wide support (e.g. mobile browsers)

<Peter_Bossley> No real way to mute a mobile browser.

Ben_Tillyer: a webpage may have multiple audio streams. Tools like reciteme for example

<alastairc> 10 minutes, back at 5 minutes after.

<alastairc> draft RESOLUTION: Errata not agreed, but happy to look at understanding doc updates.

<jaunita_george> +1

<ShawnT> +1

<Rachael> +1

<Chuck> draft RESOLUTION: Errata not agreed, but happy to look at understanding doc updates.

<Chuck> +1

<Ben_Tillyer> _+1

<bruce_bailey> +1

<JakeAbma> +1, I also see that was the main proposal yo begin with...

<JakeAbma> ("ps. should this 'platform provision / ability' be ruled out and made clear in the Understanding doc?")

<MelanieP> +1

<Ryladog> +1

<AWK> +1

<iankersey> +1

<Wilco> +1

<laura> +1

<Detlev> +1

<kirkwood> +1

<maryjom> +1

RESOLUTION: Errata not agreed, but happy to look at understanding doc updates.

<Zakim> Chuck, you wanted to say we break for 10 minutes

WCAG 2.2 Flash Definition Updates https://www.w3.org/2002/09/wbs/35422/PSE-updates

WCAG 2.2 Focus Appearance https://www.w3.org/2002/09/wbs/35422/focus-appearance-updates

Question 3 - Persistent indicators

<Rachael> https://www.w3.org/2002/09/wbs/35422/focus-appearance-updates/results

<AWK> Is this question 4?

<alastairc> 3

<Chuck> Q3

<Rachael> https://www.w3.org/2022/02/22-ag-minutes#item06

<AWK> Ah - Q4 when taking the survey, Q3 in results.

Rachael: Reading response from Wilco Fiers on https://www.w3.org/2002/09/wbs/35422/focus-appearance-updates/#wbsq2

Corrected link: https://www.w3.org/2002/09/wbs/35422/focus-appearance-updates/results#xq3

Rachael: Let's not read the many comments that want persistence

<Zakim> alastairc, you wanted to check about the "when focus visible" aspect

<AWK> From 2.4.7 Understanding: The focus indicator must not be time limited, when the keyboard focus is shown it must remain.

alastairc: if we tweak the first part "when to FI is visible" I wouldn't mind that. This makes it work well together with 2.4.7

Wilco: 2.4.7 has no timing language

<alastairc> We've thought about timing, but we have enough 'complications' in this SC...

<AWK> Agree that 2.4.7 doesn't specifically state any timing, but keyboard focus indicator is associated with a control having focus, which doesn't fade.

bruce_bailey: we're asking browser to decide
... i've gone the other way, thinking we should provide affordance

<Zakim> bruce_bailey, you wanted to KHS comment

<Zakim> Ryladog, you wanted to respond

Katie: browsers have pushed back on this in the past. Chrome has it but others don't

<Zakim> alastairc, you wanted to respond about fading and minumum requirements

alastairc: it doesn't have to be browsers enforcing the minimum; authors could do that too

<Rachael> draft straw poll: 1) Change wording to "When the keyboard focus indicator is visible..." 2) Retain the current wording " When a user interface component has keyboard focus…” 3) something else

<AWK> 1

<Wilco> 1

<alastairc> 2, can live with 1 but I'm fairly sure 2.4.7 means it has to be persistent anyway.

<MelanieP> 1

<Chuck> 2, 1

<bruce_bailey> 1

<GreggVan> 1

<Rachael> 2, I am afraid 1 leaves the problem ambiguous

<Ryladog> 1 or 2

<JakeAbma> 2, 1

<ShawnT> 1

<Detlev> happy with both 1 and 2

<iankersey> 2

<kirkwood> 1

<laura> 1 or 2

<KimD> 2 (it should be persistent)

1 or 2

<Zakim> MelanieP, you wanted to make a 3rd suggestion

<GreggVan> 1 because keyboard focus is not visible if not using keyboard navigation

MelanieP: if we started with "when it receives" would that alleviate concerns?

<alastairc> would -1 that without timing, and timing would add complexity...

<Rachael> draft straw poll: 1) Change wording to "When the keyboard focus indicator is visible..." 2) Retain the current wording " When a user interface component has keyboard focus…” 3) something else 3) Change wording to "After a user interface component receives keyboard focus..."

GreggVan: there've been times when FI is not visible because it's out of viewport

<Chuck> 2, 1

<AWK> 1

<Wilco> 3, 1

<Peter_Bossley> 2

<GN015> Are we still discussing Question 3?

<alastairc> 2, 1, not 3

<Rachael> chair hat off: 1, I have concerns with 2 and 3

<GreggVan> 1

<alastairc> GN015 - yes

<jaunita_george> 2

<MelanieP> 1

<JakeAbma> 2, 1

<KimD> 2

<Ben_Tillyer> 1

<bruce_bailey> 2, 1

<maryjom> 2, 1

<Rachael> chair hat off: 2, I have concerns with 1 and 3

<GN015> 2, not 3

<Detlev> 2,1 - not sure what 3 adds

1 or 2

<laura> 2 or 1

<Ryladog> 2 or 1

<iankersey> 2

<Rachael> For those who voted 1, can you accept 2

<Wilco> -1

<GreggVan> -1

<Ryladog> Yes

<AWK> No to #2 as it creates problems for sub-items as worded

yes

<MelanieP> -1

<Chuck> 1 has the least objections

<GN015> I would like to clarify my understanding of 1 before voting on it

<Rachael> For those who voted 2, can you accept 1

<Chuck> +1

<KimD> no

<Rachael> -1

<iankersey> -1

<bruce_bailey> can accept 1

<alastairc> -0.5

<jaunita_george> -1

<maryjom> +1

yes

<Detlev> ja

<JakeAbma> -0.2

<Chuck> 1 and 2 both have objections

GreggVan: would like to hear why people won't accept #1
... what's the scope of keyboard focus?
... does this include keyboard text input caret?
... we wouldn't want the input caret to fade

<AWK> scope is both

<AWK> Scribe: AWK

<Chuck> THANKS Caryn!

<Zakim> Chuck, you wanted to ask for a scribe change

<GreggVan> ok thx

AC: keyboard input carat is different from other keyboard focus I believe

GN: there is 2.4.7 and Focus appearance. Describing what it looks like makes sense when it is visible

<jaunita_george> +1 to GN

AC: If there is no focus indicator it would fail 2.4.7

<Zakim> bruce_bailey, you wanted to ask if Skip Nav landing spot -- is that UIC with keyboard focus?

<Zakim> GreggVan, you wanted to say interesting point. do we have a requirement that the keyboard focus be visible even when not using keyboard navigation?

BB: people worrying about fading focus - does that only apply to the chrome extension? It seems like this doesn't actually interfere with this SC

GV: two points

<jaunita_george> I see it being a problem in complex widgets and menus with many options -- folks may lose their place

<bruce_bailey> yes, @GreggV its an extra cue

GV: if keyboard focus can fade, then the user can lose track of their position

<jaunita_george> Also, couldn't it make it difficult for folks with cognitive disabilities to navigate complex forms and such?

GV: second, do we have an SC that says that the keyboard focus needs to be visible even if the keyboard isn't being used?

<GreggVan> good AWK agree thanks

<KimD> 2.4.7 "Any keyboard operable user interface has a mode of operation where the keyboard focus indicator is visible."

<Rachael> AWK: 2.4.7 does indicate that when any keyboard has a mode of operation, and that is what provides the exception you are talking about.

<bruce_bailey> 2.4.7 Focus Visible: Any keyboard operable user interface has a mode of operation where the keyboard focus indicator is visible.

<Ben_Tillyer> +1 to everything AWK said

<Rachael> ...when keyboard focus is being used, it should be visible. IF you look away, it should be where you left.

RM: concerned with wording around "when kybd focus is visible" - seems to be building ambiguity into the spec

CA: Standing decision that has received serious decisions
... without action we will have a problem with this SC for WCAG 2.2

MP: Wanted to make sure that the fading - 2.4.7 would still be in effect.

AC: yes but it could be 1 px big

WF: There was a change but the wording in the SC didn't seem to make it into the draft (?)

<Rachael> AWK: Would 2.4.7 still be in effect? You said it could hten be 1 px thick. This SC is defining what that visible focus indicator appears as.

<Peter_Bossley> Even if we say "when the keyboard focus indicator is visible" that would require persistence wouldn't it? Because 2.4.7 requires it to be visible when focused.

<Rachael> ...2.4.7 is saying, if its visible then here is what it needs to be.

AC: on wilco's point, if we agreed in Feb, we then updated it in March.
... on Andrew's point, I was thinking about non-text contract. Think I'm agreeing...

<KimD> Agree with Peter_Bossley. I'm against making a change that could conflict with another SC.

<Wilco> Sounds correct, yes

<Rachael> draft straw poll: 1) Change wording to "When the keyboard focus indicator is visible..." 2) Retain the current wording " When a user interface component has keyboard focus…” 3) something else

RM: Back to straw poll. Two options -

<Rachael> draft straw poll: 1) Change wording to "When the keyboard focus indicator is visible..." 2) Retain the current wording " When a user interface component has keyboard focus…”

<KimD> 2

<Chuck> 2, 1

1

<alastairc> 2, can live with 1

<GN015> 2

<Wilco> 1, disagree with 2

<MelanieP> 1

<Ben_Tillyer> 2

<JakeAbma> 2, 1

<Ryladog> 1, 2

<Rachael> 2, not 1 but won't object

<bruce_bailey> 1, 2 okay

<laura> 2

<GreggVan> 1

<ShawnT> 2, 1

<alastairc> Katie said 1 in zoom chat.

<Chuck> AWK: I want to ask Kim. I saw that Kim replied to Peter B saying against making a change that conflicts with another SC. I'm not clear on the conflict. Can someone clarify the conflict?

<iankersey> 2

<Chuck> AWK: Do you think the wg says 2.4.7 does not require persistence, or does?

<Chuck> Kim: 2.4.7 implies persistence.

<Chuck> AWK: And that's a conflict with 1 of the straw poll?

<Chuck> Kim: Yes

<Chuck> AWK: How is there a conflict?

<Chuck> Kim: When it says it's visible, which means it can be not visible?

<Chuck> AWK: Yes, there are times when there is no focus on a page when it's loaded. Sometimes focus is on frame.

<alastairc> or if you click into a non-interactive area

<iankersey> but we are talking about interactive compnenets, right?

<Chuck> AWK: Page loads, you tab, first time focus goes into page. Page is there, nothing has focus. And as Gregg says for 2.4.7, there is a mode of operation, you may have a site that doesn't show focus.

<alastairc> iankersey - yes, I just mean that sometimes there isn't a keyboard focus, and that's ok.

<Chuck> AWK: That's part of the appeal. All the dependency on what needs to have focus goes to 2.4.7. We are saying "focus needs to be visible in the following condition". In 2022 we are saying "visible" means this. Is that different from your understand?

<alastairc> The top of the understanding doc says "Where Focus Visible merely requires a visible focus indicator, this SC defines a minimum level of visibility."

<Chuck> Peter: We are saying either "focus has to be visible, and it needs to be this", and then we are saying "when it's visible, and we don't have to make it visible".

PB: Seems like a chicken and egg issue - what if some people just didn't make the focus visible?

<Chuck> AWK: By definition... wouldn't you agree that a cite owner that decides to not make the component visible fails 2.4.7?

<bruce_bailey> If keyboard focus is not visible, that fails 2.4.7 -- so 2.4.11 pass/fail less of an issue

PB: Yes, assuming that there isn't a mode

GV: 2.4.7 and 2.4.11 work well together

<Rachael> Proposal: Change wording to "When the keyboard focus indicator is visible..." and ensure the understanding docs clarify persistence between the relevant SC

<Wilco> 0

RM: Proposing that we change the language to "When focus is visible" AND update understanding

+1

<bruce_bailey> +1

<GreggVan> +1

<maryjom> +1

<Ryladog> +1

<alastairc> +0.5, prefer current, but if it gets us moving...

<ShawnT> +1

<Wilco> to be clear, 0, as in, not objecting

<Detlev> +1

<Chuck> +0.75

<JakeAbma> +0

<laura> +1

<alastairc> Persistence required (in 'mode of operation')

<ToddL> 0

<GN015> -.5

<iankersey> 0

<GreggVan> only required to be persistent in the mode where it is visible

<Caryn> 0

<KimD> 0

GN: if this req is not applicable when the focus isn't visible... [can't understand]

<Rachael> draft RESOLUTION: Change wording to "When the keyboard focus indicator is visible..." and ensure the understanding docs 2.4.7 and 2.4.11 clarify that the focus remains

GN: Don't like it but can live with it

<Rachael> draft RESOLUTION: Change wording to "When the keyboard focus indicator is visible..." and ensure the understanding docs for 2.4.7 and 2.4.11 clarify that the focus remains persistent

<ShawnT> +1

+1

<Caryn> +1

<bruce_bailey> +1

<Wilco> 0, and a round of applause to the chairs. Thank you.

<Ryladog> +1

<Ben_Tillyer> +1

<maryjom> +1

<KimD> 0

<JakeAbma> =)

<laura> +1

<kirkwood> +1

<alastairc> +1

<Detlev> +1

<MelanieP> 0

<Francis_Storr> +1

<iankersey> 0

Moving to question 5

RESOLUTION: Change wording to "When the keyboard focus indicator is visible..." and ensure the understanding docs for 2.4.7 and 2.4.11 clarify that the focus remains persistent

Question 5 - Complexity

RM: discussing whether we remove/mark at risk/continue
... reading from https://www.w3.org/2002/09/wbs/35422/focus-appearance-updates/results#xq6
... 10 continue, 1 remove

<Ryladog> I agree with AWK

<Chuck> AWK: In my response I talked myself into different corners. I think where I come down, we should continue with it. It's a very important SC. If we mark it at risk and pull it, it's the last opportunity to have it in WCAG until 2026. I'd rather delay 6 months and get it in. I think we are close.

RM: Mike Gower's response read
... Detlev feels that testing complexity is main issue

<Chuck> I made Alastair host. I am departing. I don't think call will end.

PB: not much to add to written comment. Addressing the UA exception proposed by deque is also important

<Rachael> strawpoll: 1) keep SC 2) keep SC at risk 3) remove SC

RM: Most people want to move forward, question is at risk or not

<KimD> 3 remove

<Peter_Bossley> 3

<alastairc> 1, 2, not 3

<Ben_Tillyer> 1 I feel that if we mark this "at risk", the SC won't make it to the final release

<Wilco> 2, 1, disagree with 3

<iankersey> 3

<GN015> 1

1 because I would rather have a 6 month delay than not have this SC in WCAG 2.2

<ShawnT> 1

<ToddL> 2, 1, opposed to 3

<MelanieP> 3 if no full default indicator is included, 2 if the full default indicator is included

<bruce_bailey> 1, 2 okay -- +1 to @AWK comment

<Rachael> 2,1 not 3

<laura> 2, 1

<Caryn> 3, maybe 2

<Francis_Storr> 1, 2, not 3

<alastairc> It's in Q4

<MelanieP> An exception for if the default indicator is not changed (drop the part about the background)

AC: To Andrew's point, if we mark as at risk and need to pull the SC can we go back anyway?

<Rachael> For those who voted 1 and 2, who would object to removing

<Ben_Tillyer> +1

<SuzanneTaylor> +1

AWK: I think that there would need to be a precipitating event

<ShawnT> +1

<alastairc> +1

<ToddL> +!

<Rachael> +1

<Francis_Storr> +1

<GN015> +1 I would object to removing

+1

<ToddL> +1 that is

<SuzanneTaylor> +!

<GreggVan> +1

<Rachael> For those who voted to remove, who would object to keeping it

<Peter_Bossley> +1

<Caryn> +1

<KimD> +1

<KimD> (Object to keeping in current form)

<MelanieP> Object to keeping it without marking it at risk

MP: We have some concerns with our group - when we go to CR there is the possibility of learning about additional concerns.

<Rachael> draft RESOLUTION: Continue with the SC at risk (we will address the other survey questions via email and meetings and address objections through W3C process)

MP: we did At Risk SC's in 2.1, don't understand the resistance

<Wilco> +1

<ShawnT> +1

+1

<alastairc> +1

<MelanieP> +1

<Rachael> +1

<GN015> +0.5

<bruce_bailey> +1

<SuzanneTaylor> +1

<Ben_Tillyer> -0.5

<KimD> If we aren't removing, the minimum we need to do is mark it at risk. So is that a +1?

<Francis_Storr> +1

<Ben_Tillyer> Microphone has stopped working, will type

<laura> +1

<GreggVan> +1

<ToddL> +1

<Caryn> +1 to marking at risk

<Detlev> +1

<Ben_Tillyer> I feel that if put at risk, the same comments that we have had, and have read, will be repeated and the SC will disappear. I may just be paranoid though?

RESOLUTION: Continue with the SC at risk (we will address the other survey questions via email and meetings and address objections through W3C process)

<Rachael> o TOPIC: Question 4 - User agents

Question #4 User Agents

AC: Key thing is about user agent exceptions.
... the survey proposes a single wider exception - if you haven't touched the focus indicator (you are the author) then the exception applies

RM: (reviewing people's responses)

<alastairc> Detlev - there are some widgets (e.g. select drop-downs), or PDFs where the author can't change the focus indicator.

<Detlev> @alastairc I don't think that is true if you change the select's fore and background colors, focus is very visible..

<alastairc> I think Wilco and Oliver made a similar point but came to the opposite conclusion...

<Detlev> @alastairc didn't check across browsers but tied that yesterday...

MP: Keep coming back to concept of small web site owners
... no idea how to change CSS or anything
... we are setting these folks up for failure
... we shouldn't be putting so much on site owners

<alastairc> To Melanie's point, small sites / orgs use tools, e.g. wordpress, shopify. Those have 'accessible templates' / themes, the individuals don't implement them.

<Rachael> straw poll: 1) remove the exception all together 2) change to "except if the focus indicator is not modified by the author" 3) retain current wording

<Wilco> 2

<ToddL> 2

<MelanieP> 2

<Caryn> 2

<alastairc> 3, 1

<ShawnT> 2

3

<GN015> 1, can live with 3

<Rachael> 3,1

<Ben_Tillyer> 3,2

<GreggVan> 3 can live with 2

<KimD> 2

<bruce_bailey> 2 , 3, 1

<Detlev> 2

<alastairc> NB: I assume we'd keep the "if the author can't modify it" exception

<laura> 2, 3

BT: What is the context for the focus modification? Who is the author?

AC: A CMS is considered the author

<Rachael> Who on the call will object if we change it to "except if the focus indicator is not modified by the author"

<alastairc> +.8, very close

(+1 if you would object)

+.25

<Rachael> +.5

<MelanieP> thank you everyone

<GreggVan> +1 to scribes and Chairs !

<Ben_Tillyer> thanks all, look forward to chatting next week

<laura> Thanks to the chairs too.

<GN015> I revote my poll answer to 1 or 2

Summary of Action Items

Summary of Resolutions

  1. Accept PR 2567 and create an errata for WCAG 2.1/2.0 for the note update
  2. Accept PR 2619 with the changed paragraph and the rest of the calculation goes into the understanding document. We come back with a change of L to Y later
  3. Accept PR 2591 as an errata for WCAG 2.1/2.0 (and include in 2.2)
  4. Re-publish WCAG 2.1 to include the errata
  5. Remove "touch" from the definition of target and remove touch from understanding as an errata for WCAG 2.1
  6. Accept PR 809 as an errata for WCAG 2.1
  7. Accept PR 1941 as an errata for WCAG 2.1
  8. Errata not agreed, but happy to look at understanding doc updates.
  9. Change wording to "When the keyboard focus indicator is visible..." and ensure the understanding docs for 2.4.7 and 2.4.11 clarify that the focus remains persistent
  10. Continue with the SC at risk (we will address the other survey questions via email and meetings and address objections through W3C process)
[End of minutes]

Minutes manually created (not a transcript), formatted by David Booth's scribe.perl version 1.200 (CVS log)
$Date: 2022/08/16 17:34:21 $

Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]
This is scribe.perl Revision VERSION of 2020-12-31
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/Agree as it applies to 2.1 and 2.2 applied to today's tech, so may be applied just to understanding or via errata also to notes (?)/Our choices are as I indicated in IRC above/
Succeeded: s/doc hange/doc change/
Succeeded: s/Don't agree with the change/Agree with the proposal/
Default Present: Wilco, bruce_bailey, GreggVan, JakeAbma, Detlev, Caryn, MichaelC, maryjom, AWK, alastairc, Rachael, MelanieP, Laura_Carlson, ToddL, Fazio, Peter_Bossley, ShawnT, Ben_Tillyer, jon_avila, StefanS, kirkwood, Francis_Storr, JustineP, iankersey, jaunita_george, Katie_Haritos-Shea, Jen_G, !, .25, .5, GN
Present: Wilco, bruce_bailey, GreggVan, JakeAbma, Detlev, Caryn, MichaelC, maryjom, AWK, alastairc, Rachael, MelanieP, Laura_Carlson, ToddL, Fazio, Peter_Bossley, ShawnT, GN015
Regrets: Makoto Ueki, Azlan Cuttilan
Found Scribe: Detlev
Inferring ScribeNick: Detlev
Found Scribe: Caryn
Inferring ScribeNick: Caryn
Found Scribe: AWK
Inferring ScribeNick: AWK
Scribes: Detlev, Caryn, AWK
ScribeNicks: Detlev, Caryn, AWK

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.)


[End of scribe.perl diagnostic output]