<ChrisLoiselle> scribe:ChrisLoiselle

<Sukriti> I can do it but a new member

Note that we'll be versioning the informative documents

<Sukriti> what does it entail?

Chuck: Talks to versioning of documents.

<alastairc> https://www.w3.org/WAI/WCAG21/Understanding/

Alastair: If you link to https://www.w3.org/WAI/WCAG21/Understanding/ this is the universal location.

For WCAG 2.2 there is a change proposal to freeze off the wcag 2.1 documents, those would stay in same place. Anything added in 2.2. would be in a different location

Essentially we are versioning. In future, we'd need to identify if we are updating in both places, wcag 2.1 and 2.2. or just 2.2.

Chuck: We are looking to people for objections. Any questions on reasoning for this?

RESOLUTION: Implement versioning for informative documents.

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

We are talking to first 4 questions on this call, on focus visible enhanced issues.

Add 'unobscure' bullet

<Chuck_> Unobscured: The focus indicator is not entirely hidden by author-created content.

First question is on adding unobscure bullet

Alastair: Mike suggested moving focus to an element. Which sort of helps with partial obscurement.

If wordwrap is applied to sticky content, it may impact the focus indicator. I don't think we are there for phrasing yet.

Alastair: It is a layer of content above the element and not related to the element. To separate it from examples that talks to adjacent elements, someone can talk to that more if they want.

Chuck: Talks to Detlev's comments, which talks to break off point and dropping extra bullet..

<JF> +1 to Detlev

<Chuck_> Detlev comment in survey read by Chuck: I am not entirely happy with the ‘not entirely’ bit. The bullet text may be difficult to comprehend without explicit reference to sticky content, but don’t have a better solution. So I agree in principle to cover the case which is a real issue - but we need a break-off point where we drop this extra bullet in case there is no WG agreement to include it, so we do not risk delaying this new important SC.

Detlev's comments tend to read as "not quite there" .

<alastairc> Non-agreement means going back to what was agreed.

Chuck and Alastair: It is possible to take it away and come back later on topic, but ultimately a resolution would be beneficial.

MichaelG: Focus visible , before focus enhance weren't talked to. The really clear case with sticky headers is where focus is visible but not in current viewport.

<alastairc> Updated suggestion: "Unobscured: The item with focus is not entirely hidden by author-created content"

MichaelG: The item with focus is not currently hidden by author-created content is what his rewording reads as. It addresses the issue that is an ongoing problem. It is easily testable.

I'd like to get it out and seek comments on it.

Chuck: I'm still a proponent of adding a bullet and adding some changes. Getting it out for public review is important.

Jake: We had sticky headers and we implemented skip links , focus moved to content and was supposed to scroll into view. The sticky header didn't take position of elements into play.
... We couldn't address for all user agents. We removed the sticky header as a design / technical issue , which was hard to fix.

<kirkwood> +1 to Jake had the same issue

<Chuck_> alternative proposed: “Unobscured: No part of the focus indicator is hidden by author-created content”

Gundula: The main goal is to make sure the user finds the focus.

<Brooks> +1 to Gundula's point.

Requesting no part of focus indicator is hidden.

<Chuck_> Unobscured: The item with focus is not entirely hidden by author-created content

Chuck: posts MikeG's text. Looking to see plus one's if you like MikeG's proposals

<mbgower> +1

<alastairc> +1 (and would object to the previous version)

<JF> +1

<JakeAbma> +1

<ok> +1

<Sukriti> +1

<Mike_Pluke> +1

<Francis_Storr> +1

<GN015> -1

<Laura> +1

<Ryladog> +1

<Zakim> alastairc, you wanted to say that scroll-padding is better supported now

Alastair: On Jake's comment: The browsers have been improved on Jake's issue he was having with sticky headers.

<Brooks> what is in the author's control is whether to use sticky content or not

<Zakim> mbgower, you wanted to say there can be a AAA for unobscured (plus better visibility)

<kirkwood> scroll padding seems would solve this, is it fully adopted?

<alastairc> brooks - scrolling (no sticky content) could be read to cause fails

<alastairc> kirkwood - it helps, but it is not 100%

