AGWG Teleconference -- 28 Mar 2023

<bruce_bailey> partial regrets in that I have to drop off at 12:30 eastern

<Laura> scribe: Laura

New members and topics

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

Announcements

RM: TPAC 2023 is from 11-15 sept.

<Rachael> TPAC 2023 will be held from 11 to 15 September 2023, with a main in-person hub at Melia Sevilla Hotel, in Sevilla, Spain.

<Rachael> WCAG 3 Survey https://www.w3.org/2002/09/wbs/35422/WCAG3_conformance_March_23/

RM: need to decide if we want to meet for TPAC.

<scribe> ... new WCAG 3 Survey available.

UNKNOWN_SPEAKER: so we have a doc to work from.

WCAG 2.2 Target Size, Q1-2 (not new questions) https://www.w3.org/2002/09/wbs/35422/wcag22-misc5/results

<alastairc> https://docs.google.com/document/d/1N38qrHOJSXW-OrJI7GiSjQwaYZxh5OBDJ36No7p2Ax4/edit#

<Rachael> Summary Doc https://docs.google.com/document/d/1N38qrHOJSXW-OrJI7GiSjQwaYZxh5OBDJ36No7p2Ax4/edit#heading=h.7f7j4lnmyz6c

AC: had a survey and background work.
... Wilco raised issue 3050

2.5.8 Target Size "overlapping any other target" does not work #3050

AC: looked at a couple of options.
... sharing screen with an example.

<kirkwood> -1 for “immediately adjacent” incorrect

AC: 2 options.
... Option 1: Update language of current version
... Option 2: Switch to ‘circles’
... some proposed text.

<Rachael> Proposed revised spacing exception: Spacing: Undersized targets that do not meet another exception are positioned with sufficient spacinged sosuch that if a 24 CSS pixel diameter circle is centred on each, none of the circles intersect another circle or target.

<AWK> +AWK

AC: "Spacing: Undersized targets that do not meet another exception are positioned with sufficient spacinged sosuch that if a 24 CSS pixel diameter circle is centred on each, none of the circles intersect another circle or target."

<Rachael> Proposed revised spacing exception: Spacing: Undersized targets that do not meet another exception are positioned with sufficient spacing so that if a 24 CSS pixel diameter circle is centred on each, none of the circles intersect another circle or target.

AC: comments around odd shapes
... 3 choices. leave at is. Update language of current version. or Switch to ‘circles’.

RM: anyone want to call out anything from survey?

<bruce_bailey> Example: Bullseye target with center target 23px diameter, dead space ring of 22px thickness, and a 2nd target which is a circular ring outside of that 4px thick. "Circles centered on each target" for this bullseye example means a 24px diameter circle centered in the bullseye and a 24px diameter circle with its center in the middle (i.e., 2px in) **anywhere** on the outside ring.

bruce: will paste in comment.

wilco: did not see this update. this looks quite different.

ac: hasn't changed conceptually.
... change made for undersized target.
... quite narrow.
... toolbars aren't an issue then.
... can cover details in the understanding doc.

<bruce_bailey> bounding box does not help with bullseye example

mg: added to understanding doc on how to handle the center.
... it is the bullseye argument.
... make it 24x24 so it doesn't fail.
... it is an edge case.

wilco: unusual shapes are common on the web.
... e.g. link with an image.

<alastairc> but that's gonna be much bigger than 24...

gn: question: is the white space part of the target?

ac: it is linked in the doc

gregg: not just talking about fingers. also talking about mice.

<Ben_Tillyer> +1 to gregg

<jon_avila> Thank you Gregg.

<Rachael> ack ack bruce_bailey

<kirkwood> +1 to Gregg

gregg: make it simple so it applies more generally.

<Zakim> bruce_bailey, you wanted to say i don't believe that (1) 23 + (2) 22 (deadspace) + (3) 4 makes either the center (1) or (3) hard to hit.

<Zakim> mbgower, you wanted to say I can maybe answer?

<bruce_bailey> what is the size of targets on screen at present ?

Bruce: target size if toolbar square?
... it is a big target.

rm: isn't it 2 separate targets?

<Zakim> mbgower, you wanted to say

bruce: yes.
... talking about the ring around the bullseye.

mg: make inner target bigger. have you ever seen that in the wild?

gregg: is that a common practice?

<alastairc> Bruce, how's my diagram?

