<laura> Scribe: Laura

New members and topics

RM: Any new members?
... Any new topics?

Announcements

(none)

<mbgower> +1

RM: moving to more asynchronous communication

<Rachael> public-ag-admin@w3.org

RM: set up a new email list.

<alastairc> Archive: https://lists.w3.org/Archives/Public/public-ag-admin/

RM: It is at: public-ag-admin@w3.org 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

Do we want to use the email list as a first pass on adding exploratory content

<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

WCAG 2.2 Page break locators https://www.w3.org/2002/09/wbs/35422/wcag22-page-break-nav/

rm: first up is Page break locators

Page break locators - Understanding doc scope update #2350

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

Are online word processing and slide applications in scope #2274

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.

WCAG 2.2 Target Size https://www.w3.org/2002/09/wbs/35422/wcag22-target-size-min/

Multiple overlapping elements interact oddly with offset #2159

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

Use "area" in target spacing (minimum) #2162

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

New members and topics

WCAG 2.2 Accessible Auth https://www.w3.org/2002/09/wbs/35422/wcag22-accesssible-auth-updates/

<laura> s/to prvide /to provide /

Resolving 'common' objects #2386

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

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

Update Focus Appearance Enhanced and split Focus Not Obscured #2365 https://usercontent.irccloud-cdn.com/file/Y7Y2K3Bt/image.png

<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> https://raw.githack.com/w3c/wcag/Focus-appearance-enhanced-updates/understanding/22/focus-appearance-enhanced.html

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