<alastairc> Conformance challenges re-review reminder https://w3c.github.io/wcag/conformance-challenges/

<PascalWentz> Webex active? Don't see any participants

<CharlesHall_> regrets for 2nd half

<Jennie_> scribe: Jennie

<alastairc> https://www.w3.org/WAI/GL/wiki/Scribe_List

<Jennie_> Alastair: Still looking for other scribes.

<Jennie_> ...Please check the scribe list and add yourself on.

Use of Zoom for future meetings

<Jennie_> Alastair: We have been using Zoom for some meetings.

<PeterKorn> Alastair; can we give just a brief heads up about the status of the Challenges doc?

<Chuck> +1 using zoom

<Jennie_> Alastair: Does anyone have any problems with Zoom?

<david-macdonald> I love Zoom much better

<PeterKorn> +1 to Zoom

<kirkwood> +1 to zoom

<OliKei> +1 to zoom

<Jennie_> Alastair: If you prefer to send information to the chairs privately, please send it in an email.

Conformance challenges re-review reminder https://w3c.github.io/wcag/conformance-challenges/

<CharlesHall_> +1 to zoom (been having a webex issue of forced app download for each meeting)

<sajkaj> +1 to Zoom

<Jennie_> Alastair: Here's a reminder on the Conformance Challenges document.

<sajkaj> https://w3c.github.io/wcag/conformance-challenges/

<david-macdonald> braking up for me

<Detlev> can't hear you well

<Chuck> me too

<Jennie_> Peter: A few weeks ago, (hard to understand)

<Chuck> It's on your end Peter

<kirkwood> audio issues

<Jennie_> Alastair: Keep talking for a moment, but please repeat.

<kirkwood> better

<Chuck> perfect!

<Chuck> now much less than perfect.

<Jennie_> Peter: We have made quite a lot of changes since December.

<kirkwood> uh oh

<alastairc> Quite a lot of changes, few weeks spoke briefly...

<Jennie_> * Peter is still breaking up

<kirkwood> can’t hear

<Jennie_> Janina: I suggest you call back in

<Jennie_> Janina: So there are structural changes.

<Jennie_> ...A lot of the details were moved into appendices.

<PeterKorn> Coming in via PSTN

<Jennie_> ...More recently we have gotten substantive suggestions from Michael - those are mostly incorporated

<Jennie_> Janina: Judy made suggestions now incorporated.

<Jennie_> ...The editor's draft now has discussion of mitigation.

<Jennie_> * We cannot hear Janina

<Chuck> lost Janina

<Jennie_> * We can now hear Peter

<Jennie_> Peter: In the last couple of weeks we put out a request for any other concerns.

<Jennie_> * Please mute the background noise - makes it hard to scribe

<Jennie_> Peter: Michael Cooper did a fantastic job of a lot of suggestions.

<Jennie_> ...We pulled in those changes, added a new section on mitigation approaches to try to address the challenges raised.

<Jennie_> ...We also made clear in the first paragraph of problem statements that WCAG conformance statements - what we are trying to do is highlight challenges

<Jennie_> ...so that moving forward we can deal with them

<Jennie_> ...The document has a new tone.

<Jennie_> ...We would very much appreciate those that had concerns, or those that have not yet reviewed, to review, file issues, send emails on the list...

<Jennie_> ...Our hope is next week we would have 2nd survey to see if it now is a good reflection and ready

<Jennie_> Alastair: If everyone could mute when not talking, that would really help

<Jennie_> ...Yes, we will be having a survey soon, so start reviewing the document.

<Jennie_> ...Any questions or comments on that document or the process?

WCAG 2.2 Touch target spacing: https://www.w3.org/2002/09/wbs/35422/target-spacing/results

<Jennie_> Alastair: We did discuss this last week, and got quite far.

<Jennie_> ...The mobile task force met about it, and suggested some more changes which is why it is back up for review.

<alastairc> "For adjacent targets, the minimum height and width, where the height and width include the target size plus spacing between targets, is 44 CSS pixels each except when"