gregg: think of this not just for fingers but for mice.

<bruce_bailey> dead space should have radius of about 48 px

jon a: green circle passes. It would pass with the appropriate padding.

<bruce_bailey> present example looks good

ac: suggestion would be that they wouldn't meet the exception.
... outer circle not that easy to hit.

<Zakim> GN, you wanted to ask how do we handle a kind or rounded progress indicator (bullseye)?

ac: it is an odd case that would fail.

<dan_bjorge> Note that you have google docs at 133% zoom, the real sizing is even smaller than that

gn: struggle with the definition of center.

<Rachael> strawpoll: 1) Keep the current wording and address concerns in understanding 2) Update the spacing with the circle alternative discussed 3) Something else

gn: seems like series of targets that belong together.

<Rachael> strawpoll: 1) Keep the current wording and address concerns in understanding 2) Update the spacing with the circle alternative discussed 3) Something else

<mbgower> 2

<dan_bjorge> 2

<Wilco> 0, not enough time to review

<GN015> 2

<Detlev> 2

<ShawnT> 2

<alastairc> 2, can live with 1

<bruce_bailey> 3 1 2

laura: 2

<GreggVan> 2

<Makoto> 0, in any cases, should have visual examples of pass/fail

<bruce_bailey> i can live with any

db: Patrick has visual examples.

<dan_bjorge> PR with draft understanding updating including new examples: https://github.com/w3c/wcag/pull/3103

<kirkwood> would it be too much to put language we are voting on in irc?

wilco: only got this version yesterday. Not sure we should be voting.

<Detlev> Patrick's visualization: https://raw.githack.com/w3c/wcag/patrickhlauke-target-size-minimum-issue3089-companion/understanding/22/target-size-minimum.html

<alastairc> "Undersized targets that do not meet another exception are positioned with sufficient spacing such that if a 24 CSS pixel diameter circle is centred on each, none of the circles intersect another circle or target."

rm: have discussed for months. we may need to pull the SC.

mg: this is not marked at risk.
... we have issues of overlapping.
... pr has been out for at least 3 weeks.

<bruce_bailey> being able to drop "target offset" as defined term would be a big plus

<alastairc> +1, it's been discussed a lot

mg: has been attempt to be thorough.

ac: could mark at risk with fall back to return to previous language.

<Wilco> Don't know

<mbgower> not me

rm: who would object to that?

<Detlev> no objection

<ShawnT> no objections

<Rachael> If we make the change and add the old language as an at risk option to fall back to if we find a problem during CR, who would object to the CFC?

laura: not me

<GN015> no objection

<dan_bjorge> no objection

<Jay_Mullen> no objection

<bruce_bailey> no objection

<Wilco> yes to existing

<Rachael> Who would object to existing language?

who would object to existing language?

RM: who would object to existing language?

<alastairc> Existing: Spacing: The target does not overlap any other target and has a target offset of at least 24 CSS pixels to every adjacent target;

<mbgower> I'm less happy with it, but I support it

<dan_bjorge> I think the existing language is much worse than the new proposal, but I don't think I'd formally object to it

<Detlev> not ideal , but ok

<alastairc> Prefer the revised

<bruce_bailey> +1 to dan's comment

<Rachael> draft RESOLUTION: Change the spacing exception language to proposed revision with an at risk option to fall back to existing (current CR) language

<alastairc> +1

<mbgower> +1

<dan_bjorge> +1

<Rachael> +1

<Ben_Tillyer> +1

<ShawnT> +1

<Jay_Mullen> +1

<GN015> +1

laura: +1

<Makoto> +1

<bruce_bailey> +1 but can fall back use "touch" instead of "overlap" ?

<Wilco> Abstain, not enough time to review

<kirkwood> +1

<Detlev> +1

<bruce_bailey> +1

<alastairc> I don't think 'touch' is as good as the current, with some adjustment to the understanding doc

<kirkwood> +1 to Bruce to not having “overlap”

wilco: how many people have seen this version before this call?

<AWK> +1

ac: it was in the survey but is an update.

wilco: not enough time to review properly.

<bruce_bailey> i had not seen GoogleDoc before today, but it is very minor edit to recent proposals

rm: not sure extending more time is an option.

mg: spacing wording has been in place for 3 weeks.

wilco: why a last minute change?