MichaelG: Talks to AAA level and making that it is fully visible. The reason I talk to "author's control", is that there are many that are not under their control.
... It is a compromise to get toward something rather than nothing.

<Brooks> This compromise argues against the SC to which it is attached.

JF: I support the goal on compromise and appreciate Gundula's comments. What if we had a "at least 50 percent" or 60 percent of focus indicator is present? I.e. what does not entirely hidden mean?

<Fazio> +1

Gundula: If focus indicator is percentage based, then why would the requirement be needed per a developer review?

<Fazio> There are many varizbilitiesin visual field cuts like mine

JF: What is insufficient focus indicator vs. sufficient focus indicator?

<mbgower> Percentage will be a real testing challenge, IMO

Alastair: I don't think a percentage is correct route. The focus indicator should be is talked to in the first three bullets. The last bullet is a temporary situation , i.e. overlapping.

<Zakim> alastairc, you wanted to say that any % of 'focus indicator' undermines the rest of the SC

We aren't looking at focus indicator on last bullet. It is the element that is being overlapped by other content on the last bullet

<Chuck_> “Unobscured: No part of the focus indicator is hidden by author-created content”

I.e. non adjacent content

For Gundula's proposal: “Unobscured: No part of the focus indicator is hidden by author-created content” , please comment via plus one.

<Chuck_> proposal: “Unobscured: No part of the focus indicator is hidden by author-created content”

<mbgower> -1 it's too hard to pull off

<ok> +1

<JF> -1

<Chuck_> -1

<alastairc> -1, infeasible

<kirkwood> +1

<Ryladog> -1

<Brooks> +1

<Mike_Pluke> -1

<Sukriti> -1

<Laura> +1

<PascalWentz> +1

There is a mix of like and dislikes , there is not consensus on Gundula's proposal

<Chuck_> Proposal: Unobscured: The item with focus is not entirely hidden by author-created content

<Ryladog> +1

<mbgower> +1

<Chuck_> +1

<Mike_Pluke> +1

<Francis_Storr> +1

Chuck: Do you agree to add this as a 4th bullet?

<ok> -1

<GN015> didn't have exactly this before, in the first poll?

<JF> -0 as "not entirely" needs to be defined

<alastairc> +1

<JakeAbma> 0

<Brooks> -1

<PascalWentz> -1

alternative would not be adding anything in.

<Laura> 0

<Jennie> 0

<kirkwood> -0

<GN015> -1

<Sukriti> 01

<Sukriti> -1

Gundula: Could you repeat that?

<Chuck_> Unobscured: The focus indicator is not entirely hidden by author-created content.

The one that is in survey originally is on focus indicator. The element rather than focus indicator is now the current.

<alastairc> I thougth we dropped the 'focus indicator' one as it creates a massive hole in the previous bullets

<mbgower> "Not fully obscured"?

JF: Not entirely hidden is not measurable.

<kirkwood> +1 to JF

<kirkwood> not entirely hidden doesn’t seem usable

If we are saying partially hidden or not entirely hidden, at what point is partially hidden too much?

<Chuck_> Unobscured: The focus indicator is not entirely hidden by author-created content.

Alastair: The reason we moved on this last time is that we talked to focus indicator being partially hidden, it opens exceptions

MichaelG: The only way you can make this easily testable is that is the fully obscured area. It is not a perfect solution, but it is good. The alternative is nothing and no traction.

<Ryladog> +1 to Mike

<Mike_Pluke> +1

Chuck agrees to Mike

<mbgower> But isn't today the deadline?

Chuck: There is consensus among group to do something, but we haven't agreed on what it should be. It is worth conversation what the 4th bullet could be. Do we have other proposals?

<alastairc> Some examples (images, sorry) about the hole the partially visible 'focus indicator': https://github.com/w3c/wcag/issues/1145#issuecomment-644028281

Chuck: We do need to have a decision to move forward.

Gundula: Requesting that the focus indicator is not fully hidden was rejected. If focus indicator was hidden completely, i.e. strong bar on left and focus is on one side, it may be hidden completely. The focused element is not in viewport anymore.

It seems like we've gone beyond the wording of the survey.

