<laura> Scribe: Laura
<kirkwood> yes
<AWK> +AWK
ac: Accessible Authentication Results. 7 questions
ac: simple change. But it is normative.
<alastairc> https://github.com/w3c/wcag/pull/1408/files
ac: 13 agree with the change
suggest resolve to accept.
<Chuck__> +1 to accept
RESOLUTION: accept pull request 1408
scribe: second topic Clarify exceptions in definition.
<alastairc> https://github.com/w3c/wcag/pull/1411/files
scribe: It was pointed out in
github issue 1310 that exceptions need to be part of the
definition, as notes are not normative. Pull request 1411 shows
the change in the SC text, which is to move the note for
"cognitive function test" into the main definition.
... all agree accept awk
... It is still memorization, even if it is easy because of
repetition.
awk: The right way to handle this is not to say that remembering your own email address isn't memorization, it is to exempt these specific items that are memorized from the requirements of the SC.
<alastairc> Current proposed text: "memorization, such as remembering a username, password, set of characters, images, or patterns. Common personal identifiers such as name, e-mail, phone number, and handle on social media are not considered memorization as they are consistent across websites;"
<GN015> I n the first resolution above, should it say request 1280 instead of 1408?
sl: agree it is an issue. Not sure what to do about it.
ac: bit of a theme with this SC.
<kirkwood> long term memory is not often referred to as “memorization” think this is confusing
<kirkwood> +1 to Alastair
ac: line we have been drawing 1.) things that about you and 2. ) things that are about the web site.
<mbgower> "...are considered an acceptable level of memorization, as they are familar to the user and consistent across websites;"
<alastairc> q/
jk: making it confusing regarding memorization
<Glenda> could we say “not relying on short-term or mid-term memory”?
ac: can we keep it in the definition and make it clearer?
<mbgower> "...are not considered short- or mid-term memory, as they are familiar to the user and consistent across websites;"
awk: let me take a look
here.
... I guess we could.
<alastairc> Current bullet: "memorization, such as remembering a username, password, set of characters, images, or patterns. Common personal identifiers such as name, e-mail, phone number, and handle on social media are not considered memorization as they are consistent across websites;"
<Glenda> we do have a handy dandy list of user identified info for 1.3.5 https://www.w3.org/TR/WCAG21/#input-purposes
<Zakim> mbgower, you wanted to say I've posted a suggested phrase. We can go into detail in the Understanding
awk: need to be specific as to what is allowed.
mg: need to explain in the understanding doc.
<mbgower> "...are not considered short- or mid-term memory, as they are familiar to the user and consistent across websites;"
ac: we have a couple of suggestions.
glenda: can we used the list we already included?
ac: most of them could work. but not all of them.
jr: memory types don’t make a difference.
<alastairc> akc aw
<Jennie> +1 to John R's suggestion
<alastairc> "Common personal identifiers such as name, e-mail, phone number, and handle on social media are not considered cognitive function tests as they are consistent across websites;"
awk: easiest fix “they are not considered cognitive functional tests”
<Chuck__> ack "such
<Chuck__> ack as"
mg: concerned with "such as”. not restrictive enough.
<kirkwood> social
<Glenda> +1 to what mbgower just said. let’s list them specifically. so it isn’t fuzzy or open to different interpretation.
<alastairc> The common personal identifiers name, e-mail, phone number, and handle on social media are not considered cognitive function tests as they are consistent across websites;
ac: any issues with the last wording?
awk: do we have a definition for social media?
ac: no
... if the company allows the social login for other sites may
work.
... we are trying to allow authors to allow 3 party
authentication
... like google and facebook
jk: People are using password managers. We should have that in mind.
ac: considered password managers and social media logins separate
jennie: maybe the problem is the term “social media handle” is the problem?
<Levon> I treat password managers like an accommodation, so I don't have to rely on my poor memory.
ac: don’t know what we have “social media handle” now.
<mbgower> The common personal identifiers name, e-mail, and phone number are not considered cognitive function tests as they are consistent across websites;
<Zakim> mbgower, you wanted to say take it out :)
ac: maybe we should just remove it.
wilco: something like twitter is very common.
<mbgower> The common identifiers name, e-mail, and phone number are not considered cognitive function tests as they are personal to the user and consistent across websites;
ac: do you need to rely on it in this scenario?
wilco: no.
<kirkwood> +1
<Chuck__> +1
ac: any objections to: “The common identifiers name, e-mail, and phone number are not considered cognitive function tests as they are personal to the user and consistent across websites”?
<JohnRochford> +1
<Jennie> +1
Laura: +1
<sarahhorton> +1
RESOLUTION: Accept amended pull request 1411, close issue 1343 and incorporate feedback from 1344
ac: top of the understanding document gets bogged down in 'cognitive function test' and loses sight of the authentication scope.
<alastairc> https://github.com/w3c/wcag/pull/1412/files
<alastairc> New text: "The general case of remembering a password is a <a>cognitive function test</a>, which are known to be problematic for many people with cognitive disabilities. "
ac: I put together a change in the understanding doc, which adds a line near the top.
<stevelee> +1 to Rachael
ac: Rachael said "The general case of remembering a password..." seems needlessly complex. Can we just say "Remembering a password..."
<Jennie> +1 to Rachael
ac: MG said I just want to break it up to be grammatical: <p>The general case of remembering a password is a <a>cognitive function test</a>. Such tests are known to be problematic for many people with cognitive disabilities.
<alastairc> Remembering a password is a <a>cognitive function test</a>. Such tests are known to be problematic for many people with cognitive disabilities.
ac: any objections to the change?
<kirkwood> +1
Laura: +1
<JohnRochford> +1
RESOLUTION: Accept amended pull request 1412
ac: 1st example in the understanding document confuses email & username issues.
<alastairc> Proposed text: A web site uses a properly marked up username and password as the login authentication. Copy & paste is not blocked on the inputs, so the user's browser or extension can identify the purpose of the inputs and automatically fill in the username and password
ac: As well as pointing out the
note on the same topic (which essentially answers the
question), there is a small change outlined in Pull request
1415 that shows the change in the understanding doc, which adds
to the first example.
... any objections to the text?
RESOLUTION: Accept pull request 1415
ac: smhigley pointed out that
there are cases (such as web-based command line tools) where
copy-paste is necessary.
... question around making it more explicit.
<kirkwood> we should keep in mind going to a public machine
ac: From previous discussions,
copy-paste is necessary for things like password managers, and
we do not want to discourage that.
... However, allowing for any copy-paste to 'pass' can lead to
very intricate processes where you have to swap apps multiple
times whilst maintaining an item in the clipboard within 30
seconds.
jr: (inaudible)
ac: not sure it is available to web content
<kirkwood> we can not allow copy paste.
sl: question is if copy/paste is available or if we are requiring people to copy/paste.
ac: author may not know.
jr: preventing copy/paste is terrible.
ac: we talk about that in the understanding doc.
jk: have copy/paste in critical path NYC kiosk inaccessible.
<Zakim> AWK, you wanted to point out my suggestion in issue 1418
awk: suggest the problem is a problem with the kiosk
<Zakim> mbgower, you wanted to say that a kiosk is likely an exception. WIll we have any exception?
mg: kiosk is a closed system. Not applicable.
<kirkwood> don’t think so
mg: are there situations where this is not possible?
<AWK> "closed environment" rather than "closed system"
mg: should be ways of doing it.
jr: assume this will be in the
understanding. doc.
... should work for everybody.
mg: I have had very high security
clearance. used app on iphone, etc.
... some extreme cases but I don’t think we have to address
them.
<Jennie> * But their supervisor could be blind, and may need to know what the training covers.
<alastairc> "transcription, such as typing in characters. Copy and paste, such as that automated by a password manager, is not considered transcription but requiring multiple steps or applications to complete a paste is a cognitive functional test;"
ac: PR talks about updating the definition of transcription.
<mbgower> +1 to tackling in understanding
ac: probably should simplify to
Copy and paste is not transcription.
... is that okay with coga folks?
jennie: time where formatting may
be different. Is that something for the understanding
doc?
... yes.
... gives example with a hyphen
<JohnRochford> What a great memory Jennie has!
ac: when copying from an SMS you get the full message
<GN015> Sorry, I have to leave early today. have a good meeting!
ac: suggest not to accept PR and update understanding doc
<alastairc> Proposal: Do not accept the PR, propose a new understanding, allowing for copy/paste.
<Wilco> +1
<Jennie> +1
Laura: +1
<Levon> +1
RESOLUTION: Do not accept the PR, propose a new understanding update, allowing for copy/paste.
<alastairc> scribe:kirkwood
<alastairc> https://github.com/w3c/wcag/pull/1414/files
AC: fairly straight forward,
think multistep. change is here
... just changin to ‘for each step’
... compare between choice options, assumed applied across
steps
SteveL’ one or two factors and then all the rest
AC: each stage has to pass
AD: reworded what we had previously
SL: that’s good wasnt quite sure what the issues was
AC: anyoone abject to except pull request
Wilco; seems like sam requirment, what is the differnce?
AC: you could have a passing method for first but not second
WF: seems like it would pass
AC: if not negative impact it
would be helpful
... blocker for you WF?
WF: no
AC: no objections
RESOLUTION: Accept pull request 1414
AC: last of authentication
questions
... what i suggested taking picure of common objects, remeber a
cat in future
... mulifunction test would not include personal info
... need to expand on examples
... the example was identify which image contained image
... need to add something around cpaptures and examples
... do people agree with approach
... think we should update understanding to make clearer
... agree with Sarah comments
... good approach?
SL: PR doesn’t seem to
match
... culture issues is there
... going to add sums, dysclaculua issue?
AC: that is a failure
... there are formatting issues which i fixed
... andrews point was addressed
... bruce agrees its tough
... see if people agrees with raitionale
MG: understand
<laura> s/. not restrictive /. It is not restrictive /
AC: its a greay line
... have used capture as authentication
... do agree that balancing act and need too update
understanding
... not hearing objections
RESOLUTION: Accept amended pull request 1407 and we will update the understanding doc instead.
AC: next have target spacing,
only first question, have several issue about spacing
... we got to situration trying to make target samller, sems
like be better dealt with personlization
<alastairc> Proposal: "The size of the target for pointer inputs is at least 26 by 26 CSS pixels except when:"
AC: make smaller minimal siaze 26 x 26 with same exceptions as previously
SH: had some questions about
affect of it, my understanding moving aswy from spacing and
towards specifying target size, seems name should be
updated
... to reduce activate control using space if we should circle
back to that spacing for this SC
AC: yes generally we know bigger
better, so many scenerios inroduced issues so think AA
... came because even using spacing it still impacts
heavily
<alastairc> https://www.w3.org/2002/09/wbs/35422/wcag22-target-spacing-issues/results
DF: no seeing in survey, is it in there?
AC: yes
DF: see it now
<laura> s/definition of transcription /definition of transcription /
DF: you put it quite well,
discussed spacing option. to combine minimal target size and
spacing and found didn’t go well together, hard to control,
diifficult to express
... smaller size would go well with AAA
... 26 acceptable, but dropdowns, tqables often smaller than
26. just link with no p;adding. difficult
WF: might need to think about,
not conviniced smaller target with spacing rather than larger
target with no space. no evidence seen with targets being flush
next wo other
... think current is more clear
AC: did 26 come form somewhter?
DF: don’t remember Micorosoft or empircle google docs, email , if it was a common size Jake meay now
<AWK> "Kathy from the TF noted: "The 24 CSS px comes from Microsoft’s research where they are recommending a target area of 24px with a minimum of 16% spacing. If we look at the minimum that is 3.8px so we rounded that to 4 CSS pixels.""
<alastairc> AWK - that was their prefered icon size, it wasn't a usability/accessibility recommendation
Jake: ther was research with 24
and 4 pixel spacing, there were combined minimal size with
spacing
... why 24 with space or 28 without
... so according to all comments basic thought was to focus on
AA version of target size
Jake; it was 24 then 24 may be Kathy or others gave input in discusssion
<Glenda> “Microsoft's Windows Phone UI Design and Interaction Guide suggests a touch target size of 34px with a minimum touch target size of 26px.” https://www.smashingmagazine.com/2012/02/finger-friendly-design-ideal-mobile-touchscreen-target-sizes/
Jke: t was 24 then 26 may be Kathy or others gave input in discusssion
<Sukriti> Alaistar, Kathy mentioned your research for 26
Jake: seemed 26 was best alternative
Ac: we’ll come back to specific number
WF: occurs to me all links would
fail this
... seems extreme
Jake: i was thinking the same
]Jake: every interacttive element below might need spacing for example
Jake: couldn’t think of logical
defensible one
... there is a need but where to draw line need help
AC: 44 Wilco sayd pixel spacing
goog for some scenerios
... this version captures something different
DF: one option we have is unless
element is a native element, if you have text just text, native
link, not ure, as soon as you start exceptions list will grow
longer, such as in line links, wrapping to second line becomes
an option, is list in line, lots of issues
... what is in scope what are we trying to get at.
... in line text or dropdown list not sure where to draw
line
BrooksN: target on bulls eye for example
BN: what i’m getting at is about
finger size issue
... stylus versus finger, is this really getting at user need
here
... can imagine use of wrong click but not too small
WF: if you put content in its not
user agent, i cna only imagine user agent controls like check
boxes and radio buttons
... seems we are getting sutck here, maybe we should scope out
to say these things at the very least should be explored.
limiting to buttons or menus
Jake: we are hitting some dead
ends, started more than a year ago, preventing accidental
activation for target smaller than 44 x 44 then went smaller to
26 x 26
... if need to define size, with perfect list we have two
forces at play.
... if make too big can’t put enough info on page might have
push back
<Brooks> I haven't heard of anyone skinny-thumbing a mobile touch target. I'm not sure the problem to solve for the mobile space is creating rule that makes it easier to activate a target. It seems to me that the intent of this SC is to prevent accidental activation of nearby targets. An SC that only speaks to minimum target size doesn't solve the original problem.
Jake: provide spacing to cover 44
and at least 24 by 24 stil ned spacing as mentioned in
github
... we got rid of spacing and even tried AAA
... so difficult
AC: getting something in AA doesn’t seem likely
<alastairc> Brooks - The other aspect is that you need to know about is the heuristics that the devices use, if you miss a small target it will often guess which you meant. So spacing them out helps.
DF: differnce between pointer and
touch. with touch harder to hit small targes, but wanted to be
conscious of that, didn’t want to create a carve out
niche
... thats why stuck with what work for both. probleme with
spacing allow for target very small. then designer would make
target very samll meking target too smalll
... need to figure out how to combine minimum target size with
miminum spacing
WF: there may be some way out of hole but may need more work in tadk force
BN: i agree iwht Detlev with comibined approach of target and spacing
AC: when talking target size of
spacint. how links in vericlaly spce list without going off
screen,
... maybe good to go on to comments in survey, don’t fhink
we’ll find research around the size
... what they use for minimum size, and other examples can
show, don’t want ot create a increased workload across
industry
... anything above 16 for example will capture quite a
lot
... its always going to be somewhat arbitrary
... glenda put a link in around 26
Glenda: its from windows 2012
<sarahhorton> https://docs.microsoft.com/en-us/windows/uwp/design/style/app-icons-and-logos#more-about-app-icon-assets
GS: thats what i think its about size of human finger
AC: might be a way forward
<sarahhorton> https://developer.apple.com/design/human-interface-guidelines/macos/icons-and-images/custom-icons/
<Glenda> “A past study from the MIT Touch Lab found that the average person’s fingertips are 1.6– 2cm (0.6–0.8 in) wide. The impact area of the typical thumb is even larger — an average of 2.5cm (1 inch) wide! Designing touch targets to account for the physical dimensions of users is basic user-centered design.”
<Glenda> https://www.nngroup.com/articles/touch-target-size/
AC: not really saying about good size target in Microsoft material
GS: a MIT touchlab reference average person finger size
AC: not even center of finger
SH: thinking about it phisical world we have specification. if building a building
<Glenda> cool references at the bottom of the NNGroup article: References
<Glenda> Parhi, P., Karlson, A. K., and Bederson, B. B. 2006. “Target size study for one- handed thumb use on small touchscreen devices.” In Proceedings of the 8th Conference on Human-Computer interaction with Mobile Devices and Services. MobileHCI ‘06. DOI= http://doi.acm.org/10.1145/1152215.1152260
<Glenda> Dandekar K., Raju B.I., Srinivasan M.A. (2003). 3-D finite-element models of human and monkey fingertips to investigate the mechanics of tactile sense. Journal of Biomechanical Engineering, 125, 682–691. DOI= 10.1115/1.1613673
SH: we producing operating systems can adopt determination
<Glenda> Look at this research: https://dl.acm.org/doi/10.1145/1152215.1152260
SC: looks like average size of finger is 40 pixels, and 24 touch size
<Chuck__> kirkwood: having difficult time with this, this is an arbitrary number. There are user agent functionality that is built into every device where...
<Chuck__> kirkwood: you are able to zoom in. As far as touch target size is concerned, I don't think that... we just need to pick a number. We can't compare...
<Glenda> “The results showed that while speed generally improved as targets grew, there were no significant differences in error rate between target sizes =9.6 mm in discrete tasks and targets =7.7 mm in serial tasks. Along with subjective ratings and the findings on hit response variability, we found that target size of 9.2 mm for discrete tasks and targets of 9.6 mm for serial tasks should be sufficiently large for one-handed thumb use on touchscreen-based
<Glenda> handhelds without degrading performance and preference.”
<Chuck__> kirkwood: a point size with digital and printed materials, it's arbitrary.
<alastairc> Kirkwood: Difficult time with this, it is an arbitary number. There's UA features built into screen devices where you zoom in, so the target size can get bigger. We just have to pick a number. We can't compare point size like we can with printed size, and not like physical architecture either.
<Chuck__> kirkwood: door sizes make sense in physical world, but doesn't make sense in digital world.
<alastairc> ... just pick a number
<Detlev> The size of the target for pointer inputs, or the non-interactive space surrounding the target, measures at least 26 by 26 CSS pixels except when
DF: trying to include target size suggestion with spacing in it
<alastairc> Suggested update: "The size of the target for pointer inputs, including non-interactive space surrounding the target not shared with other targets, measures at least 26 by 26 CSS pixels except when:"
DF: this would leave out number and issue of shared spacing and small target size
AC: suggest with shared spacing need to be addressed
DF: gave examples not sure
GS: while we are dealing with digital stuff this is the moment when physical
<Sukriti> http://touchlab.mit.edu/publications/2003_009.pdf
GS: thinks mobile HCI not free
but has been scientific research on human beings and digital
interfaces
... prefer a study rther then 24 sounds good
AC: think in where to go narrowing down to agree that 44 not going to work
<Glenda> @Sukriti, it is a different research article. I think both the one you referenced and THIS one should be reviewed..so we can use this research to explain whatever size is finally chosen. Parhi, P., Karlson, A. K., and Bederson, B. B. 2006. “Target size study for one- handed thumb use on small touchscreen devices.” In Proceedings of the 8th Conference on Human-Computer interaction with Mobile Devices and Services. MobileHCI ‘06. DOI=
<Glenda> http://doi.acm.org/10.1145/1152215.1152260
AC: seems to setup things getting
push back, seems llik focusing in on a smaller size
... think covers survey questions
AC: like to get proposal is with
explainer texxt with where number came from out to those on
github that raised issue
... would be useful to get organization feedback
<alastairc> https://www.w3.org/WAI/GL/wiki/WCAG_2.2_Issue_tracking_and_resolution
<sarahhorton> A note for the proposal, update the SC title to reflect the updated intent
AC: would appreciate read through
one issue and propose response, we have somehting like 10
issues per success criteria
... need people to read and respond
... need to agree then work through
... any questions?
presnet+
This is scribe.perl Revision of Date 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/sinacio/scenario/ Succeeded: s/auther/author/ Succeeded: s/Resutls/Results/ Succeeded: s/aggree /agree / FAILED: s/. not restictive /. It is not restrictive / Succeeded: s/comapny /company / Succeeded: s/tryig /trying / Succeeded: s/and. facebook/and facebook/ Succeeded: s/consideedr /considered / Succeeded: s/socal /social / Succeeded: s/someting /something / Succeeded: s/probelm /problem / Succeeded: s/secuity /security / Succeeded: s/addess /address / FAILED: s/defintion of transciption /definition of transcription / Succeeded: s/transciption/transcription/ Succeeded: s/fairyl straignt/fairly straight/ Succeeded: s/restictive /restrictive / Succeeded: s/36/24/ Succeeded: s/i is available /it is available / Succeeded: s/peole /people / Succeeded: s/defintion of transcription/definition of transcription/ Succeeded: s/transciption/transcription/ Succeeded: s/whhen copying from an sms /when copying from an SMS / Succeeded: s/not accept PR /not to accept PR / Succeeded: s/understanding doc/understanding doc instead./ Succeeded: s/restictive /restrictive / Succeeded: s/defintion /definition / Succeeded: s/transciption/transcription/ Default Present: Chuck__, MichaelC, Rachael, alastairc, Laura, Francis_Storr, stevelee, Raf, MelanieP, AWK, Nicaise, kirkwood, GN, sarahhorton, Jennie, Glenda, Brooks, Grady_Thompson, juliette_mcshane, mbgower, Sukriti, Levon, Katie_Haritos-Shea, JohnRochford_, Wilco, Detlev, (sorry, meeting, overran), JakeAbma, bruce_bailey Present: (sorry AWK Brooks Chuck__ Detlev Detlev_(sorry Francis_Storr GN Glenda Grady_Thompson JakeAbma Jennie JohnRochford_ Katie_Haritos-Shea Laura Levon MelanieP MichaelC Nicaise Rachael Raf Sukriti Wilco alastairc bruce_bailey juliette_mcshane kirkwood mbgower meeting meeting_overran) overran) sarahhorton stevelee Regrets: JustineP BruceB DavidF CharlesH Wilco Found Scribe: Laura Inferring ScribeNick: laura Found Scribe: kirkwood Inferring ScribeNick: kirkwood Scribes: Laura, kirkwood ScribeNicks: laura, kirkwood 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: Input appears to use implicit continuation lines. You may need the "-implicitContinuations" option. WARNING: IRC log location not specified! (You can ignore this warning if you do not want the generated minutes to contain a link to the original IRC log.)[End of scribe.perl diagnostic output]