<bruce_bailey> i think this is PR: https://github.com/w3c/wcag/pull/3089

rm: hard to see that this is a big change to our process.

wilco: Seems like a big change to me. I'm not sure.

<bruce_bailey> that is PR link from survey

<mbgower> This was the wording of the PR that was surveyed <li><strong>Spacing:</strong> Targets are spaced such that if 24 CSS pixel diameter circles are centered on each target, none of the circles intersect another circle or target.</li>

wilco: want to review further.

<bruce_bailey> https://www.w3.org/2002/09/wbs/35422/wcag22-misc5/results#xq24

mg: I want all the scrutiny we ca get. PR put in place weeks ago.
... been 3 public discussions on it.

RESOLUTION: Change the spacing exception language to proposed revision with an at risk option to fall back to existing (current CR) language

RESOLUTION: Change the spacing exception language to proposed revision with an at risk option to fall back to existing (current CR) language, note that an objection raised about needing more time for review

<bruce_bailey> In PR, i find JAWS Test has illustration similar the concern I expressed in survey

<bruce_bailey> https://github.com/w3c/wcag/pull/3089#issuecomment-1460174001

2.5.8 target size should not have a "lists" exception #3051

ac: discussion early in he new year on 2.5.8 target size should not have a "lists" exception #3051
... thing we can make the small editorial change.
... trying to get at reflowable text so used the concept of lists for coorilation.

rm: reads survey comments

wilco: see how it makes testing slightly easier. Makes me sad that we have to make this exception.

<Rachael> strawpoll: 1) Remove the exception 2) Keep the exception with current wording 3) Keep the exception with enumerated 4) Something else

<Ben_Tillyer> 3

<alastairc> 3,

<Detlev> 3

<Wilco> 1, 3

<GN015> 1, can live with 3

<dan_bjorge> 3 = 1 > rest

<bruce_bailey> 3 2 1

<ShawnT> 3

laura: 3

<AWK> 3

<mbgower> 3

<Makoto> 3

<dan_bjorge> equally happy with 3 and 1, happier with either of those than any of the rest

<Francis_Storr> 3

<GreggVan> 2 unless someone can tell me the difference between numbered and enumerated (which is not plain language)

<kirkwood> 3

<Rachael> 1 or 3

<dan_bjorge> a) numbered might not be interpreted to include letters, b) we probably mean it to

<Detlev> a, b, c are an enumeratiion

<Detlev> but not numbers

<bruce_bailey> enumerated covers a b c d , i ii iii

<kirkwood> plain language: should be numbered

<Zakim> alastairc, you wanted to discuss gregg

gregg: what is the difference between numbered and enumerated? not plain language.

ac: enumerated can be letters too.

<mbgower> https://github.com/w3c/wcag/pull/3084

<kirkwood> ordered

<bruce_bailey> okay with ordered

<GreggVan> are not numbered/lettered

<Wilco> ordered makes this much worse

rm: is there a plain language alternative?

<GreggVan> numbered/lettered

<Detlev> sounds very much h like <ol> though+

ac: avoided ordered and unordered as html centric.

<GN015> ordered might be understood as in some order, like in alphabetical order

<alastairc> Consider the full text: Inline: The target is in a sentence, or is in a bulleted or enumerated list, or its size is otherwise constrained by the line-height of non-target text;

<kirkwood> “bulleted numbered or lettered” actually works better and is clearer

gregg: bulleted list is not a ordered list.

<kirkwood> +1 to Gregg

<alastairc> The target is in a sentence, or is in a bulleted, numbered or lettered list, or its size is otherwise constrained by the line-height of non-target text;

gregg: not sure numbered will make a difference.

<mbgower> "The word "enumerated" here refers to list items prefaced by one or more characters (whether numbers or letters) representing an ordered list."

<alastairc> The commas are getting really odd...

mg: reads PR

<bruce_bailey> cannot not just say "lists" because that implies menus using lists (CSS/HTML) are always okay

<bruce_bailey> we want exception only for lists that *look* like lists

<GN015> coming from the German term, translation directly brings me to "enumerated", so I'd consider it as the common term. Isn't it?

<Rachael> strawpoll: 1) bulleted and enumerated. b) bulleted, numbered, or lettered lists

mg: only talking about list with a symbol and those without.

<GreggVan> then bulleted, numbered or lettered sound clear

<kirkwood> and is also standard publishing parlance