<Chuck_> Unobscured: The focus indicator is not entirely hidden by author-created content.

Chuck: We can poll for those concerns

<Chuck_> 0

<kirkwood> +1

<alastairc> -1 creates hole, undermines the 1st bullet

<Mike_Pluke> +1

<JakeAbma> 0

<GN015> +0.5 (can live with it)

<mbgower> +1 (but I think it is potentially more confusing, and opens up edge case problems

<JF> -0.5

<Ryladog> +1

<ok> 0

<Brooks> -1

<Laura> 0

<Francis_Storr> 0

<PascalWentz> 0

<alastairc> Example of hole it creates https://alastairc.uk/tests/wcag22-examples/sticky-footer4.html

Consensus is not present at moment on this poll.

<Chuck_> Unobscured: The item with focus is not entirely hidden by author-created content

Chuck: Do we have proposals other than that are within the survey?

JF: Concern is not entirely hidden and what the measure of that is exactly

Alastair: We don't want to undermine previous bullets that we are talking to with the last bullet.
... If other content is around or adjacent, edge cases come in to play.

<Zakim> mbgower, you wanted to say how is not visible subjective?

MichaelG: To me, the not visible means it is not there.

To have one pixel come in to view, that would not be a great design as not all views will show that.

Brooks: Talks to sticky content vs. focus is visible. We don't want to undermine general principle

<mbgower> Another situation that will fail this is non-modal dialogs that obscure the item with focus

<Zakim> JF, you wanted to ask if we can "suggest" a minimum surface requirement in Understanding doc?

JF: Can we address this in understanding documentation?

I.e. the intention is "X". The sufficient enough can be talked to vs. insufficient vs. mandated break point

<Chuck> Unobscured: The item with focus is not entirely hidden by author-created content

JF: We could add suggestions in understanding. Maybe its not always a percentage. Maybe it is a number of pixels

<CharlesHall_> doesn’t “author created” eliminate “user agent rendered” or some other factor?

<Brooks> To clarify my comments earlier, I said it seems like we are trying to give a "pass" to sticky content. Sticky content has a lot more accessibility problems than causing focus indication to be obscurred. It seems like we are spending a lot of time trying to protect a known inaccessible practice.

<Chuck> Unobscured: The item with focus is not entirely hidden by author-created content

Chuck: Do we have any other suggestions ?

<Zakim> mbgower, you wanted to say this isn't just sticky footers

<kirkwood> have notice3d it, disagree

DavidM: The issue came up in an academic environment, it doesn't seem we are getting very far on it. Do we drop this topic?

MichaelG: The sticky footer is just the latest content to talk to this. Non modal dialog does similar thing.

<kirkwood> +1 to Gower

<Chuck> +1

<Ryladog> +1 to Mikie

MichaelG: Non modals or modals that are not modals , things that are supposed to be dialogs that aren't.

Brooks: Pages that have infinite scroll and tabbing , that is a fail in my book. Fail of focus order and keyboard.

Yes please :)

Thanks John!

<alastairc> scribe: kirkwood

<Chuck> Unobscured: The item with focus is not entirely hidden by author-created content

Chuck: going to add, or nothing?

<ChrisLoiselle> John K : This is helpful https://www.w3.org/WAI/GL/wiki/Scribing_Commands_and_Related_Info

<mbgower> +1

<Ryladog> +1

<Francis_Storr> +1

<alastairc> +1 to add

Alistair: we will have a sction in uderstanding doc if have bullet

<ok> +1 to add

<david-macdonald> 0

<JF> Provisionalo +.75

<JakeAbma> +1

<GN015> -1

<Mike_Pluke> +1

<PascalWentz> 0

perfect

<Laura> +1 with addition to understandg doc

<Brooks> 0

<CharlesHall_> +1 with entirely hidden and author-created both defined.

RESOLUTION: Add the bullet "Unobscured: The item with focus is not entirely hidden by author-created content" and add understanding content (tbd).

Resolutiion stated by Chuck

Add an AAA version?

thanks

CA: add a triple A version

<Chuck> Any keyboard operable user interface has a mode of operation where the keyboard focus indicator is equivalent to at least a 2 CSS pixel solid border around the control, and has a change of contrast compared to the unfocused control of at least 3:1.

