<Joshue108> trackbot, start meeting

<trackbot> Meeting: Accessibility Guidelines Working Group Teleconference

<trackbot> Date: 27 November 2017

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

<jallan> scribe: Jim

<AWK> Please feel free to sign up for a slot this week

<Detlev> I can do second part

<Detlev> how long is the call??!

<Detlev> gosh

<Detlev> I have to kleave in 2 hours so min is the second hour

<Detlev> or first

Device Sensors https://www.w3.org/2002/09/wbs/35422/resolving_device_sensors/results

<jallan> detlev: some changes to made to sensors based on Jon A. comments after CFC. do we need another cfc

<jallan> awk: will check. did a second CFC last week. it was approved. no comments

<jallan> ... additional comments at back of queue

<jallan> det: sent changes to list... no comments

<jallan> awk: will review

<jallan> josh: reviews device sensor language

<KimD> old/current: All functionality of the content can be operated without requiring specific device sensor information, unless the device sensor is essential for the function and not using it would invalidate the activity.

<KimD> From TPAC: Functionality which can be operated by device or user motion can also be operated by user interface components and can be disabled to prevent accidental actuation, unless the motion is essential for the function and doing so would invalidate the activity. NOTE: This criterion concerns input through sensors which respond directly to motions such as tilting, shaking, or panning. It is not intended to cover indirect motion associated with operating a keyboa

<KimD> ...keyboard, pointer, or assistive technology.

<KimD> * :-) jim

<jallan> josh: SR you had a suggestion

<jallan> sr: alt language - to not delineate all sensors. fine with proposed language

<Detlev> link?

<jallan> josh: SR like your suggestion. does group want to change or stay with TPAC lang?

<jallan> awk: can we view side by side

<jallan> ... or hear them

<KimD> They are pasted above (by me)

<jallan> sr: replace note with an exception. start the same, add accessibility supported interface

<jallan> josh: alt wording - motion activation ... etc.

<jallan> "Motion Actuation: Functionality which can be operated by device or user motion can also be operated by user interface components and can be disabled to prevent accidental actuation, unless:

<jallan> • Essential: The motion is essential for the function and doing so would invalidate the activity; or

<jallan> • Accessibility Supported: The input interface for the motion is accessibility supported."

<AWK> https://www.w3.org/WAI/GL/wiki/Comment_Summary_2-6-1#Device_Sensors

<Joshue108> https://www.w3.org/2002/09/wbs/35422/resolving_device_sensors/results

<steverep> That's covered by user motion

<jallan> det: any discussion at TPAC... input through camera... someone waving at camera to forward a presentation. not mentioned. could be important in future with AR interfaces

<jallan> awk: is this not covered by currented wording

<jallan> det: if we think covered... withdraw comment

<gowerm> Add a note that camera captured motion should be in the Understanding doc

<gowerm> and maybe a technique

<jallan> awk: what do others think?

<Zakim> gowerm, you wanted to say that I think the change results in a hole where the ability to disable is now lost

<jallan> bruce: did talk about cameras at TPAC

<jallan> mg: add to Understanding and a technique. Not in SC

<jallan> mg: concern about SR lang. have a hole. lost ability to disable and input. someone with tremors would need to disable

<Zakim> steverep, you wanted to say that was fully intended to be covered by user motion

<jallan> bruce: less confortable with SR change. not enough time to think about it.

<jallan> sr: by saying device or user motion, camera etc, was intended to be covered by 'user motion'

<jallan> ... not sure about disabled

<jallan> mg: motion essential for function. critia can be disabled and essential

<jallan> ... new lang - accessibility supported removes ability to disable.

<jallan> sr: confused about focus on disabling

<jallan> mp: was intention to remove the Note on the SC.

<jallan> josh: yes. replace note with SR rewrite

<steverep> Yes, remove the note or replace it with something saying a keyboard interface is accessibility supported

<jallan> al: how to figure out what is accessibility supported?

<jallan> ... test for keyboard?

<steverep> Shall I answer?

<Detlev> shall I try to respond

<jallan> ... what is test for keyboard? how does it pass

<jallan> sr: there is no formal test for a11y support. it is not specified

<jallan> al: if I can use a mouse for a keyboard, I can pass test?

<AWK> brb, need to answer the door for a delivery

<jallan> josh: no

<jallan> det: bring in teaser by swiping. must have a button to allow same function. the button would have to be keyboard actionable.

<jallan> ... forward presentation by moving hand, must have button activated by keyboard or pointer. interactions should be documented

<jallan> al: not satisfied. still figuring it out.

<jallan> al: next question. Don't remember motion from TPAC. any input requires a 'motion', speech, keyboard, eye gaze. short of direct brain connect... everything has motion.