<Jennie_> ...The changes look like it is for the introductory test

<Jennie_> * text, not test

<Jennie_> Alastair: That is the change that stood out to me. Anyone from the mobile task force that can comment?

<Jennie_> ...If not, we can go through the comments.

<Jennie_> ...Working up from the bottom

<Jennie_> ...Andrew commented: equivalent links on the same page - resolved?

<Jennie_> Alastair: I'm not sure. It is not an explicit exception

<Jennie_> ...for alternative conforming versions

<Jennie_> Andrew: There was some question as to whether it is an alternate conforming version

<Jennie_> ...like one video has captions, the other doesn't - you still pass.

<Jennie_> ...Should we clarify in the understanding document?

<Jennie_> Alastair: OK.

<Jennie_> Andrew: in regards to #3, just leave that

<Jennie_> Alastair: OK the 2nd one was about block of text. we have a definition of block of text

<Jennie_> Andrew: One or more sentences

<Jennie_> ...1 or the other of those 2 things would accomplish the same thing

<Jennie_> Andrew: I do think that it has been a confusing definition for people at different times.

<Jennie_> Alastair: OK

<Jennie_> Andrew: Blocks of text is more than one sentence of text

<Jennie_> ...You would need to modify it to just keep the sentence part

<Jennie_> Alastair: OK we could delete that

<Jennie_> Andrew: You can have a link that is more than a few words, but if it is just whether that link forms a sentence or not is a strange distinction to make

<Jennie_> ...in terms of whether it meets target sizing

<Fazio> +1

<Jennie_> Alastair: You can have a sentence that is a link

<Jennie_> Andrew: you could. Also, I don't know whether there is any localization issues depending on grammar structures for some languages

<Jennie_> Alastair: Yes.

<Jennie_> Andrew: We could get feedback on that once in the draft from the internationalization group

<Detlev> +present

<Jennie_> Jake: Did you delete block of text because it is also in 2.5.5

<Jennie_> ...It is just a copy of 2.5.5 and we had discussed that for 2.5.5 more than once

<Jennie_> Alastair: It is already in 2.1...

<Jennie_> Jake: Yes, we discussed it, this specific sentence. Block of text was already present in 2.0 although it is not linked, then we added that sentence because it was missing in the exception.

<Jennie_> Andrew: that's fine.

<Jennie_> Alastair: OK

<david-macdonald> link to doc of this?

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

<Jennie_> Andrew: A sentence is enough, but a group of words does meet that

<Jennie_> ...Feels a little inconsistent

<Jennie_> Alastair: OK.

<bruce_bailey> agree that we should try to iron this out

<Jennie_> Andrew: Now is the time to relitigate. Moving to AA it is much more likely to be entered into policy

<kirkwood> +1

<Jennie_> ...Things in AAA don't go through the same level of scrutiny because of that.

<Jennie_> Alastair: I think the arguments from last time around icons in a sentence, or having a word in one sentence

<Jennie_> ...We started target size at a higher level, but the internationalization aspects might need some examination

<Jennie_> ...If blocks of text is multiple sentences.

<Jennie_> ...Do we have any improvement on that?

<Fazio> 1 or more lines of text perhaps?

<Jennie_> Alastair: OK. I will propose an editor's note asking about issues with internationalization

<Jennie_> ...It is tricky with windows that resize. When does 1 line of text become less than a sentence?

<Fazio> a line can also be vertical or horizontal

<Detlev> "part of inline content"?

<Fazio> so helps with internatoonal

<Jennie_> Alastair: Part of inline content is technology specific.

<Detlev> ok..

<Jennie_> ...Do you mean CSS? It would be good to have a non CSS way to say that

<Fazio> lines

<Jennie_> Alastair: If anyone can think of an improvement?

<Jennie_> ...Wilco had some points

<Jennie_> ...He is asking what is a target? Which when you are not familiar with this criteria...

<Jennie_> ...It does almost feel like there should be a definition of a target.

<Jennie_> Andrew: There is