wiclo: wondering what counts as a bulleted list.

<kirkwood> accordain lists? argh ;)

<GreggVan> icons are considered bulletsq+ to say

ac: went though examples prreviously. most menus don't have bullets or numbers next ot them.
... (shows examples)

<bruce_bailey> Noting that Trusted Tester has been using concepts of "visually apparent lists" and "visually apparent headings" without much difficulty

<Zakim> Rachael, you wanted to discuss scribe change

<bruce_bailey> https://section508coordinators.github.io/TrustedTester/structure.html

<bruce_bailey> scribe+

<Zakim> GreggVan, you wanted to say icons are considered bullets when used to indicate different items

<bruce_bailey> Gregg: Looks at Bruces example from trusted tester, trying to think if we have enough kinds of lists

<bruce_bailey> ... do icons count as lists when they are used to mark new items but maybe not semantically a list ?

<Zakim> mbgower, you wanted to say the challenge is when should a link be considered as a target that needs to meet size

<bruce_bailey> ... especially comes up with long paragraphs but topic start with distinct character

<bruce_bailey> Mike Gower: Where we started with this is just a single word or two used as hyper text link. That seems like a very reasonable exception because it so common.

<bruce_bailey> ... The problem arises that link list are very common paradigm for menus, side bars, etc.

<bruce_bailey> ... Horizontal menus and left-side navigation is somethat page authors have control over and should be expected to make 24 px high.

<Zakim> alastairc, you wanted to say that most things are covered by the last part of the bullet, but this made it clearer in working that out.

<bruce_bailey> ... We ran into difficulty trying to define "body text" where we believe hypertext links should be an exception.

<bruce_bailey> alastairc: The proposed phrasing makes testing easier

<bruce_bailey> ... is not changing the earlier intent.

s/coorilation /correlation /

<dan_bjorge> yes

<bruce_bailey> Dan Bjorge: I thought I was against this because it was expanding exception, but then I was okay as discussion progress , but with the example today of folder icons makes me think we should drop exception.

<mbgower> That's an authoring tool problem, Gregg. The author has still chosen the platform and the template. They must have some responsibility for that.

<bruce_bailey> GreggV: I think we need to keep exception for not under control of author because common authoring tools like WordPress cannot address

<mbgower> caveat emptor

<bruce_bailey> ... Are we saying authors can only meet this by coding in CSS and HTML?

<bruce_bailey> ... Exception for browser / user agent is different than an exception for authoring tool versus layperson author.

<bruce_bailey> ... I think we are geeking out here.

<bruce_bailey> Wilco: My clear impression is that this exception is too much of a loophole...

<Zakim> alastairc, you wanted to say that in wordpress land, the responsibility is on the template authors, so this is a tangent.

<bruce_bailey> ... We are trading one difficulty / complexity for a different one.

<Rachael> draft strawpoll: 1) The target is in a sentence or its size is otherwise constrained by the line-height of non-target text; 2) The target is in a sentence; or is in a bulleted, lettered or numbered list; or its size is otherwise constrained by the line-height of non-target text; 3) something else;

<bruce_bailey> alastairc: To GreggV concern, this ends up being a requirement for the developer of the template and not a layperson user of the template. So I think we hit the right balance here.

<bruce_bailey> ... To Wilco, we have been working on this and have balance for testability and the things under the control of a typical author.

<Rachael> strawpoll: 1) The target is in a sentence or its size is otherwise constrained by the line-height of non-target text; 2) The target is in a sentence; or is in a bulleted, lettered or numbered list; or its size is otherwise constrained by the line-height of non-target text; 3) something else;

<Zakim> GreggVan, you wanted to say -- I still question why it is illegal to make text in one location of a page the same size as we allow it in another part of the page. Either the

<alastairc> 2, can live with 1

<bruce_bailey> Rachael: Runing out of time, so trying a straw poll. [no objections to moving to poll]

<mbgower> 2,1 fine with either. Think the list langauge is going to be easier to understand

<Wilco> 1

<dan_bjorge> 1, can live with 2

<Rachael> 1 but can live with 2

<ShawnT> 1

<AWK> 2, 1

<bruce_bailey> GreggV: I am still concerned that we are saying has to be this size on one part of the page but some list on the left is not acceptable.

<bruce_bailey> ... To say page is not accessible on left but is okay in middle is pedantic.