<Zakim> gowerm, you wanted to say that this is another SC that is expanding the meaning of 'accessibility-supported'.

<jallan> al: gnarly problems

<jallan> mg: note removed... delineated what is motion.

<jallan> mg: accessibility supported... not defined in SC. this SC is an expansion of accessibility supported. original tpac language put constraints. is everything captured. do we need to add anything?

<jallan> al: regarding motion... need to think more. motion required by all inputs. hard to split out difference. using examples to delineate, not definition

<jallan> brook: do we need something about lack of motion. QR code to navigate. QR require stability and lack of motion

<jallan> sr: with QR, it is satisfied, enter code vs scanning the barcode. user has to move the phone. should be covered.

<KimD> *There's a lot of noise on the line

<jallan> sr: a11y supported. can live with tpac language. if my rewording confuses, stay with original

<jallan> sr: rewrite was to eliminate examples, and link directly to def of a11y support. look a accessibilty support of api

<jallan> ... if that is only input, not a11y support if phone does not have shaking and the OS or whatever have feature that knows "no shaking" is available and provides a button. that is a11y support

<jallan> josh: can we use TPAC language.

<jallan> sr: fine with original

<Joshue108> ack

<jallan> josh: SR rewrite seems to confuse issue. think about this

<Zakim> Bruce_Bailey, you wanted to suggest going back to device motion and user gestures

<Detlev> maybe "deliberate user motion"?

<jallan> bb: exception at TPAC covers assistive tech and motion. gestures? hand, camera, swiping

<Bruce_Bailey> Did we talk about camera gestures (as compared to touch screen gestures)?

<jallan> sr: worry about generalizing. could you camera, or IR interface. many ways to detect user motion.

<gowerm> Original text pre-TPAC: All functionality of the content can be operated without requiring specific device sensor information, unless the device sensor is essential for the function and not using it would invalidate the activity.

<jallan> al: please summarize, TPAC change (not SR review). was not in room.

<gowerm> TPAC version: Functionality which can be operated by device or user motion can also be operated by user interface components and can be disabled to prevent accidental actuation, unless the motion is essential for the function and doing so would invalidate the activity.

<gowerm> NOTE: This criterion concerns input through sensors which respond directly to motions such as tilting, shaking, or panning. It is not intended to cover indirect motion associated with operating a keyboard, pointer, or assistive technology.

<jallan> bb: user motion is always there. exempt incidential user motion - operating a keyboard.

<jallan> sr: orig SC had several objections. redundancy with 2.1.1 and scope.

<jallan> ... not require anything beyond 2.1.1, not all device sensors are inaccessible. scope was too wide.

<jallan> ... motion does not make it any clearer than does sensors. everything needs sensors... keyboard, mouse, eyegaze etc.

<steverep> No offense taken!

<jallan> josh: straw poll... +1 for original text,

<gowerm> +1 TPAC version. Also to say we can tweak the note to address some things discussed.

<Alex_> +1

<Rachael> +1

<AWK> +1 for original text

<Detlev> +1 to orignal text but can live with Steve's text too

<Mike_Pluke> +1

<Ryladog> +1

<steverep> +1

<Bruce_Bailey> +1

<Joshue108> https://www.w3.org/2002/09/wbs/35422/resolving_device_sensors/results

<jallan> From TPAC: Functionality which can be operated by device or user motion can also be operated by user interface components and can be disabled to prevent accidental actuation, unless the motion is essential for the function and doing so would invalidate the activity.

<jallan> NOTE: This criterion concerns input through sensors which respond directly to motions such as tilting, shaking, or panning. It is not intended to cover indirect motion associated with operating a keyboard, pointer, or assistive technology.

<Joshue108> +1

<Alex_> -1

<jallan> +1

<laura> +1

<jallan> al: differentiation between direct and indirect motion is unclear. examples are insufficient

<Detlev> I think it just needs a definition

<jallan> josh: Alex, can you draft something to demark

<Joshue108> +1 to definition

<jallan> al: what is or is not an direct motion?

<Zakim> AWK, you wanted to offer a modified version

<jallan> josh: this needs a defintion. can we agree on SC text with understanding that def is being developed

<AWK> Functionality which can be operated by device or user motion can also be operated by user interface components and can be disabled to prevent accidental actuation, except when: • the motion is essential for the functionality and doing so would invalidate the activity. • the motion is used to operate a keyboard, pointer, or assistive technology

<Detlev> +1 for that!

<jallan> awk: remove note, add extra bullet, make it normative. eliminate direct/indirect motion

<jallan> jason: implication that UI will respond to motion and other things. overlap with 2.1.1. should 2.1.1 be interpreted narrowly to exclude motion. need to address overlap.

<Joshue108> +1 to AWK text

<jallan> ... how to handle overlap.