<Fazio> \there's a scientific one for attention studies

<AWK> target - region of the display that will accept a pointer action, such as the interactive area of a user interface component

<Jennie_> ...not adjacent target, but target

<Fazio> in neuropsyche

<Jennie_> Alastair: Is that already in WCAG?

<Fazio> they use computer tests too

<Jennie_> Alastair: OK.

<Jennie_> ...we do have a definition of target

<Jennie_> Andrew: We probably do not need to define adjacent.

<Jennie_> Alastair: Although Wilco goes on to say he would rather have a definition centered on the distance

<Jennie_> ...In previous iterations I would have agreed, however, if the 1st part is based on a minimum height and width, including spacing

<Chuck> +1 to Alastair

<Jennie_> ...I don't think defining the center of target is helpful. The math could get strange.

<Jennie_> ...and difficult to calculate.

<Jennie_> ...The current calculation is the easiest I have seen so far.

<GN015> +1 to Alastair

<Jennie_> ...I did wonder if there is an easier way to say the top part.

<alastairc> AC: "Adjacent targets for pointer inputs have minimum height and minimum width of at least 44 CSS pixels including spacing except when"

<Jennie_> ...(without chair had on)

<Jennie_> ...it seemed less wordy

<alastairc> Current wording is: For adjacent targets, the minimum height and width, where the height and width include the target size plus spacing between targets, is 44 CSS pixels each except when

<Jennie_> Alastair: for those in the mobile task force - do you know why they are specifically called out?

<Jennie_> Detlev: I wasn't on the last call

<Jennie_> Alastair: It seems to be very separate: min width and height...

<Jennie_> Jake: Yes, I know that from our last call adjacent was not present so we ended up with a success criteria for every target

<Jennie_> ...The user need is only applicable when they are adjacent to each other.

<Jennie_> ...In a rewrite adjacent was put back in.

<Jennie_> ...Then we have to make sure it is for every side - the width and the height.

<Jennie_> ...It is about the width and the height, and the pixels, and about being adjacent. If you have another way to rewrite it, that would be great.

<Zakim> Chuck, you wanted to say Adjacent targets for pointer inputs have minimum height and minimum width including spacing of at least 44 CSS pixels except when:...

<Jennie_> Alastair: I think adjacent made it clearer

<Jennie_> Chuck: I'm modifying Alastair's suggestion because yours with "except when" - that is based only on including spacing.

<Jennie_> ...I don't think that is the intent, so the exception applies to the totality

<Jennie_> Alastair: I think that helps

<Jennie_> ...I don't think we need the "for pointer inputs" part

<alastairc> "Adjacent targets have minimum height and minimum width including spacing of at least 44 CSS pixels except when:"

<Jennie_> Alastair: Any complaints about that formulation?

<Jennie_> Andrew: I find it hard to parse.

<Jennie_> Gundala: I am afraid the each is missing.

<Jennie_> Alastair: You mean each of the height?

<Jennie_> Gundula: we had "each"

<JF> + 1 to Gundala... think vertically stacked links

<Jennie_> Jake: that is really good that she said that, because you could have 22 x 22 and that would pass

<Jennie_> ...44 for width and 44 for height. We specifically added each to make sure

<alastairc> "Adjacent targets have minimum height and minimum width including spacing of at least 44 CSS pixels each, except when"

<Jennie_> Alastair: OK

<Jennie_> John F: The spacing has to be on all 4 sides.

<Jennie_> ...Even though some links might look polygon, we are dealing with essentially the box level.

<Jennie_> ...the spacing has to be from all 4 sides of the link.

<Jennie_> Alastair: If you scroll down to the picture, which has 2 thin links

<Jennie_> ...the distance from the 1st to the 2nd passes

<Jennie_> ...You could have one 44 pixels tall, and that could also pass

<Jennie_> ...you don't have to have 44 in every direction, it needs to include spacing

<Jennie_> ...I think what Jake is saying is different

<Jennie_> ...You need to apply to both height and width

<Jennie_> John F: is it "either"

