<laura> Scribe: Laura

<sarahhorton> I can scribe for the 2nd half

AC: Welcome everyone. Looking for a scribe for second half. Anyone new to the group?
... mostly WCAG 2.2 stuff today.

Auto-captions note https://www.w3.org/WAI/GL/wiki/Conduct_expectations

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

AC: discussion last week on Auto-captions. We have a Wiki page: Conduct expectations
... added a section on Auto-captions to that page.
... quality of the captions can leave a lot to be desired.

<Zakim> Rachael, you wanted to correct minutes to captions

RM: will add a sentence to it about downloading the captions.

Ac: will enable captions now.
... Any other questions about the auto captions?

Target spacing (Q1-3 only) https://www.w3.org/2002/09/wbs/35422/wcag22-target-spacing-issues/results

Updated SC text for closing issues

<alastairc> https://github.com/w3c/wcag/pull/1645/files

AC: created an updated taking on wilco's suggestion.
... think we have kind of resolve the issues we talked through previously.
... on the survey Patrick Lauke said, I'm still wondering if the use of the word "offset" in the normative wording isn't confusing. Maybe it's just me, but "offset between targets" on first reading sounds like padding/margin between them (before I then carry on reading the normative wording that immediately redefines what I would think that word generally means).
... "Especially the "between" doesn't help, as it reinforces in my mind the fact that it's, well, the space between..."

<Detlev> wound "offset of" be any better?

We went through a lot of options previously but have not found a better way to say it.

<alastairc> Starting "The offset of targets is at least 24 CSS pixels"

<david-macdonald> sounds weird.

scribe: "offset of" may work but almost sounds like the space that target should take up his at least this size.
... loses that relationship to other targets

<alastairc> "The farthest point of one target to the nearest point of an adjacent target is at least 24 CSS px, except if:"

Dm: when we kind of hijack a term, in this case "offset", we usually define it.

AC: Could removed it all together with a definition.

Detlev: trying to find out the current status. Does it include Wilco's update?

<alastairc> https://github.com/w3c/wcag/pull/1645/files

MG: leery to try to recraft this.
... suspect that this will be a long conversation.

<alastairc> https://raw.githack.com/w3c/wcag/scha14-pointer-target-spacing/understanding/22/pointer-target-spacing.html

<alastairc> https://github.com/w3c/wcag/pull/1645/files

Ac: We have our current draft and we have an update to that.

<alastairc> Each <a>target</a> has a unique area of at least 24 by 24 CSS pixels, except if:

Ac: It reconstruct the first part, and the bullet, so it moves the whole last offset bit into the first bullet.

Dm: I think wilco's is quite good.
... I like it.

Ac: it's not it's not trying to change it.

<alastairc> Preview of the new version: https://raw.githack.com/w3c/wcag/ebda32c44d51f9cb2e1d0e897ff3444789e76489/understanding/22/pointer-target-spacing.html

detlev: It is much clearer.
... do we have time for the final wording?

Ac: the main thing is it, it's not trying to make a big change, it's, it's kind of shuffling around the pieces that we already have.

Mg: I have concerns with the use of unique area, each target has a unique area of at least 24 By 24 CSS pixels
... seems to be prescribing the size of the target which I thought we wanted to get away from.
... see a lot of potential problems.

<Detlev> good points..

Ac: it's not trying to change the, the requirement, it does change the emphasis, so it's starting off with the unique area of a certain size
... not convinced it does change the requirement.

Sarah: I'm concerned about the unique area.

<JF> +1 to Michael & Sarah

ac: we used to have the bullet with nested,

Sc: increases the scope.
... it is possible to have two targets next to each other that are 20 pixels wide.

Wilco: The first thing that stands out to me is that you didn't remove the other bullet that this was supposed to replace.
... don't understand the concern about unique area. It has always been there.

Ac: t's the change in emphasis because when you start off with the language about it can be size plus spacing.

wilco: If it is 24 by 24 you're good. If it's smaller than that, you might still be good, depending on how much space there is between the target and the targets.

Ac: It looks like a bigger change than it is.

dm: Yes, I would agree with that, you got that second bullet. It gives you everything that you had a new SC.