<jallan> josh: have you reviewed awk lang.

<jallan> al: don't see advantage of switching to TPAC lang from original. check to see if it is essential vs if motion is involved.

<jallan> ... developer don't know the device or what motion is involved. make the language easier

<jallan> jason: use of NFC device, is essential. the device provides all security, etc. recardless of the motion.

<jallan> al: the sensor is essential, not the motion.

<Detlev> shall I take over scribing?

<Detlev> scribe: Detlev

<AWK> Reminder that we are talking about this item for an hour.

Jason: Suggests to widen the exception to the use of the sensor rather than the motion being essential

<Zakim> Joshue, you wanted to say we need to focus more on what authors need to do to support this

(That was Alex' suggestion rephrased by Jason)

Josh: wants a trimmed-down version that people will understand

<Zakim> gowerm, you wanted to say, what uses of sensor OTHER than motion would not be essential?

<steverep> Here's why we can't just talk about "sensors": https://github.com/w3c/wcag21/issues/572

goverm: scope in original language is broader - why do we need to cover sensors, what other sensors should be captured?

Brooks: QR code may fall into that category - you have to hold the phone to capture the image

Josh: liked Andrew's suggestion - lack of clarity now

Jason: In Alex' scenario (NFC) you can move the terminal to device or the other way round - NFC use may not require moving the dvice

<gowerm> +1 to Jason's point.

Jason: may not fall into th escope of proposal - we can exclude Alex' scenario

Josh: suggests to leave this open and thrash out on the list

<Alex_> note that the NFC scenario is just one that i think of today to point to the problem of this proposal

Josh: good suggestions, but too cmplex to solve now

RESOLUTION: leave open

accessible authentication https://www.w3.org/WAI/GL/wiki/Comment_Summary_2-2-6

Lisa: No one is assigned to this SC - someone should step forward
... looked at comments
... first comment about a small change to legal exception - leave that for now
... another comment about 2 factor auth process
... wrote explanation that 2 factor auth is a problem for people with short span memory
... can be made accessible if link is included in SMS that can be activated, should not rely on coying alone
... 2. coment was about requiring e-mail, and that would not be very secure
... commented that there are other alternative methods, such as biometrics, set back etc
... EU site allows multiple login methods, supplied link to that
... so gave example sites and explained issues
... other comments were similar
... Mike was one of th ecommenter - other thing to be covered is legal requirements

<AWK> where is the current language?

Josh: Someone else should pick this up as SC manager, taking care of comments

<Joshue108> https://www.w3.org/TR/WCAG21/#accessible-authentication

Josh: Any questons or comments to Lisa?

Lisa: Put the comments into the Wiki
... was done this morning

AWK: This is an SC that we have not gone through by looking at specific comments
... we need to be careful to cover responses to evolve language
... we should use time to dig into the comments

Alex: question on 1. comment (who has control of content)
... SC assumes that this is a service administrated by someone on the other hand

<Joshue108> Comment 1 for Accessible Auth https://github.com/w3c/wcag21/issues/354

Alex: if admin can rest that is fine - but in some cases user is administrator him or herself
... there is no reset process for yourself

Josh: let's pcik up comments sas suggeste dby AWK

<Joshue108> Comment 2 for Accessible Auth https://github.com/w3c/wcag21/issues/372

Lisa: if it is a private service (resetting router) then the SC may not apply?

<Joshue108> Comment 3 on Accessible Auth https://github.com/w3c/wcag21/issues/440

Alex: You may lose content by resetting router

Lisa: This is only one option, there are other mechanisms like biometric or a token that come swith the box that don't require copying over a long password

Alex: should every hard drive come with biometrics?

<alastairc> Where might this be for web content? Interesting point, but need some web-content examples.

Lisa: could be a token?

Alex: How can the hardware use the token?

Josh: suggests again going through comments

<Lisa> im not sure routers are in scope

<Lisa> for wcag

Josh agrees router is not in scope of WCAG

#254

<Joshue108> https://github.com/w3c/wcag21/issues/354

sorry, 354

Josh: Lisa's response was to change exception wording..

Lisa: It was another comment that requested a change of wording
... Comment was that understanding is not up so benefits unclear, would need Techniques
... Was in Google docs but was not ported over
... comment was that SC would requring biometrics, but that is not true

<laura> Understanding Accessible Authentication: https://rawgit.com/w3c/wcag21/accessible-authentication/understanding/21/accessible-authentication.html

Josh: Will you update response?

Lisa: yes

Josh: reads comment my Michael Cooper on 'essential'

AWK: this can be resolved entirely by using the word required instead of essential

There was a resolution aon that already

Josh: reading comment in issue #440

<Joshue108> Comment 4 on Accessible Auth https://github.com/w3c/wcag21/issues/441

Lisa: said 2 factor auth requiring copying over is a problem for people
... bu tit can be made less difficult by adding a link so number does not have to be copied

<Joshue108> Then 442, 473, 503 - same as 440 or 441

Mark: Trying to understand why individual can't write down number and taking it over to another device
... similar scenarios exist everywhere

<Glenda> dyslexia

Lisa: problem with repeat letters with no good working memory - getting confused when identifying the next letter

<Glenda> and Dyscalculia

<marcjohlic> But then how do these folks deal with things such as ssn, phone #, credit card numbers etc?

Lisa: difficult when letters are repeated you need to process several pieces of information a tthe same time

<marcjohlic> I get that there are real disabilities, but I guess I'm asking why methods used for phone numbers, cc numbers, zips, URLs etc can't be used for 2 factor as well ?

Lisa: often problems occur when putting in things like credit card numbers
... same problem with new phone numbers, keep them similar to make it easier to remember
... with that SMS there is not enough time to copy that numbwer correctly into the input form

Jason: note that the most secure schemes don't involve SMSs

<Lisa> jason, that is completely conformant if done as a token

Jason: another application runs at the other device, uses a one time password, encryption key is provided once only

<Lisa> app used in the eu funding site does that

Jason: this proposal inherently seems to exclude the most secure authentication options - this is a problem

<alastairc> Jason is right, 2FA via SMS is on it's way out. It will take some time for people to orgs to swap over, but that is happening. https://www.theverge.com/2017/9/18/16328172/sms-two-factor-authentication-hack-password-bitcoin

Lisa: one option using an app, following that approach does not involve copying over info, uses a token

Jason: the way it works is that you get the encryption key via QR that generates the indivdual 6 digit code

that figure relies bith on enc key and the time it was generated - sdo the code would change any time it is called up - an dthat would be needed for authentication

Lisa: understands that - put once you have set up the app, you can put it next to device and send token?

Jason: no, that is not how it works
... you can't send the token

<alastairc> Lisa: I haven't come across a method that magically gets it across from one device to another, would love to see it.

<Glenda> Example of 2nd factor token that does not require typing in a code: https://saaspass.com/about/bluetooth-ble-two-factor-authentication.html

Mike_Pluke: suggestion to write down code on paper - in mobuile scenarios people don't have paper, so unrealisitc;
... credit card info different because it is on the card

<alastairc> Glenda: Interesting, but not available to web content.

Mike_Pluke: difficult situation, cannot easily be solved

Josh: Lisa, mive that to where the group needs it

Alex: we have massive hacks that affect millions - 2 factor auth is the most simple approach to address these problems so they are vital
... so setting up requirements to do it in a specific way will create a lot of pushback since privacy is of prime importance

<Zakim> gowerm, you wanted to say, let's address the single point being raised in this comment.

Alex: we should not put road plocks in the way of 2 factor authentification

goverm: issues should be compartmentalised

<marcjohlic> FWIW the 2-factor apps that I have used have a copy function in them. Are we saying that as long as the 2-factor app has a copy function in it, it would pass? Or is the fact that they have to use that copy function to copy / paste it considered "transcribing"?

goverm: this SC changes exisitng business rules and practices and therefore in cannot be level A

<alastairc> marcjohlic: Interesting, but AFAIK that's not available on desktops?

Lisa: it is single A because it is a complete block to important things like online banking

<Zakim> JF, you wanted to say that some tokens use USB dongles, but not all, and they won't work on cell pnones, etc.

JF: multi-factor authentification common - some processes use USB dongles

<Lisa> alternitves - you need alteritive

JF: should be used multi-factor - for every method there are some users that cannot use it
... we should not be too specific
... providers are already dealing with this - if you have done it twice you can remember the machine and use a cookie stored at the machine. The ways to implement it are much wider than assumed here

Lisa: the SC just says there are alternatives for 2 factor auth - clear that there are many different approaches

Josh: Lisa please think about what you need from the group to move this forward

Lisa: We need someone to manage the comments

<Lisa> https://saaspass.com/about/bluetooth-ble-two-factor-authentication.html

<alastairc> Lisa: Only works on Apple stuff, and doesn't work for web content.

Lisa: before we outlaw 2 factor we need techniques to show how it can be done - maybe bluetooth can be used here

Bruce: folks I've spoken to have serious concerns - there are laws that require best security options - wish there were easier ways.

<Glenda> “FIDO U2F / Security Keys: Universal Second Factor (U2F) is a relatively new style of 2FA, typically using small USB, NFC or Bluetooth Low Energy (BTLE) devices often called "security keys." To set it up on a site, you register your U2F device. On subsequent logins, the site will prompt you to connect your device and tap it to allow the login.” https://www.eff.org/deeplinks/2017/09/guide-common-types-two-factor-authentication-web

Bruce: question to Michael - can we get help from the accessible architecture working group?

Lisa: git some feedback, there was a meeting with the web authentification group

<Glenda> “Like push-based 2FA, this means you don't have to type any codes. Under the hood, the U2F device recognizes the site you are on and responds with a code (a signed challenge) that is specific to that site. This means that U2F has a very important advantage over the other 2FA methods: It is actually phishing-proof, because the browser includes the site name when talking to the U2F device, and the U2F device won't respond to sites it hasn't been registered t[CUT]

<Glenda> is also well-designed from a privacy perspective: You can use the same U2F device on multiple sites, but you have a different identity with each site, so they can't use a single unique device identity for tracking.”

Lisa: There is a link to the TR of their spec

<Lisa> https://www.w3.org/TR/webauthn/

Lisa: another avenue was work with ?? (security expert)
... We should ask janina to set up a call with them

Josh: anyone on the call who can help Lisa with that (covering comments)?

<Zakim> AWK, you wanted to remind people about schedule

AWK: this week is final push - so we have little time need to process CFCs by midday of Friday - then missing that, the SC is either removed or included with exisitng text and marked as being "at risk" - very narrow time window
... si fir this one we had nor responses for the issues raised until this morning - so there not be enough time with outside security people to solve this

Josh: Lisa, are you confident that we can have a final SC text wrapped up soon?

Lisa: One small request to change wording of legal requirement (ou side of control of content provider) can propably be handled - but I can't manage the comments, someone else has to step in

<Zakim> gowerm, you wanted to say the most critical comment I'd like to see addressed is issue 442

Josh: we have to leave this open then

<AWK> +1 to Mike's point.

goverm: The most critical one was a hint to a study that showed that all users could deal with transcribing a 5 digit string - we need evidence at what length of string the problem sets in

Lisa: There is a research doc - there is huge evidence that people with short term memory deficiency can't hold on to two bits of information at a time

<laura> Yes.

<gowerm> for currrent SMS based stuff.

Lisa: also body of evidence for dyslexia, put particularly short term memory problems
... also dementia - all pointing to problems od copying ovr information
... that amount of evidence was not required for anything else

goverm: supply evidence?

Lisa: not doable withion one week

goverm: That one study showed that all people could copy over so it is not evidence for the problem this SC is now focusing on

<AWK> Chair: AWK

<Lisa> http://www.visuallearningcenter.com/why-copying-from-the-board-is-so-difficult-for-some-children/

can the next one take over scribing?

<Lisa> this link may be rubish

<AWK> The Group is taking a 20 minute break

<AWK> We will return at 20 past the hour

<Lisa> https://www.ncbi.nlm.nih.gov/pubmed/11160462

<gowerm> scribe: gowerm

+1

adapting text https://www.w3.org/WAI/GL/wiki/Comment_Summary_1-4-13

<AWK> https://www.w3.org/TR/WCAG21/#adapting-text

AWK: On this one we don't have a survey this point in time.

<AWK> https://www.w3.org/WAI/GL/wiki/Comment_Summary_1-4-13

<laura> Side-by-side comparision: https://www.w3.org/WAI/GL/wiki/Comment_Summary_1-4-13#SC_Text

AWK: At this wiki page, we have responses to a bunch of different proposed issues.
... Laura has been working on this one for a long time.

Laura: We went through almost all them at a November 13 meeting. There are just a few to do
... The last three on the page.

AWK: 577 and 576 are things we don't need to respond to, since they are after deadline.

<AWK> before/after text: https://www.w3.org/WAI/GL/wiki/Comment_Summary_1-4-13#SC_Text

Laura: We added a new editor's note. That note was in response to something discussed at the end of the November 13 meeting
... We are getting rid of the word essential, and scoping it.
... If we can't do that, will have to limit this to blocks of text. We have not seen evidence that it cannot be done yet.

<Zakim> steverep, you wanted to say the editor's note adds nothing specific beyond feedback which is the point of a draft

Steve: I can live with the editors note, but I think it's prolonging something that doesn't need to be there. It doesn't say anything beyond give us feedback. I don't think it has anything

AWK: I think that's a fair point. But I also think it doesn't hurt to focus people's interest in certain areas.
...

Editor's notes will not be in any final version

Laura: And it gives us an escape clause in case we need to lessen the scope

AWK: Another change was to change the title of this from text spacing to adapting text.
...

Okay so the comments to David put in… You have responses?

Laura: Yes and he's okay with the responses.

<Ryladog> Goofd to go

<alastairc> It's ready (crosses fingers)

AWK: What do people think on the call? Are there other issues or concerns? Is this one ready to move forward?

<Ryladog> Good to go...:-)