CA: if we agree to adding someone would need to create understanding document
... six said yes one said no

AC: we need someone to work with understanding dcocument iit’s a subset of AA help give direction

MG: perfect opportunity to add a word to Gundula one

<Ryladog> +1

GN: feel add then why not add color contrast

<ok> +1

<Ryladog> +1 to 4.5:1

Gundula: add contrast yes

CA: some in irc agreeing

<Mike_Pluke> +1 to 4.5

CA: jake said lets add to triple A and had comment

JA: not really

<alastairc> "Any keyboard operable user interface has a mode of operation where the keyboard focus indicator is equivalent to at least a 2 CSS pixel solid border around the control, and has a change of contrast compared to the unfocused control of at least 4.5:1. No part of the focus indicator is hidden by author-created content."

CA: we have proposal differnt then in survey

AC: posted in IRC

<Ryladog> +1

<Chuck> +1

CA: poll

<JF> +1 to AAA

<Sukriti> +1

<JakeAbma> +1

JF: triple a correct?

<Mike_Pluke> +1

Alistair: yes

<alastairc> +1

<PascalWentz> +1

<ok> +1

<david-macdonald> +1

MG: do we have a contrast requirment for AAA
... weird to do that

JF: do we want to have AAA to match AA for non-text contrast

<Zakim> mbgower, you wanted to day doesn't match contrast at AAA?

\s/JS/JF

<mbgower> +1

MG: weird to do it for this one

AC: more straight forward

<alastairc> Just need someone to draft the understanding...

CA: seems like no objections

<Sukriti> I can create the draft of the understanding document for AAA version

AC: need someone to work on it

CA: poposed resolution, agree to work on an AAA version of 2.4.11

MG: bulleted form like others?

AC: we wil do a comparison

RESOLUTION: agree to work on an AAA version of 2.4.11

<Sukriti> yes

3. Do we try to mitigate the tricky examples?

<alastairc> Example: https://codepen.io/JasonAment/pen/qBdjPeP

CA: this is third question do we try to mitigate in both, it is not something see in wild…

thank you

<Chuck> Proposed response: This is not a common pattern that we have seen in the wild, and it seems unlikely that the new success criteria would cause people to try this method. Whilst it is a potential hole, we would rather not complicate the text in order to plug that (quite rare) hole.

AC: think of large buttion with stiped outline and swap position so invisible basically to normal vision its a clever way of getting around SC.
... i tried to do it, for a niche example
... thought unlikely to be an issue in practice

GN: i like suggestion to have discernable and feel hardly measurable thought it would be added intent to add clearly as goal. it follows literal word but not intent

CA: maybe we could just update intent

GN: agreed

CA: like it

<Sukriti> sounds good

AC: we need to agree to proposed response and add to understandign

CA: any concerns objection to GN proposal?

AC: Gundual put in otp of understanding doc

CA: not change understanding but to Gundula repsone
... in addition update understanding

<alastairc> Response as per the survey, plus: "We will make an update to the understanding document to clarify these scsenarios"

MG: we will be adding to understanding to clarify

AC: yes

CA: any objections

JF: i’d like to see some of that draft language as well

AC: I’ll take what Gundula in survey results and put in stripedc patterns

JF: can we see draft language

AC: can we agree on response to public comment and update understandfing

RESOLUTION: answer wtih proposed response, including a comment that we will update the understanding document.

RESOLUTION: answer wtih proposed response, including a comment that we will update the understanding document.

4. Change "border" to "perimiter"

CA: Jake suggested changing border… will paste it in

<Chuck> OLD: “The focus indication area is greater than or equal to a 1 CSS pixel border of the focused control."

<Chuck> NEW: “The focus indication area is greater than or equal to a 1 CSS pixel line around the focused control’s perimeter."

<JF> -1 as "border" is also a CSS element, but perimeter isn't

CA: alistair you said stick with border

AC: don’t think its particualarly a css thing

<alastairc> JF, do you mean -1 to changing, or -1 to using border

CA: detlev comment poroposing simple change to text
... MG want to talk to this

