See also: IRC log
<interaccess> Timeouts
<interaccess> Minimize User errors
<interaccess> Single Key shortcut alternative
<AWK> +Joshue
<AWK> Scribe: ChrisLoiselle
<Detlev> I can try to scribe
<scribe> Scribe: ChrisLoiselle
<Alex_Li> I thought the webex pw is "ag", is it not?
<Detlev> ok - not sure I am around on that call
<Detlev> put me down for 30 may then
<Mike_Elledge> I'll do june 13th
AWK: are meeting minutes public?
<kirkwood> I can do the 20th
Josh O: surveys will be going group soon on EO Tutorials
Josh O: Comments and public comments vs. member comments. Responding to comments. Some SC managers are engaging with commentor.
More formal commenting will follow later on down the road.
<Alex_Li> i will call back
Alex L: on queue, can't hear him though. will wait on Alex
<alastairc> q
Josh O: any comments on SC managers and commenting?
AlastairC: need agreement on our response before responding to public / external commentors
<Alex_Li> i'm back
Alex L: not all comments need to be responded to, is there a general standard?
Josh O: all will need responses, but SC managers can engage with OPs and make responses they believe are appropriate. Official responses need surveys and plus ones for working group stance
AWK: working group responses vs. working draft - SC manager has the ability to respond saying we have a new way of resolving your issues.
<david-macdonald> Lisa you may be muted
Josh O: Lisa on phone?
Kathy W: there was issue with calling in.
<AWK> Updated wording proposal (from AWK): For each time limit set by the content where data entered by the user can be lost, the user is advised about the length of inactivity that generates a timeout unless any user-entered data is preserved for at least 24 hours after the timeout.
James: Use internet connection to have computer call you.
<KimD> * Me (Kim?)
Kathy W: biggest concern with embedded links, it is a user concern. pose significant challenges on interacting with content
<Lisa> I am on the call but no one can hear me
<Lisa> Will try to call in
<AWK> https://rawgit.com/w3c/wcag21/target-size_ISSUE-60/guidelines/sc/21/target-size.html
<AWK> you are muted Lisa
<Joshue108> GH summary https://github.com/w3c/wcag21/issues/60
if content reflows and links overlap, that is ok. You'd need touch target
Michael C: Content reflows can overlap...link wrapping...don't understand what is referencing.
<Detlev> is an "in" missing? i.e. "A 44x44 CSS pixel target can overlap if it is *in* an element where the links can wrap."
Kathy W: touch target can overlap. Sentence before and after, now touch target is overlapping. That is the exception.
<david-macdonald> Target: Region of the display that will accept a touch action. If a portion of a touch target that does not perform the same action or go to the same page is overlapped by another touch target such that it cannot receive touch actions, then that portion is not considered a touch target for purposes of touch target measurements unless the content can be reflowed so that the touch targets to do overlap.
Michael C: wording "where links can wrap" , touch targets can overlap...wording needs to be addressed
<Zakim> Greg, you wanted to ask for examples
Greg L: is there a live example on this regarding touch targets?
Kathy W: Link to Patrick's example
<laura> Patrick’s: example: http://codepen.io/patrickhlauke/pen/aBNREe
<Joshue108> http://codepen.io/patrickhlauke/pen/aBNREe
Detlev: Overlap would address this exception where there is inline text links. Where they are immediately next to each other. Would be better to have it overlap.
Text content wraps vs. just links, real issue is two different links which overlap. Text of SC needs to be addressed.
Kathy W: Agree wording needs to be addressed
<Zakim> AWK, you wanted to say that requiring a size that causes known problems (overlapping interactive elements, which will create confusion) is not a good idea.
<Detlev> doesnt need script for that padding!
<JF_> +1 to AWK
<gowerm> +1 still don't understand why we don't just exempt links in blocks of text
AWK: 44 x 44 is a problem when it comes to links like this. Most links would need this. This may be creating additional confusion. Clicking on one link when it is the target for another link.
<Mike_Elledge> q
Kathy W: push back from user says this is a major issue. can't resolve both sides of this argument.
<kirkwood> “when touch targets overlap due to reflow”. I think setting a size 44 pixels is an issue with zooming now on most devices. I think the pixel size shoud be dropped
Kathy W: targets are close together is the issue here.
<Detlev> I think to address Andrew's (and others') concerns we can lower the vertical value for inline targets to 22px
<KimD> +1 to AWK - potentially cannot ever support this because of text links, footnotes, etc.
Alex L: last exception can't be modified, what does that mean?
Kathy W: this was a concern based on comments
<AWK> === question about what the "cannot be modified" exemption is actually for and what an example would be
James N: Patrick came up with this technique to have larger click area than target itself. Has any testing been completed with VoiceOver? Link vs. target testing.
Kathy W: will double check that
James N: I could test (Patrick's demo).
Josh O: you can supress the notification vs. the focuc
JF: This seems like a user agent requirement. Patrick's script would have to be used everywhere. Can't mandate this script be integrated by user agent
<kirkwood> +1 to JF on not mandating a fixed size
JF: I would need to do some testing too, but one of the problems is that we are defining a 44 x 44 box, and touch target is more a circle. Linear line...square vs. circle. Box model vs. push target
Kathy W: we might have to drop this, or have someone contribute to the solution.
<AWK> === AWK volunteers to look hard at this one before Thursday
David M: in agreement, we don't know what user is using to control the link. inline links will get some pushback. suggestion would be 44 x 16
bigger target , pinching and zooming in to click on link
Josh O: Interdependency of SC
Kathy W: think we are losing the end user perspective. relying on zoom is probably not the way to go. People who are not "touching" screen, i.e. people with tremors.
<EA> +1 t what Kathy is saying
<Joshue108> +1 to Kathy also - lets not forget
<Wilco> +1 with Kathy
Mike: triple A would be applied to links, give people ability to improve links, but wouldn't require them to in AA
<david-macdonald> David responds that 44px may not be big enough for users with tremours. So we may not meet the needs of those with severe tremours only
who is speakking , Mike ?
<Detlev> +1 to what Mike Gower says
<david-macdonald> +1
Mike G: exempting text links does not wipe out benefit of this. In people with tremors, user agents and operating systems can help and we don't have to get all items in to the SC by default
Staggering criteria over a couple of levels, AA, vs AAA
<Joshue108> === Continue on Thurs
<AWK> I suggested a version that seems to address people's stated issues:
<AWK> For each time limit set by the content where data entered by the user can be lost, the user is advised about the length of inactivity that generates a timeout unless any user-entered data is preserved for at least 24 hours after the timeout.
<Joshue108> https://www.w3.org/2002/09/wbs/35422/Timeouts_Issue14/results
AWK: SC lets the user know what is coming. Doesn't go into sensitive information
Katie H-S: User should be notified "in advance" , that text needs to be re-introduced into SC
<AWK> For each time limit set by the content where data entered by the user can be lost, the user is advised in advance about the length of inactivity that generates a timeout unless any user-entered data is preserved for at least 24 hours after the timeout.
JF: concerned that language on what we voted on vs. what the language we are discussing is not matching. "In advance" should be in the SC.
<Zakim> AWK, you wanted to encourage people to not view a survey as "a vote"
Alex L: Purchase an airline ticket, and then the airline ticket is no longer there because someone else bought it? What is the time limit vs. time out?
Lisa: The user should be aware of the time limit they have to complete a task.
<david-macdonald> We could say "predetermined timeout..."
Alex L: how do you know when the tickets will be sold?
I.e. real time event vs. time out?
Lisa: Preference is user is aware that price of ticket can change , i.e. this is an estimate
Exceptions are welcome to be discussed and included.
<gowerm> "Where data can be lost due to transaction time limits or inactivity timeouts"
Alex L: it seems it is unclear on what definition of "time out" is vs. time limit. I will follow up when proposal is drafted.
<gowerm> Where data can be lost due to transaction time limits or inactivity timeouts, users are warned at the start of the process about the time limitations, unless...
AWK: intepreting this as a time
out, systematic aspect. Trying to do something, then you are
out of time. Can't proceed. I.e. phone automatically hangs up
on you in quue. Vs. interacting with a form for limited number
of tickets for a baseball game.
... Voting is not being completed right now, discussion and
surveys evolve.
<gowerm> Time Limits: Where data can be lost due to transaction time limits or inactivity timeouts, users are warned at the start of the process about the time limitations, unless...
Josh O: airline systems are complex, timeouts will need to be clearly defined. especially for this criteria. Define as time limit and generalize it vs. using the word "time out".
<kirkwood> +1 to changing to ‘time limits’
Inform the user they may be bumped out.
<AWK> For each time limit set by the content where data entered by the user can be lost, the user is advised about the length of the time limit unless any user-entered data is preserved for at least 24 hours after the limit is reached.
Mike: plus one on time limits
<Ryladog> AWK ....still missing 'in advance'
<Rachael> +1 focusing on time limits
<Greg> +1 for changing to "time limits"
<Joshue108> +1 to focus on time limits vs time outs.
<Joshue108> +1 to in advance
<Lisa> Andrew wording does not have time outs
<Lisa> So I think this is a red hearing
David M: wording of time limits is a concern. I agree with Alex. Use "pre-determined" timeouts. Let them know 15 minutes is time limit upfront.
Real time exception is also a possibility.
<AWK> For each time limit set by the content where user-entered data entered can be lost, the user is advised at the start of the process about the time limits unless any user-entered data is preserved for at least 24 hours after the limit is reached.
<Zakim> Greg, you wanted to discuss (a) length of time as well as inactivity; and (b) we postponed deciding on defining what counts as data preservation; and (c) respond to Alex that loss
Katie H-S: there are other SC that address advanced notice etc.
Greg L: first comment: time outs vs. time limits wording needs to be addressed. Second comment, the word "Preserve" , third thing was responding to Alex: Point in process of ordering tickets. Data loss may not be lost even if you were timed out.
<Zakim> steverep, you wanted to ask how different implementations of time limits would pass and also suggest removing "inactivity"
<Joshue108> +1 to removing or rewording inactivity as on mobile a user can be active but not interacting with the server
<Ryladog> I would like to see the wording we had agreed upon last week - when we were deciding to add or not sensetive data
Stephen R: "process" wording needs to be in SC. Also, "inactivity" should be removed. I.e. you have 5 minutes to do this. Is not "inactivity", it is a time limit.
<Ryladog> +1 to removing or rewording inactivity
does hitting next cause the user to be re-advised of time limit to complete in a process (5 step process), does it reset each step? or 5 minutes for whole process?
James N: airline ticket (broad example). End of a process , and user can't do what they wanted to do. I..e no longer available (finite resource).
persistence storage vs. non storage, which session is open for 24 hours? What are the consquences of small shops vs. large companies?
<Zakim> Ryladog, you wanted to ask why we are not calling it a "time limit"?
<gowerm> don't forget the security exemption discussed last time
<AWK> Last week: "Where data can be lost due to timeouts, users are warned at the start of a process about the length of inactivity that generates the timeout, unless the data is preserved for a minimum of a 24 hours of user inactivity."
<marcjohlic> +1 to Katie - this seems like it's getting too convoluted to me
Katie H-S: may be making this to hard. Need to go back to the language from last week. This is not about inactivity. It is about warning user about time limit.
<Joshue108> +1 to Katie
<Joshue108> great idea IMO
The other items can be another Success Criteria.
<gowerm> +1 to Katie. Focus on time limits, drop 24 hours.
<laura> +1 to Katie
<AWK> My edits based on comments: For each time limit set by the content where data entered by the user can be lost, the user is advised about the length of the time limit unless any user-entered data is preserved for at least 24 hours after the limit is reached.
<Greg> +1 to simplifying per Katie
<Makoto> +1 to Katie
Lisa: find things to include in main use case.
all we are asking people to do is warn the users.
Lisa is breaking up on phone call.
<Ryladog> My suggestion, lets have this one be about being wanred in advance how much time you have. Short name is: Identify Time Limit. The let have another SC if you want that is (short name) Data Saved 24 Hours. An test the outcome of that one. Then have another SC called (shoer name) Inactivity Time Limit.
Lisa: do we have enough for August deadline? We know main use cases are testable. Whatever needs to be excluded can go into an exclusion list
<david-macdonald> +1
<gowerm> How about we get a new version that incorporates feedback.
Josh O: we have to try to get as robust of a SC as we can.
<JF_> +1 to Josh.
Josh O: agreeds to Katie's points. Three simple SC that can be parsed that way
<JF_> +1 to breaking this into 3 SC
<AWK> For each time limit set by the content where data entered by the user can be lost, the user is advised about the length of the time limit unless any user-entered data is preserved for at least 24 hours after the limit is reached.
<AWK> For each time limit set by the content where data entered by the user can be lost, the user is advised about the length of the time limit at the start of the process unless any user-entered data is preserved for at least 24 hours after the limit is reached.
need to figure out on how to message time limits
Jason W: AWK raised the key issue. The relationship isn't clear between time limits under discussion and 2.2.1 , this may be very confusing.
<marcjohlic> +1 didn't we have discussions and agree that 2.2.1 and this one should match - whether that is 24 or 20 - but for both
Time limit set by content...
<AWK> I think that we discussed that the 24 and the 20 are for different things and didn't need to match.
<marcjohlic> Agree that we covered they were for separate items, but I thought folks felt it would be less confusing if they both had the same time (the preference being changing 2.2.1 to 24)
relationship needs to be addressed between these to SC
<gowerm> How about: "Where data entered by the user can be lost due to timeouts, the user is advised in advance about the length of the time limit at the start of the process. "
<steverep> How about this simplified version: "If a process has a time limit set by the content, the user is notified at the start of the process about the length and nature of the time limit."
<gowerm> Same idea as Steve: Where data entered by the user can be lost due to timeouts, the user is advised in advance about the length of the time limit.
Lisa: It is really important , as it is a big improvement. We want the user to understand they can't finish the task. I.e. can't do online, call the agent in order to complete the task.
<Ryladog> Yes to Steve, simplify this, seperate into seperate SCs
<david-macdonald> Ideally we could amend 2.2.1 Timing Adjustable: For each time limit that is set by the content, users are advised in advance and at least one of the following is true: (Level A)
it is like the submit button not working after you have been working on a task for an hour
Josh O: to Lisa, am I misreading your interpretation? No response from Lisa
<gowerm> It's complementary to 2.2.1. There is nothing in 2.2.1 that tells the user there IS a time limit until just before they reach it
Katie H-S: Let us simplify this. Have implementable SC, separate it out. It is overly complex as written currently.
it is a mistake
<marcjohlic> +1
Lisa: we have more criteria than we do time. so it woudln't go into 2.1 , timing is not possible.
RESOLUTION: Removing Resize Content #77
yes
I'll push minutes
<laura> bye
rrsagent make minutes
<Mike_Elledge> 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/katy/Kathy/ Default Present: AWK, Joshue, JakeAbma, Detlev, Mike, Elledge, kirkwood, alastairc, steverep, MikeGower, shwetank, Laura, Makoto, Katie_Haritos-Shea, KimD, Melanie_Philipp, David-macdonald, Pietro, JanMcSorley, Greg_Lowney, jasonjgw, marcjohlic WARNING: Replacing previous Present list. (Old list: AWK, Melanie_Philipp, Wilco, Rachael, LisaSeeman, jasonjgw, marcjohlic, Greg_Lowney, MikeGower, kirkwood, Laura, Kathy, KimD, Katie_Haritos-Shea, shwetank, Davidmacdonald) Use 'Present+ ... ' if you meant to add people without replacing the list, such as: <dbooth> Present+ AWK Present: AWK Joshue JakeAbma Detlev Mike Elledge kirkwood alastairc steverep MikeGower shwetank Laura Makoto Katie_Haritos-Shea KimD Melanie_Philipp David-macdonald Pietro JanMcSorley Greg_Lowney jasonjgw marcjohlic Regrets: Denis_Boudreau bruce_bailey mike_pluke Lauriat No ScribeNick specified. Guessing ScribeNick: ChrisLoiselle_ Found Scribe: ChrisLoiselle Found Scribe: ChrisLoiselle WARNING: No meeting chair found! You should specify the meeting chair like this: <dbooth> Chair: dbooth Found Date: 09 May 2017 Guessing minutes URL: http://www.w3.org/2017/05/09-ag-minutes.html People with action items: WARNING: Input appears to use implicit continuation lines. You may need the "-implicitContinuations" option.[End of scribe.perl diagnostic output]