1, can live with 2

<GN015> 1

<bruce_bailey> Detlev: I agree that the GitHub is exactly on point. Elements which are not part of the author controlled content should not be included...

<Zakim> mbgower, you wanted to say we attempted to just have an exception for text links and that was not supported, so we have to provide some guidance to authors about when to fail text

<bruce_bailey> ... but I would prefer to keep exception for lists.

<bruce_bailey> mbgower: There was a proposal to exempt text but after much conversation there was consensus about that approach being too much of a loophole.

<GreggVan> 2

<kirkwood> 2,1

<Makoto> 2 1

<bruce_bailey> Rachael: We have slightly more agreement for dropping lists as exception entirely.

<GreggVan> 2 or 3 (any text link)

<Detlev> 2 (hopefully with clarification of icons fronting lists) otherwise I fear I will fail Hughe swathes of content out there immediately

<Rachael> draft RESOLUTION: Use "The target is in a sentence; or is in a bulleted, lettered or numbered list; or its size is otherwise constrained by the line-height of non-target text; "

<Ben_Tillyer> +1

<bruce_bailey> alastairc: We have tried other phrasing to identify navigation elements but it was even more tortured phrasing

<mbgower> +1 fine

<Wilco> -0.9 + I'll be sad

<kirkwood> +1

<bruce_bailey> Asking for concerns?

<GreggVan> -1 Have not heard the logic yet for having any restriction based on line height

<dan_bjorge> To be clear, the restriction based on line height already exists in the current version

<bruce_bailey> Rachael: two objections to moving forward with present phrasing

<Zakim> mbgower, you wanted to say I can answer gregg

<bruce_bailey> GreggVan: What is the response to observation that size of something in middle of screen is a fail but it is okay when same content is on left sidebar ?

<bruce_bailey> mbgower: One approach is that lineheight must always be 24 px high.

<bruce_bailey> ... that is much much too restrictive, it is not a real world problem.

<bruce_bailey> ... But we also know tightly grouped link lists are problematic...

<bruce_bailey> ... So where to draw line so we cover tight spacing many places but not impacting body text.

<alastairc> because it's not feasible

<mbgower> because body links clearly are a different use case from primary page navigation

<bruce_bailey> GreggVan: That explains how we got here -- but we still do not have a pithy answer for why exact same thing in middle of screen is okay but not when in footer.

<Rachael> draft RESOLUTION: Use "The target is in a sentence or its size is otherwise constrained by the line-height of non-target text; "

<bruce_bailey> alastairc: It is not feasible to require 24 px lineheight everywhere.

<Wilco> +1

<mbgower> +1 fine, but prefer the other

<dan_bjorge> +1

<bruce_bailey> ... so do we require something or nothing at all ?

<alastairc> -0.5, not objection, just think that it's not as useful.

<bruce_bailey> GreggVan: Agree not feasible for body text. But how cover two legs of stool but not a third?

<mbgower> This is rehashing a LOT of discussions

<alastairc> gregg - it is more like providing a room full of stools, and some of them have 4 legs, some of them have 34

<bruce_bailey> ... If person has trouble with tight text, they cannot use body text. If side bar a problem, then body text a problem.

<Rachael> draft strawpoll: 1) Remove SC 2) Keep SC and continue wording 3) Something else

<bruce_bailey> Detlev: I think it is reasonable to make distinction between body text which is everywhere and navigation and menus which we know can often be a barrier.

<bruce_bailey> Rachael: I will try another straw poll. Gregg are you saying we should drop SC?

<Rachael> strawpoll: 1) Remove inline from SC 2) Keep inline exception and continue wording discussion 3) Something else

<Detlev> @ Gregg I woud dispute that... needs research

<alastairc> We already have the AAA version

<bruce_bailey> GreggVan: I am saying that links in running text are more important than links in menus. I would like to have at AAA.

<Wilco> 2

<alastairc> 2

<ShawnT> 2

<mbgower> 2

<dan_bjorge> 2

<Ben_Tillyer> 2

<Rachael> 2

<bruce_bailey> Rachael: please vote

<Detlev> 2

<kirkwood> 2

<Makoto> 2

<GreggVan> 3 keeping one at AAA removed AA

<GN015> 2

2 don't let perfect be the enemy of good.

<alastairc> Gregg we have the AAA version: https://www.w3.org/TR/WCAG22/#target-size-enhanced