<Jennie_> Alastair: We are trying to make it both

<Jennie_> Detlev: I think it would get messy if we try to specify where the spacing has to be in relation to the target

<kirkwood> wouldn’t measurement from center resolve all of this?

<Jennie_> ...if considering interactive area

<Jennie_> Detlev: You can imagine a case where 1 item has its visual marker in the top right corner, the other in the top left corner

<Jennie_> ...If we wanted to rule that out it would be much to descriptive, and I would shy away from that.

<Jennie_> Alastair: Yes, I think so.

<CharlesHall_> the distance is between the adjacent sides, correct?

<Jennie_> Alastair: we are aiming for both height and width

<alastairc> Adjacent targets have minimum height and minimum width, including spacing, of at least 44 CSS pixels, except when

<Jennie_> ...Because that version said minimum height and minimum width, maybe "including spacing" needs to be in commas

<Jennie_> Alastair: Does that work any better?

<Fazio> or period then this includes spacing

<Jennie_> John F: the only question I would ask is in the context of text links that will be dependent on the size of the text

<Jennie_> Alastair: Which is why we have an exception for inline links

<Jennie_> ...Does anyone see issues with that?

<Jennie_> Andrew: So what is the formula now?

<Jennie_> Alastair: It is 6 lines back

<Jennie_> Andrew: It is confusing because it says the target has the minimum height including spacing of CSS pixels, but target is the area

<kirkwood> how does the targer include the spacing?

<Jennie_> ...We are using target in more than one way

<bruce_bailey> Suggestion: parenthesis instead of one pair of commas?

<Jennie_> Andrew: Target is also the button - the button has a target

<Jennie_> ...The target is the thing