<Detlev> no concerns

<Glenda> Ready to move forward

GTG

<JF> +1 - let's go

<steverep> +1 to move forward

AWK: I'm not hearing any objections.

<Ryladog> +1

RESOLUTION: Accept SC text as proposed https://www.w3.org/WAI/GL/wiki/Comment_Summary_1-4-13 and comment responses as proposed

accessible authentication https://www.w3.org/WAI/GL/wiki/Comment_Summary_2-2-6

Change of Content https://www.w3.org/WAI/GL/wiki/Comment_Summary_3-2-7

Accidental Activation https://www.w3.org/WAI/GL/wiki/Comment_Summary_2-5-2

AWK: This is one where we've had some discussion and we've had some issue responses.

<AWK> https://www.w3.org/TR/WCAG21/#accidental-activation

This one is 3.2.6

<AWK> New: For single-pointer activation a mechanism is available to use activation on the up-event, either explicitly or implicitly as a platform's generic activation event, unless one of the following is true: The activation is confirmed; The result of the activation is reversible; Down-event activation is essential.

AWK: There were a small number of comments about this one

<AWK> https://github.com/w3c/wcag21/issues?q=is%3Aopen+is%3Aissue+label%3A%7Ecomment-accidental-activation

AWK: Right now there are four comments
... One felt the SC text was too specific.