<bruce_bailey> Rachael: I am seeing consenus for 2 and GreggV I will provide some backgroud

<bruce_bailey> Rachael: I see fewer objections to (2) than (1) so that is consensus position

<GreggVan> if 3 is off the list 2 is next choice

<mbgower> scribe: mbgower

<Wilco> scribe+

<Zakim> mbgower, you wanted to give a bit of background

<alastairc> scribe- mbgower

<Wilco> Mike: The current AAA has slightly different wording than our AA

<Wilco> ... The problem is when something isn't in a clear sentence or paragraph. When is it a text link? That's the problem.

<Rachael> draft RESOLUTION: Use "The target is in a sentence or its size is otherwise constrained by the line-height of non-target text; "

<Wilco> Rachael: Not everyone voted. If you object, let us know. We need to know.

<Wilco> +1

<alastairc> -0.5, but I think we should do it and move on (assuming there are +1s_

<dan_bjorge> +1

<Rachael> +1

+1 fine but will need more explanation in Understanding document that we're talking about lists (and how to distinguish them)

<ShawnT> +1

<GN015> +1

<kirkwood> +1

<Detlev> 0 I think it will get a lot of pushback - exempting list in body text would mitigate that

<Makoto> +1, and +1 to mbgower

<GreggVan> -1 lists in body text are need to be excepted

<alastairc> We'll have more explaining to do in the understanding doc.

<Wilco> Alastair: I don't think it changes the scope of the exception much

<Wilco> ... The line-height fallback still applies

<Wilco> ... What we're talking about is making it easier to understand that most links will be accepted

<Rachael> "The target is in a sentence or paragraph, or its size is otherwise constrained by the line-height of non-target text; "

doesn't solve the problem space

<Wilco> Rachael: Chair hat off; Most text links we're concerned with are within a sentence or are fully a sentence, even if broken out into a list

<Zakim> GreggVan, you wanted to say - no link is constrained by non-body text. Any link can programmed to be taller -- and templates or CSS could do that as easily as lists on the

<Wilco> Gregg: No links are constrained by text. It's all in CSS. You can say it's an authoring tool problem.

<Wilco> ... I'm worried we're making arbitrary lines. We can't do it everywhere so we do it in a few places?

<Detlev> @Gregg people will balk at designs where the line height changes because the css adds padding to links!

<Zakim> mbgower, you wanted to say it doesn't solve the probelm space

<Wilco> ... If you can't operate half the page, why do we worry about the other half.

<Wilco> Mike: That's not under discussion. We do have the inline exception, we just voted on that.

<Wilco> ... Restricting to sentences and paragraphs, a bulleted list is not part of a paragraph. In HTML, the UL is outside the P.

<Rachael> Thank you for that clarification

<Wilco> ... Depending on how you punctuate, it could be considered outside the paragraph as well.

<Wilco> ... You get into a situation where if someone put a comma on the end its in scope, but if it doesn't it's out

<Wilco> Alastair: I'm inclined to take it out and move on.

<Wilco> Rachael: We have objections either way, but fewer to taking it out

<Zakim> GreggVan, you wanted to say if we just make it "block of text" and leave out body -- it solves my problem as well

<Zakim> alastairc, you wanted to say we tried that

<Wilco> Gregg: If we just say "block of text" that solves my problem, and it solves the question of in or out a paragraph.

<Wilco> Alastair: We tried that, it doesn't help.

RESOLUTION: Use "The target is in a sentence or its size is otherwise constrained by the line-height of non-target text; "

<Wilco> Rachael: We'll address in detail in the understanding document how to do this.

WCAG 2.2 Focus appearance See https://lists.w3.org/Archives/Public/w3c-wai-gl/2023JanMar/0309.html

<Wilco> Alastair: Last week we agreed to move to AAA.

<Wilco> ... The complexity has weight, but we want guidance.

<Wilco> ... We agreed to AAA as is, but typically we have stronger requirements at AAA.

<Wilco> ... Suggestion 1 was to remove the first bullet, make it shorter

<Wilco> ... Suggestion 2 was to increase the minimum area

<Wilco> ... Another was to have only one area requirement.

the last bullet was about contrast

<Wilco> ... If we did that, then we could remove the 2px minimum, as it is likely to have that anyway.

<Rachael> draft strawpoll: Which of the following do you support (Choose all that apply): 1) Removing first set of bullets, 2) Increasing the size to 2 CSS pixels, 3) Use only one area requirements and "no thinner than 2 CSS pixels"