<Wilco_> Suggest using the language of 2.5.5: The size of the target for pointer inputs is at least 24 by 24 CSS pixels except when:

dm: in favor of where we are going with this.

AC: I believe the requirement in the two versions we're looking at is exactly the same, it's just the way that being presented.

Sarah: That does account for the space in between is now an exception for needing to meet the area of 24 by 24 with the target alone.
... I like that it is simpler but worried that we're gonna go into a whole other round of hand wringing about it but it.

<Detlev> Mike can you give a practical example what issues may arise?

<mbgower> Can you please re-paste this proposed version, in it's entirety? Or provide a link?

Sarah: maybe remove the word "unique""

<alastairc> https://raw.githack.com/w3c/wcag/ebda32c44d51f9cb2e1d0e897ff3444789e76489/understanding/22/pointer-target-spacing.html

Ac: The word unique helped in terms of saying that it's not overlapping.

<Detlev> ...but imagine the nested exception missing...

<david-macdonald> except when (is used more in WCAG.. we don't usually say except if

ac: 2 things: One is, if anyone can see any issues created by this, that it's not got the correct scope, that's one aspect. I don't think it does because it's using the same language as before, it's just flipped it around.

<alastairc> https://github.com/w3c/wcag/pull/1645/files

<david-macdonald> https://github.com/w3c/wcag/pull/1645/files

ac: Second where people think the change in emphasis is wrong.

<mbgower> Pointer target

<GN015> suggestion: Pointer Target Size

Mg: I think it's just kind of inverted it. Unique area caught me by surprise. I understand now. Let's go with this.

<david-macdonald> I could live with "pointer target"

<Detlev> target size (minimum)

bb: "offset" seems awfully technical to me.

<kirkwood> +1 to bb

Ac: maybe remove the word offset

<Wilco_> -1

<GN015> +1 target size (minimum)

<david-macdonald> that could work

<AWK> "Target Size with Spacing"

<mbgower> I think offset is the best we have

<alastairc> "Spacing: The farthest point of one target to the nearest point of an adjacent target is at least 24 CSS px;"

Ac: but keep the definition.

Detlev: I don't even think that may even need "unique"

<alastairc> https://raw.githack.com/w3c/wcag/ebda32c44d51f9cb2e1d0e897ff3444789e76489/understanding/22/pointer-target-spacing.html

<mbgower> bingo

wilco: I remember why we used offset. It's because you want to compare every target to to every other target.

<Zakim> mbgower, you wanted to say you need "unique" because you are removing 'nested' bullet

Mg: we need "unique".

<Detlev> OK, let's leave it in...fair pint

Mg: It's possible to come up with a situation where the, the outside target can have less than 24 pixels

<Detlev> :)

<mbgower> it's gonna need a lot of rewrite on the Understanding document

<alastairc> https://github.com/w3c/wcag/pull/1645/files

ac: Does anyone object to taking on the PR with the update?
... you think you'd say, No, at the CFC stage, please let me know now.

mg: Understanding doc will need a lot of work with this update.

Awk: I don't know if I have concerns.

<kirkwood> second that

Awk: Hard to read and understand at a first go.

<alastairc> Previous version: https://raw.githack.com/w3c/wcag/scha14-pointer-target-spacing/understanding/22/pointer-target-spacing.html

Awk: this has been a severe challenge from the beginning.

<alastairc> New version (minus 'nesting bullet'): https://raw.githack.com/w3c/wcag/ebda32c44d51f9cb2e1d0e897ff3444789e76489/understanding/22/pointer-target-spacing.html

Awk: it hasn't gotten any easier.
... I need to look at it a lot more.

Dm: if there is strong agreement, I could take a pass at the understanding doc.

SC: one thing I was wondering about is if we should call this point or target spacing anymore or appointed target area or size,

Ac: that's worth considering as part of the update.

awk: this will be the first real size target size thing that we have at single or double AA.
... would this let you have a single Button with 23 pixels of distance to adjacent targets?


<bruce_bailey> @AWK thats a good stress test

Ac: yes.

awk: the way we dealt with a lot of these questions in the past was going it would impact a user with a disability differently.

SC: the intent of this SC shifted, the intent of this SC was also to avoid if targets are close to each other to have at least spacing so we avoid hitting an unintended target.