<JF> -1 to swapping out border with permiter - like others I feel that border and CSS are bound

MG: I can live with either as long as no gotcha, maybe note in editorial
... just asking for comments

CA: don’t wish to block

JA: this not from me, it was clear for me, a team discussed and was awkward, they had questions about it, didn’t have common understanding

<alastairc> Interestingly, we only use the term 'border' in one place in the spec, in a note under contrast: https://www.w3.org/TR/WCAG21/#h-note-78

JA: though interesting started thread, they completely misunderstood and ended up with perimeter
... really don’t understan and mixed with CSS thats where came from
... i was fine with it

JF: i had to deal with it wit image map, an actual map, focus on different states, outlined geographic border
... your concernt about border linked to CSS box model but in real world can be multiple shapes
... wondering if we can have better meaning of border
... maybe its defining edge

CA: gone through comments i’m going to switch to not changing
... going to treat John as separtate

<Chuck> Poll: Change "border" to "perimiter"

<Chuck> -1

CA: do we change border to perimeter

<mbgower> 0

<Mike_Pluke> -1

<JakeAbma> 0

<GN015> +1

<Sukriti> -1

0

<Brooks> -1

<alastairc> +0.5

<JF> -1 to changing border to perimeter

<ok> +1

<Francis_Storr> 0

<Laura> -1

<OmarBonilla> -1

<Ryladog> -1

<david-macdonald> -1

<PascalWentz> +.5

CA: if no consesensus then we don’t change
... want to focus on Johns idea
... is it worth to propose text to clarify
... looking for volunteers

<alastairc> Probably just a sentence https://www.w3.org/WAI/WCAG21/Understanding/focus-visible-enhanced.html#Contrast-thickness

<Francis_Storr> I can volunteer for that.

AC: see sentence here will email around

<JF> Border: the determinable edge between two adjacent items. It can be the CSS box model, or can also be a 'polygon' (as seen in image maps, etc.)

AC: copy section and email around

<Laura> +1

<mbgower> +1

<JF> +1 to resolution

RESOLUTION: No change of "border" to "perimiter", we will review some draft changes to understanding.

<alastairc> +1

RESOLUTION: No change of "border" to "perimiter", we will review some draft changes to understanding.

[12: 34pm] Laura: +1

Reflow updates survey https://www.w3.org/2002/09/wbs/35422/reflow-updates/

CA: reflow

JF: i pasted in suggestion

<CharlesHall_> border also has a definition in CSS

CA: Francis we can add this into it
... new agenda item