<Zakim> mbgower, you wanted to say the last bullet is about contast

<Wilco> Mike: The third item is not just about 2px, it's a contrast requirement. We're stripping out the exception

They need to have an area

<alastairc> 1, 2, 3 (agree with all)

<Rachael> strawpoll: Which of the following do you support (Choose all that apply): 1) Removing first set of bullets, 2) Increasing the size to 2 CSS pixels, 3) Use only one area requirements and "no thinner than 2 CSS pixels" and the contrast requirement with adjacent non-focus indicator colors

<Ben_Tillyer> 1,2,3

<GN015> 1

All of the above, in reverse order of preference

<Detlev> I don't know

<Rachael> 3 or 1 & 2

<dan_bjorge> 1, 2, 3 (but could also live with as-is)

<Wilco> 1, 2, I don't understand 3 fully yet

<Wilco> Alastair: Side or bottom indicators would struggle to pass if we go to one area measure

<Wilco> ... If we do keep the shorter-size metric, it means we're not actually increasing the size

<ShawnT> 1, 2, 3

<Wilco> Rachael: I would prefer clear understandable instead of keeping the complexity

<Wilco> Alastair: The other type of indicator that would struggle could be an icon that expands. Those would struggle to pass because of the adjacent contrast requirement

<Laura> 3, 1, 2

<Wilco> Dan: Because 3 keeps non-focus indicator clause, you can still pass with the expanding control. It just increases how much to expand it

<Wilco> GN: The motivation for these exceptions are common. They were there for flexibility and creativity, I would like to keep that.

<Wilco> ... The first bullet was only there for simpler wording.

we raised the bar; it's AAA

<Wilco> ... The Google research was only restricted to one control and style.

<Wilco> ... I feel the conclusion to dropping other variations goes too far

<Zakim> alastairc, you wanted to talk to AAA usage

<Rachael> draft RESOLUTION: Remove first set of bullets and Increase the size to 2 CSS pixels

<Wilco> Alastair: This comes down to what we put at AAA.

<Wilco> ... Our previous AAA version had doubled the requirement. It's generally where we put things we know aren't always feasible.

<Wilco> ... It's more aspirational.

<alastairc> -1, as if we still have the 4x shortest edge it doesn't matter

<GN015> -1 it restricts to solid 2px wide focus indicatr, which is not meeting needs on complex screens

<Wilco> Alastair: It's either only the first bullet, or the other three

<alastairc> Either just 1, or 1-4

<GN015> furthermore, AAA are liely to be complied together, and a 2px solid focus ona high contrast screen might not be easily perceivable, while a different pattern migt be spotted easily

<Rachael> strawpoll: 1) Remove the 1st set of bullets or 2) Increase area requirement, use only one area requirement and remove no thinner than

<ShawnT> 2

<alastairc> 2, can live with 1

<GN015> 1

<Wilco> slight pref for 2

<Detlev> Sorry, can't wrap my head around implications, - abstain

1, fine. 2 is better, but I think I heard some people in between those

<OliK> 1

<dan_bjorge> slight pref for 2, but 1 is fine

<Laura> 2, can live with 1

<Rachael> 2, can live with 1

<Wilco> +1 Detlev. Need to see option 2

<Makoto> 2, 1

<kirkwood> 2

<alastairc> https://docs.google.com/document/d/1RGQBMvDAhEylflppCAKrF6IW8zjHjqH6DNqXKKzpHyI/edit#

<Wilco> Rachael: We'll e-mail out the options, please respond to the list soon

<Wilco> ... We'll send out a draft resolution poll shortly

- DRAFT -

AGWG Teleconference

28 Mar 2023

Attendees

Contents

New members and topics

Announcements

WCAG 2.2 Target Size, Q1-2 (not new questions) https://www.w3.org/2002/09/wbs/35422/wcag22-misc5/results

2.5.8 Target Size "overlapping any other target" does not work #3050

2.5.8 target size should not have a "lists" exception #3051

WCAG 2.2 Focus appearance See https://lists.w3.org/Archives/Public/w3c-wai-gl/2023JanMar/0309.html

Summary of Action Items

Summary of Resolutions

Scribe.perl diagnostic output