AC: one of the things we, we should bear in mind is particularly on touch screens heuristics

<Detlev> so is target spacing the right name after all?

<Zakim> JF, you wanted to note that depending on "heuristics" is problematic - no guarentees

Wilco: Smaller things are less of an issue than things being close to each other

<jon_avila> We have generally steered away from things are usability issues for all - e.g. links with ambiguous names. So I think it's ok that we don't address 1px targets as they are problems for everyone.

JF: Heuristics exists, but we can account for all the different permutations of those heuristics. So I'm concerned about relying on that to do the final mile.
... not that dependable.

AC: we have to draw a line somewhere.

<bruce_bailey> now i am thinking @AWK example of two single-pixel targets 23 pixels from each other does not invalidate proposed phrasing

SC: We actually undershot what it recommended.

Mg: nervous about rapidly adopted fairly significant change in wording. But I don't think it's really changing the criteria.

bb: appreciate that SC focusing on target spacing and not target size.

AC: we do have the AAA SC.

<alastairc> https://www.w3.org/WAI/WCAG22/Understanding/target-size.html

AC: we've got 24 double A, and we've got 44 at AAA.
... we have a couple of points considered, you know, just having a minimum it can be no less than this.
... But we do have certain odd examples.

<Zakim> Chuck_, you wanted to ask for scribe change at top of hour

<alastairc> scribe: sarahhorton

Detlev: Since we are looking again, should we start changing understanding document once agreed, or go ahead now?

Alastair: People want to digest, might be better to wait?

<alastairc> https://github.com/w3c/wcag/pull/1645/files

Alastair: quick poll now?

<david-macdonald> +1

<Wilco_> +1

<bruce_bailey> +1

<Chuck_> Poll: Do you support merging in these changes?

<JF> -1

<Detlev> +1 happy with Wilco's simplification

<michael> 0

<morr4> +1

<Sukriti> +1

<AWK> -.6

<Rain> +1

<GN015> +1

Alastair: doesn't change meaning, changes how it's presented

<Rachael> +.5

<kirkwood> 0

<michael> I do think working through understanding may help QA it

<alastairc> Sarah: One thought, couple of people asked about this produces a name change? If we could clarify that? I don't think it fits in the way it has been re-cast.

Alastair: If doesn't pass would remove SC
... address issues, then have CFC

<alastairc> acn gn

Alastair: merge in update and then get understanding document updated

GN: Is note still relevant since it was about nesting?

Alastair: Since removed word (nesting) can remove note

JF: Feels like there are still questions, can we take time to get answers?

Alastair: Trying to make progress to point where we can address questions
... resolve to merge changes to draft, bring back with updated understanding before CFC

RESOLUTION: Merge changes, bring back with new understanding doc updates, prior to CFC

Minimum pointer clearance needs better empirical backing #1445

<alastairc> https://github.com/w3c/wcag/issues/1445

Alastair: Link was not correct, now fixed, resources section at bottom
... response for why 24px is good amount?
... otherwise resolved all issues

<bruce_bailey> half of the largest commonly used minimum is not a bad answer

<Chuck_> sarah: I remember doing exploration into how Apple human computer interface guidelines and MS guidelines and looked at minimum guideline sizes.

Sukriti: Tolerate 15% error, looked at major websites, also regular text size on websites

<alastairc> 24px was selected as a combination of the research document, with an error margin of 15%. We checked quite a few major websites to check for feasibility, and accounting for regular text size + 4px spacing/padding.

Sukriti: most websites would pass, some would need adjustments

<alastairc> https://github.com/w3c/wcag/issues/1445#issuecomment-777875550

<Wilco_> That's super important to document.

<sukriti_> https://docs.google.com/document/d/1_EHFVE-p4jEtKFa2jMEUruSvu6iv-Vt7UxRW9SrHTCQ/edit#heading=h.ez5cwti49sai

RESOLUTION: Accept the amended response to address issue #1445

Google feedback #1456

<alastairc> https://github.com/w3c/wcag/issues/1456#issuecomment-709321640

Alastair: Quite a few points, addressing all points
... could the interface switch to touch-friendly version

