<ChrisLoiselle> scribe:ChrisLoiselle
<Sukriti> I can do it but a new member
<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.
We are talking to first 4 questions on this call, on focus visible enhanced issues.
<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
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
<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.
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
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
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
<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"
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.)[End of scribe.perl diagnostic output]