<alastairc> scribe: alastairc

AWK: For the definition, in the SC it talks about single pointer activation, can we add 'activation resulting from'?

<AWK> Proposed: Single Pointer Activation: Activation resulting from one point of contact with the screen

Detlev: Concerned whether that would cover double-click/tap? Wouldn't be exactly the same point, but perhaps that's a minor concern? Do we refer to the same definition as from pointer-gestures? It would be best to have one definition.
... we accept long-presses & double-taps at the same spot, good to cover the same aspects.

AWK: Not sure if the updated SC for pointer gestures includes the definition?

Jason: I was unsure where we're getting into single-pointer activation as that's a separate SC? I think there was discussion of combining them, so it would all be in one. I also commented on the tech-specifiity, suggested some revised text, but that discussion hasn't finished yet.
... on issue from TPG

https://github.com/w3c/wcag21/issues/330

AWK: (reads from issue)

Jason: Someone suggested a re-wording, but it's a while since I looked at it.

<Zakim> steverep, you wanted to say this has not addressed issue #380 https://github.com/w3c/wcag21/issues/380

Steverep: Not sure what it means by activation for anything beyond a single click. The user-benefit could be there as well, but not sure how to apply to a double-click, gesture etc. Multiple things are being activated in those processes. Perhaps it could be, e.g. a drag n drop has a down event which is essential, but there could still be a way to reverse or confirm it, so long as it works on the down event.
... not sure how to incorporate those.