Expand 1.4.10 to apply 'down to' instead of 'at' 320px (#698)

CA: original intent so no horizontal scrolling down to 320 pixels to allow for legacy apps
... should we update reflow with a down to requirment?
... not agreeing text but want to include
... given number of yes , are ther any disagreemtn to down to

<GN015> I miss my response in the results.

MG: thought proposal to alter down to

<alastairc> https://github.com/w3c/wcag/issues/698#issuecomment-487768701

AC: do want to look at it it is literally adding ‘down to’

MG: rather than painful process changing update understanding

AC: Bruce voice is missing who had concerns
... don’t think we can completely address in understanding

1. Expand 1.4.10 to apply 'down to' instead of 'at' 320px (#698)

<Zakim> mbgower, you wanted to say this is changing the requirement

AC: massive vloume of zoomability, its worth an update

MG: the 320 was almost an lternative version, by changing to down to think it is changing intent

AC: changing to down to we could updte SC

CA: do we take the time

DM: if i remember think it was around just test if 320 goes down to it there are bugs, and mulitplier for testing of this

<Brooks> +1 to David's recollection - a big part of the reason why specifically chose 320 pixels - testing complexity, time and cost was a big factor

GN: surprised my answers are not it

CA: i need to refresh

GN: a point for later there are different points of view of content may not scroll two directions at same time, whole page or portion
... come back to later

<Zakim> alastairc, you wanted to speak about testing

AC: on davids point about testing… we generally test by zooming in
... might miss a point of horizontal scrolling out of bounds
... we could provide advise around page variations
... making testing more managable

BN: i’m actially do training around this text spacing, reflow lots of trinaing, its quite an operation
... having had experince would recommend not adding more complexity at this point
... its already an awful lot of work

CA: you did what alistair is proposing and was a lot of work

BN: no
... not a brak points just doing that in one test, resizing, reflow just texting at 320 was a lot to handle at this time

CA: as is it is already cumbersome

BN: absolutely

Ca: alaiator want otu pdate and change understanding document

AC: yes text sizing and text wpacing, looking for horizontal scroll bars would be an addition

BN: that is not the reading i got

<alastairc> Language proposed for the SC: https://github.com/w3c/wcag/issues/698#issuecomment-487768701

BN: we are doing a vatiation looking for changes in content nee clarifcation

<Zakim> mbgower, you wanted to say I am very concerned with this as a change.

<alastairc> e.g. "Vertical scrolling content down to a width equivalent to 320 CSS pixels;"

MG: my concern is changing requirments of SC i’m concerned

<Chuck> +1

MG: how its going to pass 2.2 to 2.1 its changing an existing SC

CA: do we want to put in the effort not adopt
... an objections
... putting out to see if any objections

<Chuck> Poll: Expand 1.4.10 to apply 'down to' instead of 'at' 320px (#698)

AC: user need zoom donw to 320 pixels it was a compromise in 2.1 for mobile vue for exmaple has feasibility changed

<JakeAbma> +1

<alastairc> +1

<mbgower> I've had teams that couldn't handle reflow who designed a 320 page to address.

<david-macdonald> -1 I suggest a new SC if we are going o do that

<Brooks> -1

<mbgower> -1

<JF> -1

<GN015> +1

+1

<Sukriti> +1

<Francis_Storr> +1

<CharlesHall_> -1

<Ryladog> +1

<Ryladog> yes, new SC

AC: a new SC is an option

<Mike_Pluke> +1

<mbgower> rescinding my vote. willing to consdier

<ok> +1

<Laura> +1

<mbgower> 0

<alastairc> CharlesHall_ - I thought you'd said previously you were in favour?

CA: sensing a consensus

RESOLUTION: agree to explore ways to add "down to"

2. Level(s) for 1.4.10 Reflow #1050

CA: if prevous quesiton is confirmed we need to know how
... depricate current or add, or update to a down to
... should we update to down to or depricate

AC: i do think its a backwards compatible change

CA: i was the only one siad AA but not strong to it

KH: defintiely not depricate

CA: Wayne you wanted to do, on call

AC: Wayne is enthusiatic for this

KH: may be incorrect in speaking for Wayne might not know

AC: might need to tak him off mailing list

<Zakim> mbgower, you wanted to say that we have an established way to proceed from Focus Visible

CA: update to ‘down to’ lots of positives

MG: one other way to tackle, to move current to single =A and resuce higher reuirment to AA

RESOLUTION: Unresolved, continue next week.

AC: that was third option to come back to it next weeek

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/* "0"s//
Succeeded: s/sts/it’s/
Succeeded: s/JS: do we want to have AAA to match AA for text/JF: do we want to have AAA to match AA for non-text contrast/
Succeeded: s/addtion/addition/
Succeeded: s/internt/intent/
Default Present: Francis_Storr, kirkwood, Jennie, PascalWentz, CharlesHall_, Nicaise, MichaelC, GN, Brooks, JF, Mike_Pluke, Fazio, JakeAbma, mbgower, Katie_Haritos-Shea, ok, Laura, david-macdonald, .5, OmarBonilla
Present: Francis_Storr kirkwood Jennie PascalWentz CharlesHall_ Nicaise MichaelC GN Brooks JF Mike_Pluke Fazio JakeAbma mbgower Katie_Haritos-Shea ok Laura david-macdonald .5 OmarBonilla GN015
Regrets: Bruce Bailey AWK
Found Scribe: ChrisLoiselle
Inferring ScribeNick: ChrisLoiselle
Found Scribe: kirkwood
Inferring ScribeNick: kirkwood
Scribes: ChrisLoiselle, kirkwood
ScribeNicks: ChrisLoiselle, kirkwood

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: Input appears to use implicit continuation lines.
You may need the "-implicitContinuations" option.


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