<bruce_bailey> [11:42Adjacent targets have minimum height and minimum width (including spacing) of at least 44 CSS pixels, except when

<david-macdonald> Adjacent targets including spacing, have minimum height and minimum width, of at least 44 CSS pixels, except when

<kirkwood> target plus the spacing ?

<alastairc> Adjacent targets, including spacing, have a minimum height and minimum widthof at least 44 CSS pixels except when:

<bruce_bailey> [11:44]Adjacent targets (inclusive of spacing) have a minimum height and minimum widthof at least 44 CSS pixels except when:

<Jennie_> John F: The question becomes does the spacing between the targets get shared by both targets?

<bruce_bailey> Adjacent targets (inclusive of spacing) have a minimum height and minimum width of at least 44 CSS pixels except when:

<Jennie_> ...20 CSS pixel of space between - they pass?

<Detlev> corect

<AWK> Targets, combined with spacing between adjacent targets, have a minimum height and minimum widthof at least 44 CSS pixels except when:

<Jennie_> John F: 24 - 20 - 24

<bruce_bailey> 44 pixels from center of one target to next, except when

<Jennie_> Andrew: if you look in the understanding document, there is a diagram that shows that

<Jennie_> Alastair: I think that applies to the version we were just talking about

<Jennie_> ...You could say from one target to the next

<JF> [Button @24px] 20px [button @24px]

<Jennie_> ...Imagine you have a 200 pixel wide target next to 20

<kirkwood> agree with the measurement from the center.

<Jennie_> Andrew: I put my modified version up there which does not have "adjacent"

<Jennie_> ...at the beginning

<Jennie_> ...It is starting by talking about the evaluative unit of the moment - a target. The one you are evaluating first.

<Jennie_> Jake: where can we see that one?

<Jennie_> Andrew: the last thing I posted

<Jennie_> Alastair: Looks good to me

<Chuck> The minimum distance between adjacent targets is at least 44 CSS pixels, except when

<Jennie_> David M: in general we try to stay away from brackets

<AWK> Targets, combined with spacing between adjacent targets, have a minimum height and minimum width of at least 44 CSS pixels except when:

<Jennie_> Chuck: I've really simplified it, maybe too much

<bruce_bailey> Targets, when combined with spacing between adjacent targets, have a minimum height and minimum widthof at least 44 CSS pixels, except when:

<Jennie_> Chuck: It doesn't refer to spacing, or vertical, I don't think it has to

<Jennie_> Chuck: Andrew's is fine too

<Jennie_> ...All of these seem to be over explaining

<Jennie_> Jake: If I read Andrew's correct it demands on every side

<Jennie_> Andrew: but if you are not adjacent to something. If you have a page with 1 control in the middle of the page then you are going to max out your spacing

<Jennie_> Chuck: that's true of all of our definitions

<Jennie_> Andrew: What if you have a webpage in the upper left corner there is a 10 pixel by 10 pixel button, and there are 100 pixels below and to the right before any other controls

<Jennie_> ...You would pass for the right and below, but you would fail because it doesn't have 44 pixels relative to the last and above?

<Detlev> queue

<Jennie_> Gundula: I want to reply to measuring the distance between targets

<Jennie_> ...this is understood as border of target to border of target. Size does matter.

<Jennie_> ...Concerning the current question - if we want to avoid it we should say so

<CharlesHall_> spacing between does not guarantee that spacing is part of the bounding (hit) area

<Jennie_> ...we could exclude the case by wording the success criteria accordingly.

<Jennie_> Chuck: What she said makes sense - my definition does not take into account the actual size of the target.

<Jennie_> ...between the outer edges of the target.

<Fazio> Are we taking into account the edge of screens?

<Fazio> +1

<Jennie_> ...I agree that if you are close to the edge of the border of the page that is not covered and we should explicitly call it out

<Jennie_> Alastair: You could have 200 pixel wide buttons right next to each other and fail even though they have plenty of space.

<CharlesHall_> the edge of the viewport in iOS has a 25px control to invoke browser history or tab bar

<Jennie_> ...So far Andrew's version is our best bet for that.

<Jennie_> David F: Are we taking into account the edge of the screens or just targets close together.

<Jennie_> ...When using a CC-TV, when zooming in on targets on a phone it would cut off the edge, and the user could not tap on it

<Jennie_> ...having enough space for the user to interact with it is what is important

<Jennie_> Alastair: That is what we discussed for 2.1

<Jennie_> ...This is another attempt to be less prescriptive - what we need is target size, but separation is also a factor

<Jennie_> ...In some context, if you are using a mouse, having something next to the edge of the screen is a good thing

<Jennie_> David F: One of the ways we got through it is we made sure all text related to the target was active

<Jennie_> ...not just the focus area

<Jennie_> Alastair: The one that comes to mind is the tiny little targets in the top of the screen in the top left, and looks tiny

<Jennie_> ...because there is nothing around it - it seems like there is a heuristic going on - if you tap anywhere in that area it seems to work

<alastairc> Current proposal: "Targets, combined with spacing between adjacent targets, have a minimum height and minimum width of at least 44 CSS pixels except when:"

<Jennie_> ...But if you have 2 of those links on top of each other, that is what the SC is trying to get at

<Jennie_> Brooks: I want to confirm the intent.

<Jennie_> ...It's intent is to prevent selecting a target you did not intent to select, is that correct?

<Jennie_> ...Activating a target you did not mean to

<Jennie_> ...Is this to prevent that?

<Jennie_> Alastair: Yes, or reduce that

<Jennie_> * new scribe soon?

<Jennie_> Alastair: Yes, this is intended to prevent that

<Jennie_> ...for target size that came out at AAA

<Jennie_> ...This is another attempt to account for spacing

<Jennie_> ...It should have a similar effect

<Jennie_> ...pushback most likely from toolbars

<Jennie_> Brooks: Just thinking of how to explain this to production teams

<alastairc> "can easily be activated without accidentally activating an adjacent target."

<Jennie_> ...Would anyone disagree it is both to make it easier for touch users to activate controls as well as prevent activating the wrong control?

<Jennie_> Alastair: Yes

<Fazio> It helps with some of our COGA needs too

<Detlev> I can scribe

<Detlev> Scribe: Detlev

<CharlesHall_> regrets, dropping off call

Alastair: Reading wording for target spacing

<PascalWentz> regrets, dropping off too

<Chuck> +1

Alastair: does it need changes?

<Fazio> can you share the doc link aagain

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

Jake: The same problem as before - if you have a target of 22x22 the min width and height is at least 44 (?)

<Fazio> thx

<alastairc> Targets, combined with spacing between adjacent targets, have a minimum height and minimum width of at least 44 CSS pixels each except when:

Alastair: we can repeat each for height and width to make it clearer

Jake: We discussed the problem of automated testing possibilities - what about clickable regions with targets inside? Then you have 2 touch targets
... it's valid to add buttons inside links so how do we handle it?

Alastair: The button would need a min height and with of at least 44x44 px - isn't tzhat a good thing?

Jake: if the card is clickable but the button of smaller size say 30 x 30 pixels - the two targets are not adjacent so the SC does nit seem to apply

Alastair: Inside is the ultimate case of adjacent

Jake: If you miss the button you click the link - it should be 44x44 but that is triple A

<Fazio> its inline with all our coga work

Alastair: In my reading the button is 'adjacent' in the sens of being inside

Chuck: agree - if the target is encosed the only way to meet this is min 44x44px - the current definition covers that

<Chuck> not indirect

Jake: So if covered that's fine

<Chuck> could be in the understanding doc.

<Fazio> +1 to detlev

<alastairc> Detlev: This special case, button inside, might need to be spelt out. would have thought adjacent = next to

<Jennie_> +1 to Detlev

Detlev: inside as extreme case of adjacent should be spelled out

Alastair: can do that

Francis: suggests editorial change, is to are

<AWK> Still wondering about the equivalent link exception that was removed from the current AAA SC.

<alastairc> A mechanism is available to change the size of all targets so that the width and height are eachis at least 44 CSS pixels

Alastair: Wants to tackle more of Wilco's comments
... Wilco suggests "height is at least" ... will get very wordy

<Fazio> I'm thinking of social media share buttons. Are we excepting those? Does it make sense not too?

Alastair: reason to put in min heigh tand min width is to ensure both are considered separately

<AWK> "at least" adds less than 2x "minimum" :)