AWK: The proposed response was to handle in the understanding doc. A series of concurrent actions. It maybe that between other SCs and this, there are situations that are not fully caught, but might be better to focus on single-pointer aspects here rather than widen it up at this time.

Steverep: I think it could be covered pretty easily, e.g. change make clear it is the final step, not the initial down event. In the exception, instead of down-event being essential, make the down event's final state that is the issue.

AWK: Not sure it is as much of a user-issue as the current form. Do you have language to suggest?

Steverep: not off hand, need to think about it.

AWK: Other issues, Gregg's was about the user-agent aspect, is it an authoring thing. Wasn't sure it was do-able.
... fair point that some aspects are covered by the user-agent, could update the SC text to say it isn't applicable to components so that if a browser/OS had a native control, that is not the authors issue. Have language from another SC we could use.
... last issue was Jan Richard's, about irreversible actions. https://github.com/w3c/wcag21/issues/561
... AWK: find the exception approach more readable, but perhaps that's just me.
... Steve raised that it could cover drag and drop, what do others think?

jasonjgw: Problem is that users might issue the down action when not on the target, e.g. with dexterity issues, is that the scenario?

AWK: No, typically, if you click down and move off it doesn't activate, helps you avoid mistakes.

jasonjgw: Not sure if the scenarios we wish to cover always apply, trying to work it out. It's for people with motor difficulties, might accidentally activate things, trying to work out all these scenarios discussed are potential applications that might be addressed.
... by having the scope widen, does that help people? [enough]

Brooks: Does anyone know whether this test can be automated, or will we have to test with manual testing?

AWK: Seems like something that could be automated, but whether you can today I don't know.

<Zakim> steverep, you wanted to say this can cover low vision as well

Steverep: The prime scenario is people with motor issues, but also good for people with low vision who often tap the wrong things, e.g. drag and drop things to the wrong place.
... wording wise, just define activation differently, which is to say the completion of an activation.
... You'd have to change the glossary and understanding, not sure the SC text needs to change.