<AWK> +1 to David

DM: Always allow SC to be met through settings, e.g, high contrast

Alastair: Call out when likely solution?

AWK: Try to be consistent

Alastair: Might be something we could add to understanding
... don't always include explicitly, e.g., resize text
... add to SC or understanding?

<Rain> thank you

GN: Explain why 24px in understanding document

<alastairc> https://github.com/w3c/wcag/issues/1456#issuecomment-709321640

<Sukriti> https://raw.githack.com/w3c/wcag/scha14-pointer-target-spacing/understanding/22/pointer-target-spacing.html

<bruce_bailey> FWIW, i don't think Understanding docs have historically document where the specific numbers are justified

MG: Suggested to add "within" instead of "in"

<AWK> Bruce, this has historically been a problem also :)

Alastair: Sentence part of response, not what we have in document
... what to do when a link has all text in sentence
... asked whether "within" helps with that
... example or two in understanding might resolve

MG: Could make entire sentence a link, "within" makes it more in a body of text

<alastairc> Does "The target is within a sentence or block of text" make it clearer what passes/fails.

+1

<michael> 0

<bruce_bailey> +1

<AWK> 0

<david-macdonald> 0 -1

<JF> +.5

<GN015> +1

<Rain> 0

<kirkwood> 0

<Rachael> 0

Alastair: Leave as is, include example in understanding
... currently not explained

RESOLUTION: Accept amended draft response to address issue #1456

Redundant entry (Q1-4) https://www.w3.org/2002/09/wbs/35422/wcag22-redundant-entry-updates/results

Alastair: Come back with updated document next week

Re-entry and security #1346 and #1431

Alastair: Issues with "essential" exception

<alastairc> "Exception: When re-entering the information is essential, or unless re-entry is used to prevent user error, such as re-entry of a new password."

Alastair: suggestion to add text

<Fazio> -1

DF: When someone re-asks, not provide information because scammer, reason why there are redundant questions, adding negates purpose of SC

<Fazio> +1

Wilco: If essential then have exception, don't need to write down, doesn't change

DF: Are we adding in clarification?

Alastair: There's an "or", can see point that opens up gaping hole

GN: Canunderstanding motivation behind password, need reentry to avoid errors

Alastair: Note
... define essentail as can't do functionality any other way, would button that shows password be another way

<alastairc> Suggested update to the note: "Re-entry which is used to prevent a critical user input error, such as re-entry of a new password, is considered essential"

MG: Looked up usability guidelines, NNGroup, reveal password was one approach
... likes essential, put in normative text, email prompts but UA populates email
... password is essential, not notice extra character

<Fazio> No argument here

MG: reenter forces user to do twice, still could do wrong twice, but odds reduced

<Fazio> thats part of security though

MG: reducing something that prevents accessing system

<Fazio> I think it goes in essential too

MG: essential

Wilco: Can justify but specific interpretation

Alastair: Note?

<JF> https://www.w3.org/TR/WCAG21/#input-purposes

Wilco: Not normative

Alastair: Is something essential, subjective
... being as clear as can about something arguable
... not hardcoding something that might have better solutions

<Zakim> JF, you wanted to talk about passwords and SC 1.3.5

JF: Things like passwords, inputs that need to be tagged to identify purpose
... SC says need to tag with autocomplete
... already tagging those types of inputs, got a list of essential form inputs

Alastair: Repeated, when setting password, UA won't know it

<Fazio> this convo doesnt apply

Alastair: can't assume people have password managers

JF: Native in browsers

<kirkwood> user agents autofill as well

<Fazio> nevermind Now that I think yeah it fdoes. duh

JF: even in case with two inputs, both will have autocomplete attributes
... have another requirement that addresses these needs

Alastair: Not sure how helps with this exception

<Fazio> accessible authentication does doesnt it

JF: Password input, already need tag

Alastair: This addresses repeated entry
... doesn't help with question of whether author is allowed to repeat input

Wilco: Important that essential be interpreted narrowly
... want to avoid people interpreting it

<Fazio> I thought we aadded an explianer with MG's suggestion

Wilco: can restrict to new passwords

<Fazio> bingo

Wilco: only allowed for new passwords