Alastair: wordsmithing

<alastairc> "Targets, combined with spacing between adjacent targets, have a height and width of at least 44 CSS pixels each except when"

<AWK> Targets, combined with spacing between adjacent targets, each have a height and width of at least 44 CSS pixels except when

Alastair: thought minimum would help

<AWK> Targets, combined with spacing between adjacent targets, have a height and width that are each at least 44 CSS pixels except when

Brooks: Question to anticpate those I will be getting: Is spacing between targets going to support low vision users sufficiently?

<Fazio> that was what I was getting at earlier also

Alastair: Its quite flexible since it is not requiring a minimum size

Brooks: Scenario when zooming in, when allowing a 1 px wide button with sufficient space around it it would not help target users enough (possibly for touch but not for mouse)

Alastair: Requirement would then be similar to current triple A

Jake: rereading sentence ... feels not right does not feel as if it applies to all targets

<alastairc> Adjacent Targets, combined with spacing, each have a height and width of at least 44 CSS pixels except when:

Jake: it does not reflect the criterium

Alastair: You could change the wording but the meaning would be the same

Jake: It reads as if it is only for adjacent targets

Alastair: In terms of testing, is there an adjacent target? If not, it's not in scope

<Fazio> adjacent isn't needed I think is what he's saying

Alastair: jake's point: Specifiying targets as adjacent would make it clearer
... each should be put at the end to refer to width and height

Jake: 30px high and 100px wide would need no height of 40px

<alastairc> Adjacent Targets, combined with spacing, have a height and width of at least 44 CSS pixels each except when:

<Chuck> detlev: Brooks made a point that since this is not setting a minimum size it could be unhelpful to people if targets are small. Some would argue that usability would take care of this, but I find no harm in defining a minimum target.

<Chuck> detlev: If you went down to 22x22 as a minimum for example. Would that be too restrictive? I don't see a case for going below that. I would be conformable with that.