AWK: Not sure if activation is a term that's used, in pointer events it is talking about activation of elements. Maybe that would work.

Steverep: the definition defines single point, but not activation.

<AWK> Single pointer activation: completion of an operation resulting from one point of contact with the screen

AWK: Is that inline with what you're thinking?

Steverep: Then just need to think of beyond one-clicks are handled in the understanding.

Jasonjgw: that direction would be appropriate, don't want to overlap with other activations in an app/

AWK: The definition should remove that confusion?

Jasonjgw: You could include the irriversability aspect there, although I'm not advocating that.

<laura> I need to go too.

<scribe> scribe:Glenda

AWK: any concerns?

Katie: could we add language to clarify?

AWK: unless controlled by the user agent or operating system

<AWK> https://www.w3.org/WAI/GL/wiki/Comment_Summary_2-5-2#2.5.2_Accidental_Activation

+1

<Ryladog> +1 to this new bullet

Detlev: I think the definiiton is still confusing (for single pointer activation).

<Alex_> i agree this is pretty confusing text

“Definition of Single Pointer Activation: Completion of an operation resulting from one point of contact with the screen."

Alex: I get the up event part. I don’t get the “confirmation is provided” or “The activiation is confirmed”.
... thinks definition of “Single Point Activiation” is not clear

steverep: I agree with Alex that the confirmaiton part is not necessary. The whole idea is giving the user an “out” to reverse an action.

+1 to removing the “activiation is confirmed” bullet (from Glenda)

<gowerm> +1 to removed confirmation bullet

jasonjgw: conerned with “contact with the screen” language, restricts it too much to touch events.

<Detlev> scope should really include mouse, laser pointer, stylus...

<Zakim> gowerm, you wanted to say is this still the scope: Authors, when you have a single-click action, don't activate on the down-event, activate on the up event