<alastairc> Current exception: "When re-entering the information is essential, or when previously entered information is no longer valid. "

<Zakim> mbgower, you wanted to say this discussion is making me even less inclined to include this additional wording

MG: Let's remove note, don't add additional text, can't ask someone to re-enter password, would get pushback
... more don't want anything besides "essential" because prescriptive

<Zakim> Chuck_, you wanted to ask I don't know what John is supporting. In favor of the suggested suggestion, or in favor of not adding?

Chuck: Not sure where JF point, does it support or counter Wilco's exception?

JF: UAs have been establish to address instances, one way forward

<mbgower> To clarify, it wouldn't make sense to put the password autocomplete attribute on a New password field

JF: defined new password, machine can remember once defined
... already have requirement

<mbgower> "new-password" A new password. When creating a new account or changing passwords, this should be used for an "Enter your new password" or "Confirm new password" field, as opposed to a general "Enter your current password" field that might be present. This may be used by the browser both to avoid accidentally filling in an existing password and to offer assistance in creating a secure password (see also Preventing autofilling with autocomplete="new-[CUT]

Alastair: Autopopulating is not useful for this SC because site is asking for unique information, asking authors to auto populate if asking for same information more than once

DF: Thought we covered all these, keep taking one step forward, two steps back

<Chuck_> +1 to David, I feel the same, that it is already sufficiently covered by current text.

DF: one thing to confirm when creating new password, falls under essential, later might still fall under exceptions, why are we still teetering

GN: Discussion of autopopulation, users decide whether browser saves, whether on sheet of paper, not our business to decide
... only point to discuss is whether essential, where to mention it, not about autopopulation

JF: Got series of defined inputs

Alastair: Orthogonal to whether asking for a password is essential

<Fazio> It depends on the purpose

<kirkwood> asking for a password twice should be essential. yes.

Alastair: depends on application, need to focus on whether repeating is essential

<kirkwood> preventing mistakes

Alastair: taking away second input would take away functionality

JF: User agent is doing it

<mbgower> Because it's not essential

Alastair: About whether we allow content authors

JF: Dont have to define as essential, have technical solution

Alastair: Most people say leave as is, any objections, including in SC but included as note

<kirkwood> can we put text in irc. minutes.

<Chuck_> +1

<alastairc> Exception: When re-entering the information is essential, or when previously entered information is no longer valid.

<mbgower> +1 leave as it is

<Chuck_> +1 leave it as it is

<Rachael> +1

<bruce_bailey> +1 leave as is

<kirkwood> +1

<Fazio> +1

<Rain> +1

+1 leave as is

<Raf> +1

<JF> 0

RESOLUTION: Leave SC text as it is

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/it there is/if there is/
Succeeded: s/We ave /We have /
Succeeded: s/spounds /sounds /
Succeeded: s/practival /practical /
Succeeded: s/wouldimpact /would impact /
Succeeded: s/so so /so /
Succeeded: s/resove/resolve/
Succeeded: s/websties/websites/
Succeeded: s/adjustments\/adjustments/
Succeeded: s/Can't / Can/
Succeeded: s/suggested suggestion/suggested exception/
Default Present: Chuck_, alastairc, Laura, Rain, Ben, JF, sarahhorton, morr, GN, Raf, Nicaise, karenherr, oliverkeim, juliette_mcshane, stevelee, MarcJohlic, Rachael, david-macdonald, bruce_bailey, Detlev, Wilco_, kirkwood, Sukriti, JustineP, jon_avila, StefanS, .5, mbgower, Fazio, MelanieP
Present: Chuck_, alastairc, Laura, Rain, Ben, JF, sarahhorton, morr4, GN015, Raf, Nicaise, karenherr, oliverkeim, juliette_mcshane, stevelee, MarcJohlic, Rachael, david-macdonald, bruce_bailey, Detlev, Wilco_, kirkwood, Sukriti, JustineP, jon_avila, StefanS, mbgower, Fazio, MelanieP
Found Scribe: Laura
Inferring ScribeNick: laura
Found Scribe: sarahhorton
Inferring ScribeNick: sarahhorton
Scribes: Laura, sarahhorton
ScribeNicks: laura, sarahhorton

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