<laura> Scribe: Laura
RM: Any new members?
... Any new topics?
(none)
<mbgower> +1
RM: moving to more asynchronous communication
<Rachael> [email protected]
RM: set up a new email list.
<alastairc> Archive: https://lists.w3.org/Archives/Public/public-ag-admin/
RM: It is at: [email protected] for closing issues, etc.
<Rachael> While we have made changes to address the issue, the content is not finalized. This content may be updated, replaced, or could be removed in future edits.”
RM: would like to use that text going forward.
gregg: are this to specific people and issues?
rm: it is for GitHub
response.
... any concerns on wording?
bruce: are we already subscribed?
rm: yes
JF: 2 issues came from email. so not linked to github
rm: we will set up a process for that.
<bruce_bailey> i am okay with wording
<Rachael> While we have made changes to address the issue, the content is not finalized. This content may be updated, replaced, or could be removed in future edits.”
<Chuck> +1
<bruce_bailey> GV:
<JF> +1 to Gregg
<Rachael> While we have made changes to address the issue, the content is not finalized. We are early in the draft process and this content may be updated, replaced, or could be removed in future edits.”
greeg: add "we are early in the draft process."
<Chuck> +1
greeg: thanks
rm: do we want to use this list for the editor's draft?
<Jaunita_George> +1
<alastairc> +1
rm: for exploratory content.
<mbgower> +1
<iankersey> +1
<Chuck> +1
<bruce_bailey> +1
<jweismantel> +1
<GreggVan> +1
<ShawnT> +1
<kirkwood> +1
<Wilco> +1
<Peter_Bossley> +1
gregg: it will be a primary list for consensus.
<GreggVan> +1
rm: please be concise on the
list.
... it is for short small changes.
<Rachael> https://www.w3.org/WAI/GL/communication
<Rachael> Please review the approval to ad WCAG2ICT Task force survey at https://www.w3.org/2002/09/wbs/35422/WCAG2ICTV2/ open till end of day
<Rachael> Please answer https://www.w3.org/2002/09/wbs/35422/charter-approach-reasons/ open until end of day
<Rachael> Please review the WCAG 3 Pronunciation of Text survey at https://www.w3.org/2002/09/wbs/35422/pronounciation_wcag3/
<Zakim> bruce_bailey, you wanted to ask about charter discussion next week
rm: we will talk about the charter next week
rm: first up is Page break locators
rm: we agreed to leave the definition of "page break locators" as it is, but update the understanding document.
<Rachael> PR: https://github.com/w3c/wcag/pull/2350
rm: The update to the understanding document is in PR 2350.
ac: gn had a comment that I incorporated into the PR
<Rachael> https://github.com/w3c/wcag/pull/2366
ac: mg thinks think the new
paragraph should be moved later in the introduction.
... made a PR
... having something at the top would be useful.
mg: just suggestions. take it or leave it.
<bruce_bailey> there is a new paragraph, which is a nice add
<mbgower> can always keep the position and just add wording changes
mg: only move it down a
paragraph.
... added material to the note.
<bruce_bailey> +1 to MG for talking about what-it-is before what-it-is-not
<Chuck> +1 to MG's PR
rm: anyone object?
<Rachael> Draft resolution: Accept updated understanding per PR 2366 with GN's correction
gregg: we have techniques for non html?
<mbgower> that seems orthogonal
ac: sc is scoped to html
<Rachael> Draft resolution: Accept updated understanding per PR 2366 with GN's correction
<GreggVan> +1
<Chuck> +1
<mbgower> +1
<bruce_bailey> +1
<iankersey> +1
<jweismantel> +1
<kirkwood> +1
<GN015> +0
<ShawnT> +1
<Wilco> 0
<Nicaise> +1
<alastairc> +1
<Francis_Storr> +1
<Raf> +1
Laura: +1
RESOLUTION: Accept updated understanding per PR 2366 with GN's correction
rm: Melanie asked whether online
applications such as Google docs and Word, or Slide and
PowerPoint are in scope of this SC.
... The intended answer is no, and hopefully the previous
question will have resolved that.
<Rachael> Full response: https://github.com/w3c/wcag/issues/2274#issuecomment-1083331096
rm: However, during the thread
another commenter was making a case that these applications
should be in scope.
... The response was essentially: That's a new requirement, not
intended to be covered in this SC.
wilco: my comment is out of date
rm: Stefan said If this is a NEW requirement, sooner or later the question will be raised in public WHY so you have clearly to state the reasons for the exception as part of scope #2274.
bruce: should the proposed response should be the last response?
ac: I will add it to the end
<bruce_bailey> thanks, +1 to AC proposal to wrap up thread
gregg: rationale for SC is in a
technique instead of the understanding doc?
... need to be careful not to put anything needed for
understanding in a technique.
ac: people are widening the scope.
<Rachael> draft RESOLUTION: Accept response, Alastair will wrap it up at the end of the thread
ac: want people to understand when it would apply.
<mbgower> +1
<bruce_bailey> +
<GreggVan> +1
<bruce_bailey> +1
<jweismantel> +1
<kirkwood> +1
<Chuck> +1
<Ryladog> +1
laura: +1
<Peter_Bossley> 0
<GN015> +1
<ShawnT> +1
<iankersey> +1
<Peter_Bossley> Pass
RESOLUTION: Accept response, Alastair will wrap it up at the end of the thread.
rm: Wilco raised issue 2159, which raised an odd case where nested links can allow a large (but mostly covered) link to pass.
<Rachael> PR: https://github.com/w3c/wcag/pull/2330/files
<Rachael> Response: https://github.com/w3c/wcag/issues/2159#issuecomment-1111591756
rm: There was a long discussion,
and Wilco thought that a change would cause more
problems/complexity than it solves.
... A side discussion on nested links lead to PR 2330, which
adds a little to the target-offset definition. The intent of
the update is to exclude other links from the A to B
measure.
... wilco Agree the response, rejected the update (not
change)
... gn said, I feel the wording is overly complicated and
triggers fantasy to trick.
<Rachael> Themes: Targets other than A and B do not contribute to the spacing.
<mbgower> 'sizes of these targets' is better (that was existing language)
<Rachael> adding: if the sizes of these targets differ.
<mbgower> and removing it from "differs"
ac: sizes is just adding an
"s"
... for wilco's concern it came from trying to close off a
thread
<Wilco> I think it's quite confusing
ac: can drop if it is confusing.
<alastairc> "the distance measured from the farthest point of a target (A), to the nearest point of the second target (B). The offset includes the target and spacing around the target. The offset from A to B may be different than the offset from B to A, if the sizes of these targets differ."
<Rachael> draft RESOLUTION: Accept the response and changes but trop the “Targets other than A and B…” Change the sentence to “sizes of these targets differ.”
<mbgower> +1
<bruce_bailey> +1 for proposed response
Laura: +1
<jweismantel> +1
<Chuck> +1
<Ryladog> +1
<kirkwood> +1
<iankersey> +1
<ShawnT> +1
<Peter_Bossley> +1
<Detlev> +1
<Wilco> +1
<GN015> +1
RESOLUTION: Accept the response and changes but trop the “Targets other than A and B…” Change the sentence to “sizes of these targets differ.”
rm: Wilco raised issue 2162
pointing out an issue with the update text.
... In summary, the new wording says is that anything that's
more than 24 x 24px passes.
<Rachael> PR: https://github.com/w3c/wcag/pull/2331/files
rm: The intent is that the default case is that for each target, you can draw a 24x24 square that is exclusively part of that target.
PR 2331 implements that change.
ac: more similar to AAA
version.
... (reads Andrew Somers comment)
<mbgower> basically he's making the point that applying a generic pointer standard across both touch and mouse is problematic
ac: misunderstood some of the details around pixel density.
<Zakim> alastairc, you wanted to talk to Andrew's comment
ac: need to provide the lowest bar that we can.
MG: for strangely shaped hit areas. But it lets anything super thin passes.
gn: concernedabout area
wording.
... don't agree with change.
<kirkwood> +1 to GN issues wording saying the area
gregg: horizontal line on a page is an example. impossible to hit.
<mbgower> no, you'd just need an affordance that is 24x24 to move the window
gregg: troubled by anything to do with size.
<Zakim> mbgower, you wanted to say it is because the new wording says area not size
wilco: feels like a bad interpretation.
<alastairc> https://github.com/w3c/wcag/issues/2162
<GN015> +1 to MIke
wg: it is trying to be more consistent.
ac: problem is people read in an
overlap issue.
... maybe there is a 3rd way.
<Zakim> JF, you wanted to note that "24 X 24" as area = "576 square pixels"
ac: will type something up.
jf: maybe use surface area.
<alastairc> The size of the <a>target</a> for <a>pointer inputs</a> is at least 24 by 24 CSS pixels exclusively, except where:
<alastairc> or "without overlap"
jf: use compound square value.
<JF> +1 to Wilco - words mater
<alastairc> Noting that target is defined as an area of the screen
wilco: using the word area in 2
different ways.
... maybe use a different word.
<Zakim> mbgower, you wanted to say how common is an embedded target?
<JF> "surface area"?
<JF> "hit area" (somewhat geeky but also accurate)
mg: make it more clear in the wording. how common is an embedded target?
<SuzanneTaylor> seems like targets with holes could be covered in understanding
<Zakim> GN, you wanted to name some examples
<alastairc> JF - we don't want to use an area that is easy to 'squish, because you can have unusable wide & thin links
gn: examples in tables
... some very narrow.
<JF> AC - you could add "and no less than 1 em in height or width"
<alastairc> The size of the <a>target</a> for <a>pointer inputs</a> is at least 24 by 24 CSS pixels exclusively, except where:
ac: what does the new wording mean to you.
<Chuck> +1 to Rachael, it does not clarify for me
rm: doesn't clarify for me.
<Zakim> JF, you wanted to ask the impact on "icons" which are very often 16 X 16...
jf: concerned by 24x24 pixels because of icons.
<alastairc> The size of the <a>target</a> for <a>pointer inputs</a> is at least 24 by 24 CSS pixels, exclusive of other targets, except where:
<Zakim> mbgower, you wanted to say exclusive of other targets
mg: we are not changing the size. It is already in the sc text.
wilco: not comfortable without going through my 100 examples.
<Rachael> proposed approach: The size of the <a>target</a> for <a>pointer inputs</a> is at least 24 by 24 CSS pixels, exclusive of other targets, except where:
wilco: going back to the original wording may be better.
<Zakim> SuzanneTaylor, you wanted to say that I think most people would read the original language to mean at least 24 to 24 of space to click within, and this could be enforced in the
st: agree with Wilco. New language brings up more issues. Keep original language.
<Rachael> straw poll: 1) Targets have an area of at least 24 by 24 CSS pixels, except where 2) The size of the target for pointer inputs is at least 24 by 24 CSS pixels, 3) The size of the <a>target</a> for <a>pointer inputs</a> is at least 24 by 24 CSS pixels, exclusive of other targets, except where: 4) something else
mg: target definition should be fine.
<GN015> should it maybe say 'excluding other targets' instead of 'exclusive of other targets'?
<Rachael> straw poll: 1) Targets have an area of at least 24 by 24 CSS pixels, except where 2) The size of the target for pointer inputs is at least 24 by 24 CSS pixels, 3) The size of the target for pointer inputs is at least 24 by 24 CSS pixels, exclusive of other targets, except where: 4) explore surface area 5) something else
<Zakim> JF, you wanted to ask if #4 could reflect surface area (hit area) as a compound value (i.e. height X width = minimum value)
<alastairc> Yep - I was hoping that definition helps keep the current text
gregg: target is the active area so would be redundant.
<Wilco> proposal: Targets for pointer inputs have an area with a width and height of 24 CSS pixels, except where
<JakeAbma> 2, 3
<Chuck> 1, 2
<mbgower> 2 I prefer the original wording. I don't think the rewording on today's call gets there, but can live with it
<Rachael> straw poll: 1) Targets have an area of at least 24 by 24 CSS pixels, except where 2) The size of the target for pointer inputs is at least 24 by 24 CSS pixels, 3) The size of the target for pointer inputs is at least 24 by 24 CSS pixels, exclusive of other targets, except where: 4) explore surface area 5) something else
<Ryladog> 2,3
<GreggVan> 5, Wilco
<GN015> 2
<JF> 4, 5
<mbgower> 2,3
<Rachael> 2,3
<SuzanneTaylor> 2 (can live any of the others)
<alastairc> 2 - current text (reject PR), 1, 3, not 4
<ShawnT> 2,3
<jweismantel> 2, 3
<Wilco> 5, 2, 1, 3, 4
<iankersey> 2
2, 3, wilco
<Detlev> 2, 3, 1 - It should be 2, in the interest of simplicity: I am sure many readers will struggle with "exclusive of" expression
<GN015> I also like Wilco's proposal
<Peter_Bossley> 2
<kirkwood> 2) but like the potential language of “interactive area” for clarity
mg: seems like an easy decision. folks can make suggestions.
<Wilco> proposal: Targets for pointer inputs have an area with a width and height of 24 CSS pixels, except where
<mbgower> that doesn't solve your edge case
<alastairc> Kirkwood - that's already the definition for target: https://w3c.GitHub.io/wcag/understanding/target-size-minimum.html#dfn-target
wilco: made a proposal: Targets for pointer inputs have an area with a width and height of 24 CSS pixels, except where
<JF> so, by that language, a target area of 23 px X 200 px would fail...
<alastairc> JF- correct, and that's the intent.
<Zakim> mbgower, you wanted to say that does not plug the hole
<JF> @alastair then expect objections
mg: don't think it plugs the hole.
<kirkwood> yes
<Rachael> scribe: kirkwood
<Zakim> GreggVan, you wanted to say -- correct - I misread wilco. wilco combines 1 and 2 but is solves the problems in 1. I would suggest either "has a height and width
Gregg: reading his suggestion
RM: Cirling back to Alastair and Gower
MG: still doesn’t plug hole. such as the donut which is hole and donut issue. have 24 by 24 regardless of rewording
AC: I agree
<GN015> I do not agree a narrow donut has 24 by 24 px, as the narrow width of the donut spoils that measurement
<Chuck> +1 to AC
AC: looking for area 24 by 24 without other targets, definition of target helps us. not problem in 2.1 shouldn’t be a problem now
<Zakim> GreggVan, you wanted to ask can you get a donut out of " area that is at least 24 CSS px high and wide."
RM: proposing a resoltion to update understanding
GV: acception of area as width and height may be confusing
RM: not my understanding
MG: already have reading 24 by 24 not altering issue that Wilco with nested targets
RM: will suggest a draft resolution
<Zakim> GreggVan, you wanted to sy a contiguous area that is at least 24 pix high and wide
MG: saying contiguous area does not accomplish a size
<Peter_Bossley> I think mapping out the proposals so that we can think them through is probably a good idea.
<alastairc> The size of the <a>target</a> for <a>pointer inputs</a> is at least 24 by 24 CSS pixels, except where:
<Rachael> draft RESOLUTION: No change to current wording from this proposal. Anyone who has proposed alternate wording, submit against issue for consideration.
AC: could we get a poll?
<Chuck> +1 for current wording
<Zakim> GreggVan, you wanted to suggest a solid area that is and to
<mbgower> It's already in place. Isn't it up to someone to provide a better wording that gets traction?
<JF> +1 to Gregg
GV: issue was raised about existing wording seems still not there
<SuzanneTaylor> +1 for current wording (problems covered with example images in Understanding doc)
GV: if close we should close
it
... is a solid area 24 high by wide, if not i back out
AC: if described as an area then its not a size not an area
<mbgower> We already have that
<Rachael> The size of the target for pointer inputs is at least 24 by 24 CSS pixels, except where:
GV: an area of 24 by 24 can meet
<SuzanneTaylor> "solid" sounds like coloring/fill
RM: that is option 2
... no way to move forward then we default to it
<Chuck> +1 to draft resolution
<GreggVan> +1 to keeping current
<Ryladog> +1 for current wording (problems covered with example images in Understanding doc)
<Rachael> draft RESOLUTION: No change to current wording from this proposal. Anyone who has proposed alternate wording, submit against issue for consideration.
<GreggVan> +1 to resolution
<mbgower> +1
<Ryladog> +1
RM: don’t see a way to make change from this particular proposal, then we can come back if other wording has momentum
<alastairc> +1
<jweismantel> +1
<GN015> +1
<ShawnT> +1
<Wilco> 0
<alastairc> I can also draft a response and do an understanding update.
<laura> +1
<JakeAbma> +1
<bruce_bailey> +1
+1
<GreggVan> agree
<laura> s/to prvide /to provide /
RM: resolving the word common
<GreggVan> +1 to adding somethign to understanding to resolve last problem
RESOLUTION: No change to current wording from this proposal. Anyone who has proposed alternate wording, submit against issue for consideration.
<Rachael> PR: https://github.com/w3c/wcag/pull/2386/files
RM: five people agreed with removing common and alternative version
<GreggVan> +1 to removing common a fixed list is not a good idea lists in standards are to be avoided
RM: going through list of people who agreed with removing common
<alastairc> After Rain's comment, I wish I'd thought of that earlier.
RM: Bruce wanted fixed list of terms but would agree with common
GV: to removing common and not fixed list
<Rachael> draft RESOLUTION: Approve PR 2386 to remove the word Common
<Chuck> +1
<Rachael> +1
<alastairc> +1
<GreggVan> +1
<SuzanneTaylor> +1
<iankersey> +1
<Peter_Bossley> +1
<Wilco> +1
+1
<ToddL> +1
<laura> +1
<Ryladog> +1
<mbgower> 0
<ShawnT> +1
<Francis_Storr> +1
<Raf> +1
RESOLUTION: Approve PR 2386 to remove the word Common
<Rachael> Focus appearance (enhanced) https://raw.githack.com/w3c/wcag/Focus-appearance-enhanced-updates/understanding/22/focus-appearance-enhanced.html
<Rachael> Focus not obscured (minimum) https://raw.githack.com/w3c/wcag/Focus-appearance-enhanced-updates/understanding/22/focus-not-obscured.html
<Rachael> Focus not obscured (enhanced) https://raw.githack.com/w3c/wcag/Focus-appearance-enhanced-updates/understanding/22/focus-not-obscured-enhanced.html
AC: having updated focus appearance minimum impacted AAA version and focus not obscured same as previous draft separated out. aim was to bring up to date with all edsicussion on AA version
RM: laura agreed with comment and
mike gower comments as well
... anyone want to add to comments
... two agreed with adjusments and theme about exceptions
... reading about enhancing contrast and area and theming spoke
about focus not obscured Gundula was saying
... general themes to keep them and exceptions rewording by
Gundula
<Rachael> Themes: exceptions, Gundala's rewording suggestions
<mbgower> TMI
;)
GN: should size be doubled, think it needs to be clearer and contrast should be 4.5 to 1 not 3 to 1
<Rachael> 1. Should the size be doubled, 2. Should enhanced be 4.5:1?
<Zakim> mbgower, you wanted to say that to Gundula's point the contrast is increased for Enhanced
<GreggVan> +1 to what mbgower just said
<GN015> + on color contrast value
<GreggVan> about contrasts
MG: can’t talk about exceptions, contrast info in previous enhanced and contrast not changed and with existing wording. on exception i did double the area. double area to at least as large as 8 versus 4 pixels thik, couble area increase in contrast are changes from me
<Zakim> GN, you wanted to comment on color contrast value
AC: can pass primary part of SC and no size or thickiness so wouldn’t pass through to exception, given to increase contrast should be ok
<mbgower> yes, increase in contrast. 4.5:1 is a strong focus appearance for non-text
<alastairc> 1px thick line is like large text, we had a discussion about that during non-text contrsat.
GN: 7 to 1 for text, but nontext equal to text threshold should be 4.5 to 1. so one pixel wide should have high contrast. prefer 7 to 1 by users. unfocused state shouldn’t be an issue. agree that 1 pixel width is sufficient by end users as well
<Zakim> mbgower, you wanted to say these are pre-existing numbers in the current draft https://www.w3.org/TR/WCAG22/#focus-appearance-enhanced
Wilco: why the contrast numbers 4 to 8
MG: have not changed the
contrast
... what i have done with wording to double perimeter we should
double one side
... did not introduce new metrix into that
<Rachael> Draft RESOLUTION: Approve splitting apart the SC, resolutions on details to follow
RM: no debate about splitting SC
<Peter_Bossley> +1
<Wilco> +1
<iankersey> +1
<Chuck> +1
<mbgower> +1 to breaking out the Not obscured
<GN015> +1
<ToddL> +1
<ShawnT> +1
<Ryladog> +1
<Detlev> +1
+1
<jweismantel> +1
<alastairc> +1, noting that we split it to have a simple, higher requirement at AAA originally
<laura> +1
<SuzanneTaylor> +1
RESOLUTION: Approve splitting apart the SC, resolutions on details to follow
<Rachael> Draft RESOLUTION: Leave in the exceptions
<mbgower> +1
<Rachael> +1
RM: not much debate about these exceptions
+1
<alastairc> +1, alhtough happy to reduce them if possible.
<Wilco> 0
<jweismantel> +1
<Ryladog> +1
<Chuck> 0
<ShawnT> +1
<GN015> +1
<ToddL> +1
RESOLUTION: Leave in the exceptions
<Rachael> Draft RESOLUTION: Increase the color contrast to 4.5:1 in Enhanced SC
<Rachael> Draft RESOLUTION: Increase the adjacent color contrast to 4.5:1 in Enhanced SC
<mbgower> -1 I would really want that thought through before committing to that
<Rachael> -1
<alastairc> -1
-1
<Chuck> -1
<GN015> +1
AC: approach on original we were going for quite thick 2 pixel minimum other option would be two increase default thickness and drop adjacent one. but worry about 4.5 to 1 for adjacent because narrows palet
<Rachael> Draft RESOLUTION: Keep the adjacent color contrast at 3:1 in Enhanced SC
<alastairc> +1
<Chuck> +1
<ShawnT> +1
<mbgower> +1 I'm happy to have someone investigate increasing
<Ryladog> +1
<GN015> 0 can live with it, not happy with it
<GreggVan> +1
Wilco: why do one without other, don’t think we should
<Zakim> mbgower, you wanted to say why it is like it is
MG: not in current enhanced appearnce, i tried to change as litle as possible the reason why
RM: lets talk about thickness, MG suggest talking about doubling thikness
<mbgower> Totally understand that. I'm just explaining why it is like it is.
AC: primary compnent doesn’t
increase, either drop the adjacent exception and increase in
fisrt bullet
... I’m fine with it as is or double thikcness in first bullet
and drop adjecent in exception
MG: needs to be clearly defined 4.5 to 1 against non focused state to pass enhanced and thats why its like that
<Rachael> draft RESOLUTION: keep the current wording regarding thickness
<GN015> -1
<alastairc> "Is at least as large as double the area of a 1 CSS pixel thick perimeter of the unfocused component, or is at least as large as an 8 CSS pixel thick line along the shortest side of the minimum bounding box of the unfocused component, and"
<alastairc> +0.5
<Rachael> 0
<GreggVan> +1
<Chuck> +1
we have an exeption
<mbgower> +1 but I think it's the non-exception that is the focus of discussion
<Wilco> -1
0
<Ryladog> +1
<ShawnT> 0
<laura> +1
<alastairc> Alternative - Adjust the first bullet to "Encloses the visual presentation of the user interface component and is no thinner than 2 CSS pixels".
MG: there is no size in non exception language, want to clarify
RM: voting on keeping concept of exception
<alastairc> For context, this is the previous version https://w3c.github.io/wcag/understanding/focus-appearance-enhanced.html
<mbgower> Alastair's wording seems to work
Wilco: think we should potinetially not having contrast bullet have the no thinner than 2 pixels bullet there
<Wilco> is no thinner than 2 CSS pixels.
<Wilco> +1, gd point GN
GN: non enhanced normative part is easy to understand, but halo by exception would apply. now if has a halo it would fail. either should be doubled outside excpetion or not doubled insde the exception
RM: would wording MG be acceptable?
GN: yes
<Zakim> GreggVan, you wanted to say -- it says exceptions but there is only 1. and since there is only one -- I think the whole thing should be restructured to be EITHER a+b+c
Gregg: should be singular, should be restructured as either ABC or DEF no exceptions
<SuzanneTaylor> +1 either/or would be easier to follow
<mbgower> That's going to take a lot of rewrites to the Understanding doc
AC: Gundula easy change, on Greggs point we can change the wording to either structure
<Rachael> Draft RESOLUTION: Change the first bullet "Encloses the visual presentation of the user interface component and is no thinner than 2 CSS pixels".
<Rachael> Draft RESOLUTION: Change the first bullet to "Encloses the visual presentation of the user interface component and is no thinner than 2 CSS pixels".
<GreggVan> +1
+1
<Chuck> +1
<alastairc> The understanding doc on the AAA version isn't that big
<laura> +1
<alastairc> +1
<mbgower> +1 or to pull back the language in the exception to not double
<Wilco> 0
<ToddL> +1
<ShawnT> +1
<Wilco> feels like it should be a bullet, not part of the initial wording
<GN015> +0.5 (still feel double size is not needed)
<Ryladog> +1
<SuzanneTaylor> 0 does this drop the 8 CSS pixels accidentally?
<mbgower> it came from the existing SC
Wilco: where are we getting doubling from?
<mbgower> Minimum area: The contrasting area is at least double the area of a 1 CSS pixel perimeter of the unfocused component;
<mbgower> ^ That's the existing
AC: it is from current SC
<mbgower> We are!
<mbgower> or sentiment anyway :) not verbatim
RM: general support for this wording
RESOLUTION: Change the first bullet to "Encloses the visual presentation of the user interface component and is no thinner than 2 CSS pixels".
<Rachael> Draft RESOLUTION: Change the structure from exceptions to either/or and rewrite understanding to match
RM: if you have an issue welcome to file in github
<Chuck> -0.2
GN: like to ask group for last bullet point for if touches button and increases size not so easy to spot, contrast enhanced should be 4 pixel wide double normal focus indicator, do you agree?
<Chuck> +1 to mbgower
MG: offer caution about changing things on the fly, don’t know what it causes. tried to stay consistent. i get nervous without research
Wilco: in agreement seems arbitrary needs more thought
<Rachael> Draft RESOLUTION: Change the structure from exceptions to either/or and rewrite understanding to match
<SuzanneTaylor> +1 to Wilco's latest statement
RM: not enough support here it seems
<GreggVan> +1
<Chuck> -0.2
<alastairc> +1
<SuzanneTaylor> +1 to either or
<mbgower> -.5
<Ryladog> +1
CA: not outright objecting
<Wilco> -.5, prefer "exception"
MG: not sure have cycles to do on understanding document
<GN015> -1 as either or is exclusive, while a focus indicator fulfilling the first option also fulfills the second
MG: I get the oddity on exception but can’t vote with hard objection
<GreggVan> ok
RM: Gregg can you file issue with
propsed alternative wording?
... anything that must be said?
GN: should be with or rather than or
<GreggVan> got it
GN: should be with or either or
rathan or
... either or rather than or
<GN015> GN: should be or instead of either .. or
<GreggVan> I think it is OR and not EITHER - OR
<GreggVan> if I understood her correctly
<GN015> to gregg: yes, you did
<mbgower> ...the focus indicator either:
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/subscibed/subscribed/ Succeeded: s/github/GitHub/ Succeeded: s/explotitory/exploratory/ Succeeded: s/dow a paragraph/down a paragraph/ Succeeded: s/is scped to /is scoped to / Succeeded: s/propoesd reponse /proposed response / Succeeded: s/sneed to /need to / Succeeded: s/odd cases/odd case/ Succeeded: s/discussion, and it /discussion, and / Succeeded: s/to prvide /to provide / FAILED: s/to prvide /to provide / Succeeded: s/But lets /But it lets / Succeeded: s/concered /concerned/ Succeeded: s/yo'd /you'd / Succeeded: s/intermpretation./interpretation./ Succeeded: s/concerened /concerned / Succeeded: s/orginal woring /original wording / Succeeded: s/orginal /original / Succeeded: s/descion/decision/ Succeeded: s/i get oddity/I get the oddity/ Default Present: Laura_Carlson, Chuck, Rachael, bruce_bailey, alastairc, Peter_Bossley, jweismantel, Fazio, JakeAbma, GreggVan, Wilco, mbgower, iankersey, Detlev, Nicaise, ShawnT, MichaelC, JF, kirkwood, Jaunita_George, Francis_Storr, Katie_Haritos-Shea, ToddL, Jen_G, GN, SuzanneTaylor Present: Chuck, Detlev, Fazio, Francis_Storr, GN, GreggVan, JF, JakeAbma, Jaunita_George, Jen_G, Katie_Haritos-Shea, Laura_Carlson, MichaelC, Nicaise, Rachael, ShawnT, SuzanneTaylor, ToddL, Wilco, alastairc, bruce_bailey, iankersey, jweismantel, kirkwood, mbgower, Peter_Bossley, GN015 Regrets: Todd L, Alastair G, Melanie P, Sarah H, Justine P Found Scribe: Laura Inferring ScribeNick: laura Found Scribe: kirkwood Inferring ScribeNick: kirkwood Scribes: Laura, kirkwood ScribeNicks: laura, kirkwood 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.)[End of scribe.perl diagnostic output]