<Chuck> detlev: This would avoid meeting this sc and still having very tiny targets.

Cheers Chuck

<Fazio> good point detlev

Alastair: We went through those discussions, ended up defining the minimum of target plus spacing

<Chuck> detlev: Would avoid the cases where the target gets even smaller than that.

Alastair: would be better as an AA update for target size

Chuck: tripped up by "each" - could apply to target
... lead to misunderstandings

Alastair: "have a hight and width each of"?

<Zakim> AWK, you wanted to say 'speaking of late changes...'

<Rachael> perhaps both height and width

<Fazio> Trying to fit it all in one sentence seems to cause a lot of confusion. I feel like if it is broken up into a couple concise sentences it might be more comprehendable

AWK: Put comment in google doc offering a different construction

<alastairc> Any user interface components which contain a target and which have adjacent targets, one or more of the following must be true:

<alastairc> • The target must have a height and width that are each at least 44 CSS pixels.

<alastairc> • The target width and height, added to the spacing to each adjacent user interface component target, are each at least 44 CSS pixels.

AWK: reads alternative wording in Google docs comment

Alastair: is user interface component not the same as target?

AWK: Target area for UI component..

Alastair: Bullet points work

<Fazio> Target sounds more universal to me

AWK: Downside is that it gets longer

Gundula: Can lead to misunderstanding - spacing included in 44px in secons bullet - might be confusing

<Fazio> I like that

<Fazio> its simple

<Fazio> clear

<Fazio> +1 alastair

<alastairc> For targets, one or more of the following must be true:

Alastair: Would just talk about targets: "For adjacent targets, one of the following must be true:"

<AWK> https://www.irccloud.com/pastebin/K5oI2pBd/

<Zakim> bruce_bailey, you wanted to ask about adding space if size 44x44 ?

Bruce: why do you need space if the target i slarge enough

AWK: You don't have to

<GN015> why checking the size without spacing if spacing may be added anyway?

AWK: This way you can avoid the more complicated measurements if you have the minimum size already

<alastairc> GN - it is one or the other, you can do either.

AWK: thinking of an object in the upper left corner (say, skip nav link): it may be a line of text, not a sentence - would not need to meet 44x44 if there are no adjacent links

<Fazio> It needs to be. Punctuation matters in litigation

Detlev: would that skip link be exempt (layer above)?

AWK: You would need to account for other target

Alastair: Appearing on focus as popover content it would meet the exception

<AWK> For all targets which have adjacent targets, one or more of the following must be true:

Gundula: unsure about the logic of the current proposal the first case i salways met, so you would not need to measure the spacing - so why mention spacing?

<Fazio> +1 to Gundala

Gundula: should say including the spacing to adjacent interface component

<AWK> The sums of the target width and height, added to the spacing to each adjacent user interface component target, are each at least 44 CSS pixels.

Alastair: Gundula, to your point about absolute measurements, most toolbar content would fail, which is why it was pushed to AAA

AWK: its not width / hight, it is the sum of width/height PLUS spacing, hope the text inserted above addresses that

Gundula: liked previous wording without bullet points better

<Chuck> bummer I like the bullet points

<alastairc> acl jf

JF: Listening to this, freking out in terms of testing perspective - we are already struggeling, if we take it to general population, this is going to become a real nightmare - this what led to target size relegated to AAA

Jake: There is feedback from Wilco and Shawn that this could be automated

<Fazio> It has to be clearly defined before it can be automated

JF: All the exceptions make this very difficult to automatically test

<GN015> It seems my remark was not perceived: Given the touch target measures 44 CSS pixels in width and height, a measuring including spacing does not need to be done. So why measure without space here? Only the second bullet pont (measuring including space) is needed here.

<Zakim> JF, you wanted to ask about testability

Alastair: We have agreed at TPAC that it is to get the right wording for the intent, which is complicated

<Zakim> bruce_bailey, you wanted to say I don't think we need exceptions at AAA

<Chuck> This is AA

