<Detlev> scribe: Detlev
Lisa: asking about moving list in definition
Andrew: will be covered in item 2
Michael: should be done in a separate branch
AWK: 12 peope say its ready to go, 11 would accept it with a note
JF: concerns about timeouts - whether info is preserved is not always under control of the author
... if user gets interrupted, nothing is saved, contne only in browser cache, the author cannot capture those data
Lisa: the understanding section should point out it is server-side content
JF: Yes but cannot be imposed on the author
... auto-save would be desirable but cannot be mandated
... if server disconnects, the content won't be preserved
Lisa: Can't we warn the user?
JF: that requirement exists already
Lisa: that doesn't help coga users because trhey often need mote than 20 seconds to parse that info
... excludes people with reading disability, and those peope that need to take a break
... that is what this SC should solve, possibly at level AAA
JF: if the issue is that the warning is not long enough, but that is another issue
... the concern here is advance warning
Lisa: the problem is different when warning pops up and there is too little time
... there were other ideas lie being able to retutrn to data to change them, so this was a minimum requirement to give advance warnings if data can be lost
JF: so the aspect of generated warnings is out of scope here - but also the time of 24 hrs would need users to press save even if they are not done yet
... Gives Google search input example - input won't be saved unless users initiate that process
<lisa> i think we handel that in understanding
alastairc:
Whenever you are not logged in you would provide info on timeout
<lisa> this is AAA
alastairc: so it would be advance warnings in forms unless the user is logged in
AWK: because form could remember info when logged in?
alastairc: like * = required there could be info like "This form will time out in 30 mins"
David: So unless you preserve data, warn users - sounds like a AAA, public will comment on it
<Zakim> KimD, you wanted to ask for the definition of "form"
KimD: What is the definition of forms? Includes single field entry?
... second point: different timeouts for different customers - a product may timeout in an hour - so the customers have timeout and you may not know in advance, difficult to achieve
AWK: a definition for form seems to be missing
<alastairc> It doesn't say form, says data that can be lost...
Jason: On KimDs last point: form may not be the right term - web search could use a custom aria-enhanced control - it may or may not be a form
... unclear when the start of the process actually is - even before login?
... regarding JFs point: when someone completes a form the client needs to send parial data to the server, it's possible, but that needs to be in place
<lisa> can we add "or the process has less then 4 data fields completed."
Jason: in multi-stage forms you may commit one chunk of info at a time
... so scope of proposal is difficult and need sorted out
JF: structure for data retention is possible but do we require authors to put that in place (like auto-save)? That would be a heavy requirement
<alastairc> not saved, but not timed-out either
browser can only do it if that behaviour is scripted
(JF)
JF: happy with first half of the proposal - the OR is not achievable - may be just shorten to first half?
Lisa: original wording was 'where data can be lost due to timeout' - talking about content timeout might clarify
... another qualification would be number of four data fields, so you would have to save or press next after 4 fields
JF: this means requiring save but don't submit functionality from authors
Lisa: this is a AAA requirement and it's testable - not anyone has to do it but it would be a recommendation
Denis: confirms JF concerns
... first part of SC would be enough - because we have timing ajustable, thi swould be enough to address the concern
Lisa: disagrees - here you have to give a warning to users, which goes beyond
<lisa> exactly
<lisa> we can handle that in the understading
alastairc: in simple cases (one step forms) is not timed out so the SC does not apply to simpe cases
... but helpful in complex cases - you don't want to warn people in cases when app saves data automatically like Google docs
<Zakim> alastairc, you wanted to say this doesn't apply to simple forms.
alastairc: data can't time out if it is not submitted, it may still be in the browser
<lisa> should we add the words "in multi step process"
David: The second part is an option if you don't meet the first part (advance warning)
JF: the only way the content author can preserve data if the user has given it to the author
Lisa: it specifies that this is a tiemout due to inactivity
<chriscm> Sorry everyone, have to drop early today.
JF: cases where user logs in (bank app) if I get disrupted the data will be lost
alastairc: the bank could place a warning at the top of the from, or save input on blur
Lisa: Best case is where authors are clever and save input data - then you don't need the warning - so there is no advantage in keeping second half
<alastairc> All of John's objections made me think it was quite well worded now ;-)
<alastairc> JF - https://stackoverflow.com/questions/931252/ajax-autosave-functionality
<AWK> Add a note: The Working Group discussed including an alternative within this success criterion to allow authors to avoid providing a warning. The WG is interested in feedback regarding the feasibility of saving user data prior to it being explicitly submitted and whether such an option could be included.
AWK: objections to consider - we can add a note "WG discussed an alternative.."
<alastairc> That makes the complex case (e.g. google docs) much more difficult
AWK: there could be an opposite way of putting in a note
alastairc: would prefer a note that we are looking for feedback
Lisa: agrees that the note should express that we are looking for feedback
Alex: you need user consent for that and may not be able to get that consent
... the warning is fine, the other option of 20/24 hrs preservation would need warning
... users need to consent
Lis: that could go into the understanding section
<KimD> +1 to privacy issues - some countries are strict, I believe
AWK: should that requirement for consent be worked into the SC?
Alex: Better if it is
AWK: explains Microsoft option to handle the SC
Alex: in a form, you may not know who the user is, where he or she is based
... note about privacy concerns, violations in many jurisdictions
AWK: Alex, suggest text?
MichaelC: content with a note for now
<JF> +1 to horizontal reviews: Privacy, Security, Internationalization
AWK: Rachel's comments seems to have been addressed in latest versions
... concerns center around second part of the SC - preserving user-entered data
... while simpler forms might just have a warning of timeout
... do people agree to put in the note addressing Alex' concern about privacy and ask public for feedback?
<dboudreau> I think it's ready for external review
<alastairc> I suggested: "The working group are interested in any examples of where a timeout cannot be included in a warning before a process is started."
AWK: Alex will draft note text
<MichaelC> ackme
AWK: should taken up again on Thursday - is that OK?
<Joshue108> +1
+1
<Kathy> +1
<marcjohlic> +1
MichaelC make content ready before putting out to CfC
<alastairc> +1
<lisa> +1
<dboudreau> +1
<Rachael> +1
AWK: enough to put it out with concept of notes without text being quite ready?
Jake: if we out it out as AAA why not put 20 secs requirement together with advanc warning (?)
<alastairc> Long term, would be good to have as a bullet under Timing adjustable.
Jake: 20 seconds has been taken out, so if we create the SC, why not out in the extending part as well?
AWK: timeout does not cover 20 secs requirements
Jake: it was mentioned in original wording
Lisa: has been changed since
<AWK> https://rawgit.com/w3c/wcag21/timeouts_ISSUE-14/guidelines/#timeouts
AWK: Reminder: The text in the issue in Github is not the current version - you find it in the link that says "current version"
Josh: will it go straight to Cfc on Thursday?
RESOLUTION: Accepted to editors draft with the addition of a note on user consent and editors note
<laura> Scribe: Laura
<MichaelC> Purpose of controls SC moving lists to definition: http://rawgit.com/w3c/wcag21/purpose-of-controls_MC1/guidelines/#purpose-of-controls
<MichaelC> Purpose of controls SC moving lists to three definitions, with SC rewording to accomodate: http://rawgit.com/w3c/wcag21/purpose-of-controls_MC2/guidelines/#purpose-of-controls
<lisa> press refresh then it works
MichaelC: Has worked on moving lists to definitions
second one split into 3 terms
either are okay with me.
AWK: One of the CFC failed. Other two passed.
as of now this one is not goining into the draft.
MichaelC has proposed text to help.
we are looking for feedback.
MichaelC: either proposal would remove my objection.
JF: we are not really asking for personalization anymore.
<AWK> AWK notes that the SC name is "Purpose of Controls" currently
terminlogy is interfering
is this lost to time?
AWAK: we have some time today.
<lisa> I would go for item two
<lisa> option 2
<lisa> ie diffrent lists
MichaelC: we have a new SC. Lets not get tied up in past discussion.
JF: seems to be a disconnect.
AWK: Do the proposals this address peoples concerns?
Denis: Okay with MCs proposals.
kathy had a concern that hasnt been addressed.
JF: At AAA it is in English.
It is just like label. It is not language depeendent at AA.
Lisa: could use RDF.
machine readable. Could use any language.
<JF> The list of critical controls and inputs is simply a list, that can be translated into any language
it is an attributre value.
AWK: could add a note to make interantionalzation part clear.
MG: Question on what is being proposed.
AWK: explains.
MG: Concern sitll exists. We are taking about normative language.
last time looked at list, it wasnt ready.
have those things been addressed?
MC: long list is still there. Trying to get it into the spec.
By CR long list shouldnt be there. Want to try to solve it over the next few months.
<lisa> yes they would be fine
Detlev: not sure what to tell non-english people how to implement this SC.
nothing to give immediate benefit.
JF: Moving forward we need to introduce metadata to the community.
list can be in any language.
machine readable is more powerful.
lot of ways to add the metadata.
fix list to state with.
detlev: for a simple form what does a German author need to do?
JF: can use prose or RFDa
<lisa> I always messed up the spelling of elizabth
<lisa> lisa was easier for a dyslexic
AWK: If form uses a label will that work?
detlev: seems like a terribile blow.
<lisa> i would say first name is clear enoguh
<lisa> but we should sort out techneques
AC: We are talking about SC text and list of things.
case of progamatically identified.. Token & desscription.
David: Ive seen both sides. Would like to get something in.
lay the foundation for personization.
if the list was 15 it may be more palatable for people. Ac name should pass.
lisa: agrees with david.
can conform with auto correct.
it is an argument for techniques.
hearing that we want less terms.
<JF> <label for="foo" property="name">Prnom</label> <input type="text" id="foo">
JF: pasted code into IRC.
... we would like to see the use of metadata.
<alastairc> I'm in favour of metadata scoped with a small set of items, scope it down that way.
<dboudreau> +1 to metadata as well
James: not clear of what is being asked. And the purpose.
Lisa: lisa explains what is in the list. She will work on the list.
<Zakim> JF, you wanted to say that again, this isn't just the Accessible name, it is more than that
James: need to clarify the list of metadata.
<Detlev> -q
awk: hearing concerns about the list.
<alastairc> AWK: you could if there are any objections to the SC text, or is it just the list, and are people ok with dealing with that after august?
<alastairc> sorry: you could ask...
<Zakim> AWK, you wanted to ask if we are willing to expose for external feedback.
<david-macdonald> +1 with at risk note
is there enough support for the concept to send out for external feedback?
can anyone not support it.
<KimD> -1
Mike: it is embarrassing as is.
detlev: may be helpfut to some. but others may not. perfer not to send out.
<Detlev> +0
Kim: concerned from policy perspective.
Don't understand why we need to have all of this extra code.
<Zakim> JF, you wanted to ask if the line between "prose information" and metadata a bright line? Do we reduce this down to simplky metadata?
AWK: may be part an editors note.
<lisa> we need to be carful with calling that out
JF: AA allows for prose info.
do we remove that?
lisa: or semantics.
<JF> "focusing attention" is one of the critical goals to me at this time
josh: likes the restricted list. approach
<JF> +1 to Alastair's idea "this is the largest list, but expect it to be whittled down"
AC: maybe in the note say that the list is the longest that we would require.
<Alex> +q
it is a chicken and egg situation.
Lisa: We need to be careful resticting this SC from sites.
we have to be careful.
awk: aggrees with Lisa.
alexa: multiple ways to fulfill the SC. Concerned about cost/benefits.
alex: how do people take advantge?
JF: Schema.org is a good example
tools will look for fixed values.
something is provided to the input.
metadata is the benefit.
we are dealing with chcken / egg situation.
once we get metadata then we can stat looking at tooling.
Alex: cost/benefit changes a lot once we require this in WCAG.
JF: solution is metadata.
yes there is cost.
alex: huge cost.
AC: UA cant do this on is own.
lisa: huge benefit from existing lists.
awk: concerns about applicability to all sites, list, costs.
do we want to get external feedback?
does anyone object.
<alastairc> I think we should include, can we get permission to iterate on the list quickly though?
Kim: cant support without exception.
<Rachael> +1 alastair.
awk: even with a note?
kim: that helps a lot.
less concern with a note.
<alastairc> +1 to James, many SC could be called out to not apply to particular sites.
James: doesnt like the note approach.
<JF> +1 to James
awk: perhaps generalized note?
James: that is more reasonable.
MG: can live with it but worried about level scrutiny this SC has had.
David: If shut it down it will be a long time until we can get it in.
<JF> +1 to David - we still need to tighten this up and time is not our friend here
JF: we needed to rethink a lot of this. we cant lose this opporunity ti get it in.
awk: anyone object to CFC?
<JF> +1 to a second round of CfC
<alastairc> prefer one def, three categories.
<alastairc> not concerned either way
<interaccess> thanks for scribing Detlev and Laura
RESOLUTION: Accepted as amended with MCs mc2 branch.