gowerm: can we just define this as a “single click” from any type of device (finger, mouse, keyboard, stylus…"

<Detlev> @Glenda: why include keyboard? Virtual mouse clicks??

@detlev I was thinking kiosks with keypads

<Detlev> @glenda OK

Glenda: can we replace “single-pointer” activiation with “single-click”?

<steverep> -1 to click... now drag and drop is completely excluded

<gowerm> single-click is certainly more immediately understandable. is it too technology specific?

<Detlev> Sorry folks I have to drop out

<steverep> I'm happy to try and reword this and come back

<AWK> https://www.w3.org/WAI/GL/wiki/Comment_Summary_2-5-2#New_.2811.2F27.29:

AWK: Still need to work on definition for Single-Pointer Activiation. Or, is this self-defining and could be explained in Understanding?

<Ryladog> 95%

<gowerm> The notion of 'single click' should definitely be in the Understanding doc if it isn't in the definition

95% and handling the Single-Pointer Activiation in understanding

<jasonjgw> It's closer to doing what it was intended to achieve.

AWK: steve can you work on this today and we try to wrap in 15 mins tomorrow?

KimD - what about interactions where nothing touches the screen?

AWK: excluding things that are not touching

<Ryladog> S pen

Kim: things were happening when I was not touching the screen…pointer/pen close but not yet touching

<Zakim> KimD, you wanted to ask about events/interactions that happen without actually touching the screen and note testing concerns

<Zakim> steverep, you wanted to ask if using functionality instead of activation would be okay?

Kim: concerned for how we would test for this. Need to make sure it is testable.

Steve: what if we change the word “activiation” to “functionality” and then just define what we mean by “single-point”

AWK: but another proposed SC depends on this Single Point Activiaiton definition.

JF: other types of input, like speech, thermal, hand waving. Consider future proofing. What about VR?

<KimD> *Mike, your connection isn't the greatest

gowerm - assuming this was some sort of touch - pointer (not hand waving or voice or VR)

jasonjgw - what about people with tremors. need to be able to press in the wrong place, release and move to the right place.

RESOLUTION: leave open

Change of Content https://www.w3.org/WAI/GL/wiki/Comment_Summary_3-2-7

<gowerm> For content which does not take focus and which dynamically updates as a result of user action or application status changes, the following are true:

<gowerm> Changes in content are programmatically determinable through role or attributes;

<gowerm> Notification of changes to content is available to user agents, including assistive technologies.

<gowerm> Note: success, progress and error notices are examples of such content.

<gowerm> https://github.com/w3c/wcag21/issues/544

gowerm: 4.1.2 Name, role, value handles controls. But this is for items that are not a user interface control.

<AWK> Old and proposed text for the SC: https://www.w3.org/WAI/GL/wiki/Comment_Summary_3-2-7

AWK: some concerns have been voiced about an overload of notifications

gowerm: we can handle that thru techniques and understandings (roles and default verbosity) and how to use aria-live well

steverep: we want to cover things that 4.1.2 does not cover. Very helpful for conveying status. Examples: progress bars, status messages, alerts, success/failure messages. Will have very specific techniques so we won’t be creating too many notifications.

Katie: instead of programmatically identifiable, can we just move that to the second bullet
... redundacy between the two bullets

gowerm: we were patterning this after the 4.1.2 language/text

<gowerm> q_ to say 3 things covered in 4.1.2: programmatically determinable, make change, hear notifications of changes

jasonjgw: challenge, making sure the AT knows what has changed (and how important the change was). User agent will automatically know that something has changed. Programmatically determined is important.

steverep: agrees with Katie that while it seems redundant, the second bullet may make it more technology agnostic.
... for live-region, need to think about what is changing, atomic, polite, assertive

<Zakim> gowerm, you wanted to say 3 things covered in 4.1.2: programmatically determinable, make change, hear notifications of changes

<KimD> *brb, phone is dying

gowerm: Strange thing you can do - you can put aria-live on anything and have it set to off. Is that the same as aria-live not being present.
... if I put aria-live on something, the level of communication is based on the 2nd bullet, and we can explain in understanding and with tecniiques.

<AWK> For content which does not take focus and which dynamically updates as a result of user action or application status changes, notification of changes to content can be programmatically determined by user agents, including assistive technologies.

<Ryladog> I like it, might want to add MG point about notification of changes

steverep: when did we drop status?

AWK: it is in there...

<Zakim> steverep, you wanted to ask where "status" got lost?

Katie: We can’t limit this to what ARIA does today.

<Ryladog> My point was that AAPI will also most likely come to address this as well as ARIA

jasonjgw: reviewing 4.1.2, see this new SC as covering things that are not controls. And alerting AT of the level of importance of the notification.

<gowerm> Note: See 4.1.2 Name, Role, Value for considerations involving changes to the content of user interface components.

<Ryladog> So don't poinnt to ARIA contructs in this SC

<AWK> Scribe: AWK

Jason: Concerns about importance of changes and related updates

<Zakim> gowerm, you wanted to say I added a note we had in at one point to clarify the difference from 4.1.2

Gower: some interplay with "pause, Stop, Hide" also

RESOLUTION: Leave open

<JF> bye all

trackbot, end meeting

This is scribe.perl Revision: 1.152  of Date: 2017/02/06 11:04:15  
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/past it/paste it/
Default Present: AWK, Detlev, Joshue108, MikeGower, marcjohlic, SteveRepsher, Glenda, Bruce_Bailey, KimD, Brooks, kirkwood, Rachael, Katie_Haritos-Shea, Laura, Alex_Li, jasonjgw, Mike_Pluke, JF, alastairc

WARNING: Replacing previous Present list. (Old list: AWK, Joshue108, JakeAbma, KimD, MichaelC, alastairc, SteveRepsher, Makoto, JF, Detlev, Brooks, Greg_Lowney, kirkwood, Laura, Kathy, AlexLi, Glenda, Jan_McSorley, Lisa)
Use 'Present+ ... ' if you meant to add people without replacing the list,
such as: <dbooth> Present+ AWK


WARNING: Replacing previous Present list. (Old list: AWK, Detlev, Joshue108, MikeGower, marcjohlic, SteveRepsher, Glenda, Bruce_Bailey, KimD, Brooks, kirkwood, Rachael, Katie_Haritos-Shea, Laura, Alex_)
Use 'Present+ ... ' if you meant to add people without replacing the list,
such as: <dbooth> Present+ AWK, Detlev, Joshue108, MikeGower, marcjohlic, SteveRepsher, Glenda, Bruce_Bailey, KimD, Brooks, kirkwood, Rachael, Katie_Haritos-Shea, Laura

Present: AWK Detlev Joshue108 MikeGower marcjohlic SteveRepsher Glenda Bruce_Bailey KimD Brooks kirkwood Rachael Katie_Haritos-Shea Laura Alex_Li jasonjgw Mike_Pluke JF alastairc
Regrets: Makoto KathyWahlbin
Found Scribe: Jim
Found Scribe: Detlev
Inferring ScribeNick: Detlev
Found Scribe: gowerm
Inferring ScribeNick: gowerm
Found Scribe: alastairc
Inferring ScribeNick: alastairc
Found Scribe: Glenda
Inferring ScribeNick: Glenda
Found Scribe: AWK
Inferring ScribeNick: AWK
Scribes: Jim, Detlev, gowerm, alastairc, Glenda, AWK
ScribeNicks: Detlev, gowerm, alastairc, Glenda, AWK
Found Date: 27 Nov 2017
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.)