Bruce: It is not that complicated - but we could do a AAA version now without exceptions

Alastair: We have that in target size

David F: Important from Coga perspective, strongly suggests not to move it to AAA

JF: Sure but it is quite hard to evaluate this consistently - if it cannot be more clearly defined then it won't be workable

Alastair: Reads Gundula's insertion (only seconsd bullet point needed)
... Good point - maybe we don't need the first bullet point...

Chuck: The second point contains first as a subset

<alastairc> For adjacent targets, the sums of the target width and height, added to the spacing to each adjacent target, are each at least 44 CSS pixels.

<GN015> agree with chuck

<Fazio> For the record I really think the bullet approach works best for clarity. We should stick with it

<AWK> For adjacent targets, the measured distance between the centers of the two targets must be at least 44 CSS pixels, except

Detlev: Formulation not unambiguous unfortunately...

<Zakim> JF, you wanted to ask [perhaps a stupid question "square surface"

Alastair: We know what we are trying to say - may be we need to go away and wordsmith individually to get it right

JF: Can be not look at total surface instead of dimensions? . just tossing that out...

<Fazio> would touching target ares be a problem?

<GN015> The number of monitor pixels representing 44 CSS pixels is very different for different devices.

JF: Talk about surface size of the target itself?

<JF> 44px X 44px = 1,936 sq. Px

Jake: doesn't work for long targets with too little height

<Chuck> me too

AWK: Thinking about centers

<GN015> Furthermore, this way zooming would be made a valid technique, which last week was agreed is not a good way to go.

<Chuck> Same page as Andrew

(...reads out option pasted in above)

<Fazio> are the centers the only active parts?

<kirkwood> agree with centers.

<GN015> Next, going to a different measurement that CSS pixels would make the WCAG 2.2 as a whole inconsistent.

<alastairc> Suggested: For adjacent targets, the measured distance between the centers of the two targets must be at least 44 CSS pixels, except

Jake: hard to test

<Fazio> targets could still touch technically though

<kirkwood> +1 on centers of AWK

AWK: you need to apply som maths (tools) to do it

<Chuck> same issue though with current definitons

Gundula: Objects to the statement that it can be done - think of a small target between two large targets, it would fail for that middle target

JF: pushes back on Gundula's point that zooming would be a valid technique to enlarge targets, didn't have consensus

<Chuck> last week, I brought up zooming

Alastair: had a conversation, was conceivable as way of enlarging but no way of measuring since CSS measurements stay the same, so difficult to come up with a valid approach for measurment

JF: We need to focus on the functional outcome - people do zoom in to increase targets, should not be dismissed since it is hard to meansure
... worried about all these exceptions

Alastair: It's not that it is rejected as acceptable technique

JF: If people start to overlay it would not preserve spacing

<JF> It's not a work-around

Gundula: Zooming is a valid work-around - large hands or slight tremor, why should they put up with less content when zooming in?

JF: Everyone's needs are involved, incl. users, content creators, testers - we cannot be too prescriptive

<bruce_bailey> i disagree that zoom even solves the problem

Gundula: likes the first exception "a mechanism is available" (which might be zooming)

Alastair: Wrapping up

This is scribe.perl Revision: 1.154  of Date: 2018/09/25 16:35:56  
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/100 pixels above/100 pixels below/
Default Present: PascalWentz, Rachael, PeterKorn, Chuck, sajkaj, JakeAbma, Laura, Gundula, Jennie_, Fazio, stevelee, bruce_bailey, Brooks, CharlesHall_, david-macdonald, Detlev, Nicaise, kirkwood, Michael, JF, present, alastairc
Present: PascalWentz Rachael PeterKorn Chuck sajkaj JakeAbma Laura Gundula Jennie_ Fazio stevelee bruce_bailey Brooks CharlesHall_ david-macdonald Detlev Nicaise kirkwood Michael JF present alastairc
Regrets: Rafal
Found Scribe: Jennie
Found Scribe: Detlev
Inferring ScribeNick: Detlev
Scribes: Jennie, Detlev

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