<JF> link for webex? (The one in Andrews email says the meeting has already ended...)

<ChrisLoiselle> same here.

<laura> Same with me.

me too

<alastairc> I've emailed Josh about that, assuming he isn't looking at this yet...

<Joshue108> Hi all

<Joshue108> I've pinged Michael.

<Joshue108> About the Webex issue.

<Joshue108> Hang in there.

<Detlev> The Webex link is not working - says "The meeting has been cancelled or ended!"

<Kathy> can you tell me the webex link?

<Detlev> any idea what's going on?

<Joshue108> Its busted.

<Detlev> https://mit.webex.com/mit/j.php?MTID=m2c6416ba23424cf61cbea8b2300fcc9e

<jasonjgw> Dial-in didn't work either.

<Joshue108> Normal service will be resumed shortly..

<Joshue108> heres Tom with the weather..

<lisa> the good new is it is not just me this time who can not log in...

<Detlev> Josh you sound like you are speaking through a wet rag

<Detlev> just guessed..

TPAC schedule – Meetings are Mon/Tue (https://lists.w3.org/Archives/Public/w3c-wai-gl/2017AprJun/1137.html)

thanks

MC: meet monday and tuesday, if going for this group just monday tuesday, but stick around for ther
... technical plenary

<Joshue108> Register here https://www.w3.org/2002/09/wbs/35125/TPAC2017

MC: Wednesday is tech plenary

<Joshue108> Shedule here https://www.w3.org/2017/11/TPAC/schedule.html

MC: make travel hotel reservation as soon as possible
... travel agents suggest flight costws will be going up

Josh: any questions?

zakim: nextitem

Device Sensors/User Interface Component Contrast (Minimum): https://www.w3.org/2002/09/wbs/35422/Top3_18Apr2017/results

Josh: user interface component

<Kathy> Summary is that people feel this is already covered by 2.1.1 keyboard. However the exceptions for 2.1.1 don’t have exceptions that are needed. Also we really want to seek access with not just a keyboard but also with a non-device sensor control like an on-screen accessible button so the sensory actions can be used without requiring a keyboard interface

Kathy: give update in IRC

<Kathy> (to avoid limitations on mobile with bringing a physical keyboard as on-screen keyboards can’t be brought up in some situations and may not even pass keys through.).

Kathy: wanted to get group together most feel coverecd under 2.1.1. There is some things that don’t quite fit under excetions
... do we retire or go into silver
... or in 2.1.1

Josh: interesting discussion, all for covering. if we feel primarily covered 2.1.1 or defined for silver or put in as an exception

Kathy: i think it adds clarity, its prett simple but could go either way

Detlev: some of cases might be difficult to bring up virtual keyboard and anthintg triggered by device sensors such as shaking device. don’t know what extent device sensor input for alternative fallback. in case of shaking device. think its fairly straight forware
... in favor of including

Jason: does fall under 2.1.1 if not keyboard operable than does fall under 2.1.1 secondly put appropriate example in understanding document to tillustrate solution

<Kathy> we also have one for pointers

Jason: someone suggested what really want keyboard operable but touch or pointer issue. So desire to have SC requires operation to be availabel via pointing and keyboard. I think proposal doesn’t have anything to do with device sensors
... i’d be saying -1

Detlev: implicit assumption that everything would be pointer accessible which is not necesssarily the case now. May work with virtual keyboard but do think particular use case for mobile device where difine a certain class of devices such as kiosk or mobile. Could be cases with specific device want to meet WCAG so I do think there is a scase for it

<Greg> De6tlev, keep in mind that keyboard interface includes emulators such as speech recognition.

Josh: think this device sensors is filling the gap for that seems what people getting at. I would be in favor of including this

Alex: i want to make the case this really overlaps with 2.1.1 except for the path of users movement
... largely the path is about the pointing device, now that is different
... there is a lot of options we want to expand beyond user movement
... could be about voice or ambient noise

Alex; all we have to do is incorpoorate that so not just pointing device scenerio

Josh: are you in favor?

<Greg> +1 to keep just 2.1.1 but expand exceptions

Alex; i think it would be inelegent and too clunky best to edit 2.1.1 to incorporate other scenerios

Jason: it there needs to be an expasion of excemption in 2.1.1

<Detlev> OK, fair point, Jason

Jason: can’t reley on keyboard interface. intended to encompass speech recognition and varios input devices. even though argued keyboard input. I’m cautiously interested in proposal in exception to 2.1.1 don’t requite additional SC

MG: looking for guidance

<gowerm> In addition to its predominant mode of operation, all functionality of the content is operable through a keyboard interface without requiring specific timings for individual keystrokes, except where either the underlying function requires input that cannot reasonably be controlled or approximated by a keyboard, or providing a keyboard alternative would invalidate the input.

MG: understood support incorpporated in 2.1.1 I support based on what pasting into thread now
... looking for guidance. release as draft SC?

Josh: we may decide to modify 2.1.1 rahter than having two competing ones and potential for confusion

<Zakim> Greg, you wanted to give sample revised 2.1.1

Josh: if reasonable case for editinng 2.1.1 will consider

<Greg> In the main 2.1.1 still applies in full, but does need an a broader or additional exception: (on mobile devices and elsewhere) software should (still) support full operation via attached keyboards and keyboard emulators, and therefore should not require other forms of input except *where they are fundamental to the purpose of the application* (e.g. an electronic level, a biometric key, or a...

<Greg> ...GPS-focused application).

Greg: an electronic level would therefore fit under expanded exceptions. That would take care of it. As a whole offering support expanded exception

<Detlev> I accept it will be better to modify 2.1.1

Greg: not in favor. the proposed SC is entirely redundant and should not be added
... however it was valuable that pointed oout flaw is expetoinss are too narrow causing some papolication to fail. should correct 2.1.1 along lines of my wording tha incoroporated excetion
... modify 2.1.1 with exceptions

<JF> +1 to Kathy - no changes to existing SC

Kathy: do want to make sure all clear change 2.1.1 that we will not be changing any of existing SC. this ould be going against that

<wayne> q

<Wilco> +1, no changes to existing SCs

Josh: where we sit where there is somehting to change rather than intorducing more ocnfusion. it makes more sense to modify WCAG if only slightly

<JF> ack +++

Josh: rather have simpler rather than not makeing a change

<Zakim> MichaelC, you wanted to say the declared path is to not modify existing SC right now, but to put in new SC and later decide whether to harmonize

<gowerm> https://github.com/w3c/wcag21/issues/67#issuecomment-280167748

MC: we will not modify for not. put everything as new SC now. Then in august will do a pass and considre coming new SC with existing if possible
... path accept this SC with not as modification, but to do it now would introduce confusion

<Joshue108> https://getpocket.com/a/read/1334449404

<Joshue108> https://www.w3.org/WAI/GL/wiki/WCAG_2.1_timeline

MC: we will consider when time comes but now is not tiem

<wayne> +1 Josh

Josh: do appreciate creates certian cognitive dissonance this creat more confusion

<lisa> BTW please not the time

Jason: along those lines, think best would be to put text under 2.1.1 to thos excetptions
... along those lines, think best would be to put text under 2.1.1 to those exceptions. Is this the right place to do it could belong in multiple places. probably an issue under 2.1.1 may require us to boraden scope to include biometirci devices

<Greg> Jason, my suggestion about biometric sensors was that they'd be allowed without keyboard interface equivalent only when it was the primary purpose of the application. Thus a dedicated retinal key application would be allowed, but a general-purpose application would have to provide other alternatives.

JF: echo concerns that Michael raised with changing existing SC. Is adding exceptions the path forward. Now is not time to have discussion

<alastairc> I think the key was that a site passing 2.1 should also pass 2.0. Adjusting SCs is possible so long as nothing is dropped into a new gap.

Josh: slight changes do see need frankly ot potentially modify it

LS: small changes in existing SC such as timed events maybe changing it would be simpler way of doing it
... the SC if we are open to changing things some of the COGA things could be done

<JF> A VERY STRONG +1 to Michael

<Greg> Alistair, I disagree: we should be allowed to loosen requirements in 2.1 such that applications pass even though they fail 2.0. The proposed expanded exception to SC 2.1.1 would be an example.

<gowerm> +1 to Editor's note. Can we vote on that?

<Zakim> MichaelC, you wanted to say not modifying existing SC means not modifying existing SC; proposed modifications should be stored as an ednote in the new SC and to repeat repetitively

MC: if things that warrant it we should do it, but we can put an end note as a candidate 2.1.1 discussing modifying SC takes off track

<Makoto> +1 to Michael

<Zakim> Greg, you wanted to note that adding the new SC will not allow applications failing 2.1.1 due to the too-narrow exception to pass. The expanded exception to 2.1.1 is thus

Josh: look at SC on own merit

<Zakim> steverep, you wanted to say device sensors is not specific at all and needs to become a positive condition

Greg: the qustion of adding a new SC shoud be independent. Adding a new SC would not epanding what would pass. we should modify 2.1.1

Josh: lets keep to SC

<Zakim> MichaelC, you wanted to say we can use ednotes to talk about potential impact on existing SC

SR: need to make merge obvisous. if this is covered inexception would like to see rewritten. I’m confused about device sensor to begin with. doesn’t say addtional to what. this is not looking forward. turn arond to poistive to tell authors what to do

<lisa> +1 to michael it is to late now to say rewrit it from scartch .

<gowerm> +1

MC: rather than rewriting the SC should

<Kathy> +1

<lisa> +1

<marcjohlic> +1 to MC and ed note

<Joshue108> +1

<JakeAbma> +1

<wayne> +1

<Glenda> +1 to MC and ed note

<steverep> -1

<ChrisLoiselle> +1

<Detlev> +1

MC: look at SC on own merit

<laura> +1

+1

<gowerm> +1 Editor's note. i made a slight editorial suggestion.

<Greg> +1 I can live with that

<Makoto> +1

<JF> +0 I'm on the fnece but won't stop forward movement at this time

<Mike_Pluke> +1

RESOLUTION: Device Sensors - Accept this SC into editors draft and include an Editor note to say that the preference of the group is to alter an existing SC rather than add a new one.

<alastairc> 0 - I'm think the SC would change significantly if editing 2.1.1 were possible. Just needs to be a bookmark at the moment.

Josh: i will put SC after call

<JF> sorry, +1 to that resolution, modified from my previous +0...

Josh: going to look at user interface

User Interface Component Contrast

<Glenda> https://rawgit.com/w3c/wcag21/user-interface-component-contrast-minimum_ISSUE-10/guidelines/sc/21/user-interface-component-contrast-minimum.html

Glenda: had great discussion last week I simplified wording and made reference in notes. have under consideration to mimize color contrast. I think i have addressed everyones’’ concerns. Jason had somehting in survey are you comfortatble?

<steverep> Examples of what isn't clear?

Jason: clarity about what it covers would be valuable. what the indicators are tthat need to meet contrast requirments. if this is to be merged into graphic contrast requirments are formulated.weither need to refine this further depends on plans to merge into something else not in position to speculate. clearer deliniation of what is covered is a core part of proposl. reviewer might find it will ocer things it should cover other items. like to see greater c[CUT]

<Glenda> I have added this note, and ask that we allow this to move to the draft:

<Glenda> Examples of essential visual indicators of user interface components may include (a border, edge, or icon), current value (such as non-text visual indication of aria-valuenow on a slider) and current state (such as selection indicator, focus indicator) or other essential visual indication (which do not rely on color alone).

Jason: issue raise it sufficient if visula identifiers indicate there is a user interface component it would be sufficient
... state and roll using language of 4.1.2 being a bit clearer about what is to be covered here. it should be visually clear about state and control. wnat clarity of exatly what they are covering

<alastairc> https://rawgit.com/w3c/wcag21/user-interface-component-contrast-minimum_ISSUE-10/guidelines/sc/21/user-interface-component-contrast-minimum.html

Glenda; based on your great feedback make very clear on visual indicator of states or even a valus if essential for understanding. have addressed since thursday of last week

Jason: it depends what you want to do when merging with graphics requirements

Kathy: that is why it is a note for understanding trather than clossary term. Under consideration to combine and happy to add that note.

<alastairc> glenda - you have a few notes, I'll add that to issue 9's

Jason: if that is done, thats a good thing

Kathy: that is the one descion and will do it rithgt now

Josh: to be clear, it seems to be fairly clear

Kathy: Jsons comments were very helpful

Lisa: if people want to see as a glossary instead of note, those should be discussed after this. That kind of detail i think we can do after august

<Zakim> steverep, you wanted to say that state information cannot be included here because that's about much more than contrast

Steverep: doesn’t cover contrast between differnet staters. agree with Glenda does cover all states. Can’t cover contrast between different states. checkbox with check and without as an example. in any state control needs to have good contreat

<allanj> +1 steve

AC: regarding the SC, i will have another go, through expternal feedback, i will have a look

<Zakim> MichaelC, you wanted to say ednotes ednotes ednotes!

<gowerm> Alastair, you could just make another editor's note about potential for combination is under consideration

MC: regarding what Lisa clarity can be addressed with editorial notes
... same might apply to proposal combibne tow propspo

<Glenda> Just added this note: Under consideration: will review to see if it is possible to combine with proposed WCAG 2.1 SC 1.4.11 Graphics Contrast.

Josh: this a good SC and happy way we are going

MG: don’t think s3edcond bullet is necessary minor editorial

<Glenda> I’ll make that change, thanks

<Detlev> +1

<laura> +1

<alastairc> +1

+1

<Joshue108> +1

<Glenda> +1

<gowerm> +1

<lisa> +1

<steverep> +1

<Wilco> +1

<Makoto> +1

<JF> +1

<ChrisLoiselle> +1

<lisa> (or +2)

<JakeAbma> +1

Josh: we have a resolution

<Greg> +1

<Pietro> +1

RESOLUTION: Accepted User Interface Component Contrast (Minimum) #10 into editors draft.

<allanj> +1

EOWG 'Accessible Media Tutorial' (https://www.w3.org/2002/09/wbs/35422/2017-06_wai-media-intro/results)

Accessible Authentication: https://www.w3.org/2002/09/wbs/35422/COGA_Auth/results

thanks!

LS: there’s some small changes to wording added exceptions from JF if there is a legal requirment
... we also with word of amiguity, did a bit of rewrite that you can reset your password that would do it
... the other big topic was input from security issue and got input from people with dsecurity and wbe authentification unit, and cyber-crimes unit in Isreal (?). very aware will write to Web authentification group. authors =were opinged, if Josh and Andrew want to pick on up
... aksed if there is any security issue. lets move forward pending seeing outstanding concerns
... people may not have been aware of how many were consulted. for exmaple remembering passwords was not included
... assuming we get feedback we shold be able to get more input

Josh: great on feedback

Alastair: there is only one option abstraction biometircs and usb keys concerns was from w website owner =what are the oponts

<Glenda> FIDO = Fast Identiy Online https://en.wikipedia.org/wiki/FIDO_Alliance

Alastair: something built into or attached to device lika a usb key with button public private encryption system. rather than remembering a password. does mean for puropse of SC than people would have to use it

LS: diffent soltions for different site. could choose to login with facebook as an laternative which is a simpe way of dealing with it
... whats wrong with saying send an SMS that is a two factor system

AC: i’d be surporised about a link and SMS can be bad too

LS: smartcard, credentials, buy a smartcard from bank if you prefer

AC: from Website view is all the same thing

<Joshue108> But are we saying this SC requires hardware?

AC: not objecting where you don’t need two factor, that case third party or email loop fine. but for more s3ecurity apart from dvide based way of doing it

LS: sending a token is more reliable

AC: google has google authenticator system

<Zakim> Joshue, you wanted to ask about what are the example of positive patterns or techniques that satisfy this?

LS: the APE is going very soon before we are, we’d be blocking authentication more advanced than ours

Josh: one we can’t say we need hardware to satisfy a criteria. Two example positive patern matching techniques would that satisfy this?

LS: yes it would
... this APE puts responsibility on user

Josh: is there a user requirment for this?

LS: through the API the webist can select

<Zakim> Greg, you wanted to ask Lisa whether the legal requirements exception means that a page/app would conform with 2.1 in some countries but not in others. Is that already true?

<alastairc> Note, the user's key can be used across multiple sites. Not that expensive, e.g. https://www.amazon.co.uk/d/5fn/Yubico-Y-123-FIDO-U2F-Security-Key/B00NLKA0D8/ is < $25

webist/website

<Greg> Lisa, would the legal requirements exception means that a page/app would conform with 2.1 in some countries but not in others. Is that already true? Do/will conformance claims wil to list the legal jurisdictions under which the claim applies?

Greg: if you are adding excetions for location. Conformace in one country or another?

LS: you had to conform within each country, a very good point need to tweek wording
... it was an exception John asked for

JF: i didn’t request an exception. specificlly i put link in github about multifactor authintication. in those cased must meet law about two fact

<Greg> I do consider it problematic if WCAG 2.1 can be significantly changed world-wide by any one country changing their internal legislation.

fact/factor

JF: we are all struggling with passords, regarding choosing its not really a choice. Want to be really careful about requirments

Josh: does tie into the whole captcha isue

JF: there is low hanging fruit in low securty might be helpful.
... high security authitication methods will always be there

<KimDirks> +1 to JF

MG: I am surprised about copy and transcribe? by having it the way it is in here takes out copy paste. copy is really problamtic here. if you are trying to retype things

<KimDirks> * security is huge in Legal world and often demanded by customers who may be a federal agency such as IRS or Homeland Security

LS: i agree better word like transcribe might be better

<Mike_Pluke> +1 to MG

<Glenda> +1 to what gowerm is saying. I could support removing “copying” from this SC. Then this could be a good positive movement in the right direction.

LS: we will find a better word

<Zakim> MichaelC, you wanted to say ¨mom and pop¨ shops also have to be able to realistically conform and to say hardware could be an allowed technique, but I wouldn´t want to rely on

<Joshue108> +1 to Mike gower

MC: one point hope not forgetting must be possible for mom and pop sites to meet requirments. perhaps email reset for mom and pops should be done. do think hardware should be allowed but not dependent on it
... regarding cpatcha and authetication are different probles. one is you are you and the other is you are human. need to look separately.

<Joshue108> Thanks for that MIchael - authentication is different from CAPTCHA type issues.

MC: the best way is to have SC in fromal working draft so people can comment in public review

<alastairc> I think it is important that a security review includes what we think the sufficient techniques are for websites, both simple and those with higher security requirements.

Wayne: assitive technolgy that works on one site and doesn’t work on another. got to have multiple tech for sites. The visual thing unlike language there is no logical way such as L adn ! and 0 and O. in a situation where you have to retype a password and you have to guess. this is where it is really important right now

Glenda: if copying were removed very uncomforatble not allowing copying and pasting

LS: i can put it in now
... no one is requiring to depend on hardware. even mom and pop they just need to call the api and they have conformed

<alastairc> But the API does require the user have certain hardware

LS: places that need security wether biometric use api can use most secure handprints like in airport

<gowerm> replace the word "copying" with "transcribing"

<wayne> +1 put in the Editors Draft

Josh: i’d like ot see this go in

<lisa> with the word transcribe

<alastairc> +1, and a note for people worrying about the security, please see my survey response: https://www.w3.org/2002/09/wbs/35422/COGA_Auth/results

Josh: put +1 if you’d like to see this go in

<Glenda> +1 (with the word copy replaced with transcribe)

<gowerm> +1

<Joshue108> +1

+1

<Kathy> +1 with changes discussed

<Detlev> +1 t oget more comments

<laura> +1 (with the word copy replaced with transcribe)

<lisa> +1

<JakeAbma> +1

Josh: let us know what you think

<Pietro> +1

<KimDirks> +0

<ChrisLoiselle> +1

<Makoto> +1

<wayne> Consider a password Il15S8BO0

Josh: think we have a resoltion

<Detlev> I have to leave

<marcjohlic> +1

RESOLUTION: Accepted into Working draft accessible authentication #23

<Joshue108> trackbot, end meeting

<laura> bye

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/questi9ons/questions/
Succeeded: s/in favor of excluding/in favor of including/
Succeeded: s/sipmolified/simplified/
Succeeded: s/cyber rimes unit in australie/cyber-crimes unit in Isreal/
Default Present: AWK, JF, ChrisLoiselle, Detlev, Rachael, Greg_Lowney, Joshue108, Glenda, MikeGower, steverep, Laura, jasonjgw, alastairc, allanj, Kathy, shadi, lisa, Kim, JakeAbma, Wilco, kirkwood, Makoto, jeanne, KimDirks, MichaelC, Pietro, Mike_Pluke, marcjohlic
Present: AWK JF ChrisLoiselle Detlev Rachael Greg_Lowney Joshue108 Glenda MikeGower steverep Laura jasonjgw alastairc allanj Kathy shadi lisa Kim JakeAbma Wilco Makoto jeanne KimDirks MichaelC Pietro Mike_Pluke marcjohlic
No ScribeNick specified.  Guessing ScribeNick: kirkwood
Inferring Scribes: kirkwood
Found Date: 20 Jun 2017
Guessing minutes URL: http://www.w3.org/2017/06/20-ag-minutes.html
People with action items: 

WARNING: Input appears to use implicit continuation lines.
You may need the "-implicitContinuations" option.