<AWK> trackbot, start meeting

<trackbot> Meeting: Accessibility Guidelines Working Group Teleconference

<trackbot> Date: 04 May 2017

<AWK> Chair: Joshue

<AWK> +AWK

<scribe> scribe: Rachael

Timeouts: https://www.w3.org/2002/09/wbs/35422/Timeouts_Issue14/results

<AWK> Current version: https://rawgit.com/w3c/wcag21/timeouts_ISSUE-14/guidelines/#timeouts

Joshue108: What are substantive issues from Tuesday?

Joshue: If you can, update your comments if they have changed.

Katie: Its good to go as it is.

<david-macdonald> 1+

<AWK> Split view of the changes made: https://github.com/w3c/wcag21/commit/391d41bd1451675d9cc1c1ac706220db44eba308?diff=split

Lisa: We addressed a lot of the issues from the last call. Of the No's, I'm not sure which are relevant other than Jason's.

<Ryladog> New Re-write: 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.

Lisa: The current comments are about previous wordings.

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

Joshue: We can bypass that for now by asking people if they have concerns with current wording. So based on current wording (see link), take a look and put +1 or -1. Let us know what you want to discuss.

<Ryladog> +1 to the new wording, I am happy

<marcjohlic> +.98 (would really like to clear up the 20 vs 24 thing quickly)

<Zakim> Greg, you wanted to discuss my survey comments

<david-macdonald> how is a user warned?

Greg: This takes care of inconsistency of data. There was of what is data being preserved for 24 hours. Are logs sufficent if user can't access that data?

<Greg> Some people might argue that submitted data is preserved if it's stored in a transaction log, even if the user can't access it when they resume their task. That would certainly not be in the spirit of the rule, but might technically qualify. (This is akin to the argument that when companies delete personal data at a user's request, they should also be forced to delete it from all the backup...

<Greg> ...media--which may be much harder.)

Is that a concern?

<david-macdonald> Would probably go with 20 hours to avoid tons of questions of 20 in 2.2.1 vs 24

Lisa: The original wording clarified it better. We can include intent in the about section.

<AWK> change "is preserved" to "can be retrieved by the user"?

Lisa: I am happy to clarify it in the wording or techniques. Up to the group.

<david-macdonald> do we need an exception for security concerns?

<Greg> Should an exception be added for sensitive data, such as passwords and credit card information? For security reasons these are often not saved and the user is forced to re-enter them. However, it may not be worth adding language given that we want to encourage sites to warn about timeouts.

Gerg: Do we need to add exceptions for credit card data and sensitive information?

Jason: I added concerns to the survey that need to be investigated at some point.

Lisa: One question: Is this going to be helpful? Answer, is yes, it would be extremely useful. This version is limited but we do think it will be helpful for people. It will help wasting time.

<kirkwood> +1 to lisa

<marcjohlic> will "form data" help clarify?

Lisa: I'm comfortable with it but open to suggestions of clarifying it.

<marcjohlic> "user entered data" (it's not "submitted" yet )

Kim: Is the new language replacing what is in github right now?

Lisa: Yes

Marc: Would having form data and user entered data help clarify this? Second point: 20 vs 24 hours. I think everyone agrees 24 hours makes sense but 2.2.1 is 20 hours. Can we update 2.2.1 to 24 hours since that time frame seems to make sense?

Joshue: Yes and yes. I agree that there should be some unity.

<Ryladog> +1 to adding insensetive data exception

<Ryladog> +1 to adding sensitive data exception

<Zakim> Joshue, you wanted to ask about the difference between client and server side activity.

<LisaSeeman> can we clarify that in the write up?

Rachael: Should we address situations where sites time out at a specified time as well as timeout by inactivity.

Lisa: yes it should be covered.

<Greg> I agree; that's related to my similar survey comment: I recommend it say "length of time or inactivity", as both causes of timeout can be equally detrimental for people who work very slowly. Perhaps that should add specific times as well. Although that's not technically a timeout.

<AWK> -1 on covering the 9pm-type timeout

Joshue: We need to explore that more. I'm running into situations where timeout is basedon server call vs. user inactivity. Is that covered here? Should it be?

Lisa: It should likely be addressed here. Can we put that and Rachael's issue in the writeup? It should be inactivity from the user side.

Joshue: Something to consider.

<LisaSeeman> rachel can we cover thatin the write up or does it need a rewrite

David: I agree with what Mark was saying about 24 vs 20 hours. I agree that 24 hours is clearer. 20 hours was original the length that people could possibly work on it.

<Greg> David, keep in mind that we don't force them to keep the data, it's just that if they don't they need to provide a warning about any timeout period.

The other concern is data that impacts privacy policies. There may be something with the phrase "warn users..." that should be looked into. I think this is good enough for draft.

<Zakim> Ryladog, you wanted to say that today I filled out a form that identified for me before I stated it that I had 15 minutes to complete the transaction before it would time out -

Joshue: I think error recovery is an important area. I agree it should go to draft for further tweaking.

<gowerm> "data" and "timeout" both need to be better defined, as per some comments

Katie: I think Lisa already said we'll add the sensitive data exception. Only sensitive data would not be kept. I think we should put this out with the 24 hours. We wlil get pushback but can then address the 20 hours.

<LisaSeeman> What are next steps

<gowerm> 24 hours is fine. But I do think you need to contain the data -- "user entered" or whatever. And timeout -- need to address transaction timing (you have 10 minutes to fill out) versus inactivity timeout versus network timeout, etc

<Greg> The cutoff period might affect everyone, but those who work extremely slowly would be more likely to hit that limit. The same is true with "you must complete within 15 minutes" limits that aren't related to inactivity.

<david-macdonald> +1

<marcjohlic> +1

<LisaSeeman> +1

<Ryladog> +1

Andrew: Rational for 20 vs 24 hours in 2.2.1 is that it is longer than a working day. This is a different situation.I would like to put this out for feedbakc. I think that the issue Rachael brought up is a different issue, out of scope, It effects everyone equally.

<Kathy> +1 with the changes discussed

<Kim> +1

<gowerm> +1 assuming my typed comments are addressed

<KimD> +1 if exclude sensitive data, etc.

<AWK> +1 including the changes mentioned

<jasonjgw> -1 unless my comments in the survey are properly addressed.

<Joshue108> +1 with inclusion of client vs server side

Joshue and Andrew: Can everyone put in their opinions for moving forward assuming sensitive data and server vs client side information?

+1

<kirkwood> +1

Joshue: Pretty positive.

Lisa: What are next steps?

<AWK> === concerns about adding exclusion for sensitive data

<AWK> === question remaining about "timeout" vs "time limit" (due to inactivity or passage of time)

<Greg> Lisa, as I said above, I think sensitive data isn't really key, as we're not forcing authors to save data, merely to warn about timeouts if they don't.

=== concerns about server side vs client side activity

<AWK> === need to clarify what "data" means, per Jason's comment

RESOLUTION: Leave open while final adjustments are made. See issues.

<Greg> I think that could be clarified in supporting documents.

David: When we have something that is 10x amount, how do we handle that?

<gowerm> +1 for Katie's comment

Katie: I think that is a different success criteria

Minimize user errors: https://www.w3.org/2002/09/wbs/35422/minimize-user-errors-13/results

Joshue: This is another COGA success criteria.

<AWK> current version: https://rawgit.com/w3c/wcag21/minimize-user-errors_ISSUE-13/guidelines/#minimize-user-errors

Joshue: What have you done to address the issues raised in survey?

Lisa: A lot of the concerns haven't been updated in the form.

<AWK> Split view of changes since Tuesday: https://github.com/w3c/wcag21/commit/9f0c472094b68d7d246d24b3256827357edf94d3?diff=split

Lisa: Another comment is that this is far away from where you started. Yes we have. We are trying to make an improvement by finding something clear and testable.

<gowerm> +1 for that approach, Lisa: improvement rather than solving everything

Lisa: We can clarify some of the issues can be worked in the writeup.

Joshue: Do you need to rework this and bring it back?

Lisa: I'm not sure I understand the comment because its further away from the original intent.
... I'm not sure whether to keep the exception.

<Zakim> Greg, you wanted to review my 3 survey comments

Joshue: Generally you are happy with it as it currently stands?

Lisa: I would like more direction on what needs to be done

<Greg> Isn't this use of "such as" problematic? Does this imply that the exact list is up to the page author, or is it assumed that there is some published minimal set for each language? Or is it being implied that ANY non-alphanumeric character should be counted as a valid separator? That seems to severely limit data validation, which could lead to data corruption. For example, a person accidentally ent

<Greg> ers 3` instead of 31, but it's treated as 3 followed by a separator, and thus 3 is used rather than the user being warned of their mistake.

Greg: I appreciate what you are doing and the goal. I have 3 comments. The "such as" seems problematic. It seems broad. There is an issue with the decimal point. Seperators vary greatly from country to country and use to use.

Lisa: I agree. I prefer to keep it out.

<Joshue108> JOC: Many of the comments seem like implementation details.

<AWK> Greg, I don't understand the separator issue.

<gowerm> +1

Greg: We do have to address the concern about different characters. The user types in a random character. What do we expect the page to do? Correct it? Ask for clarification? I lean towards clarification.

<marcjohlic> +1 w/ Greg's concern

Joshue: This sounds like very detailed technical implementation. I'd like to step back and consider user need. Is this addressing a real need and if we can work out implementation details that is well and good.

<LisaSeeman> mike can you suggest some wording on that?

Mgower: You are relieving the user of the need to manually enter data or you are making it easier. Maybe we can move the paragraphs up a bit to be less technically specific.

<AWK> I'm super confused about the connection between these two paragraphs.

<gowerm> AWK: 1) minimuze user entry problems by offering input choices 2) where user entry cannot be fully overcome, improve feedback on errors for user entry

Jason: I want to speak to the internationalization details in the second paragraph. They are not technical difficulty, they are important. The characters can't be treated as interchangeable. These issue go to the text of the proposal. I agree we need to ensure that if input is treated flexibly, I'm in favor of a higher level requirement. Not sure what it would be.

<gowerm> by "input choice" I mean pre-determined values

<marcjohlic> Please consider limiting this to numerical (or even date) input. If this is open for ALL forms of input I find this much more difficult to implement.

Lisa: We had the higher level approach and got pushback on that so made this more testable. I'd be delighted for recommendations on how to move this forward.

<AWK> Why is there any benefit in accepting -[{ in numerical inputs?

Joshue: I feel your pain from trying the take a more abstract criteria and make it specific then need to go back.

<gowerm> AWK: exactly

<AWK> === need to clarify and connect the two paragraphs in this SC

RESOLUTION: Leave open

Mike: I will take this offline with you. I think the abstraction focuses on 2nd paragraph. Its made progress.

<Joshue108> === Mike to work with Lisa on higher level abstraction for this.

<Joshue108> === Greg to help also

Single Key Shortcut Alternative: https://www.w3.org/2002/09/wbs/35422/Top3_18Apr2017/#wbssc

<AWK> /rawgit.com/w3c/wcag21/plain-language-minimum_ISSUE-30/guidelines/sc/21/plain-language-minimum.html///rawgit.com/w3c/wcag21/plain-language-minimum_ISSUE-30/guidelines/sc/21/plain-language-minimum.html

<marcjohlic> Results - https://www.w3.org/2002/09/wbs/35422/Top3_18Apr2017/results#xsc

Joshue: I expect this will need further discussoion. I'm not sure what everyone's positions are on this. Some are very for and some against.

<david-macdonald> Current language https://rawgit.com/w3c/wcag21/single-key-shortcuts_ISSUE-69/guidelines/sc/21/single-key-shortcuts.html

<AWK> https://rawgit.com/w3c/wcag21/single-key-shortcuts_ISSUE-69/guidelines/sc/21/single-key-shortcuts.html

I think there is a misconception about this. If I am using speech, I am using a string of letters. When I come upon a command that is a word, I am not going to pause before that word or after that word. If it is a single letter command, I can trip it very easily. If I am in a field, that is ok but with single key shortcuts, its easy to get messed up.

With two key shortcuts, its much more difficult. Example: If you go to Google docs and put your cursor on the google docs and then try to use speech, all sorts of things will happen. "I have an idea"

Andrew: Ken, to clarify in Google, they handle this by allowing you to disable single keystrokes altogether. So to adapt, a site can avoid single keystrokes altogether or provide a way to turn them off. Users would adjust by using a mute button?

Ken: I recommend avoiding Gmail. Its like having a hole in the middle of hte room. You have to be always on guard and sooner or later someone will fall in.
... People will not know what is happening. There is no way to be viligent enough.

Kim: If you have a different way to do it or if you let a speech user put in a native speech shortcut (two words) then that is even better. That resolves the issue.

Joshue: Jason made a comment about the ratoinale for this. I'm not sure the current text sells it. It would help if we had a problem statement and solution statement.

<Joshue108> +1 to Kim!

Kathy: The information is int the SC text.

Kim: I can make a video if that will help.

General agreement that a video will help.

Kim: This doesn't happen when the focus is in a text box. It is a user error of sorts but its a common issue.

This is a modality problem. I don't think we want isolate this to being speech only. I would be leery of offering multistring approach.

Kim: That would let speech users do this.

I think focusing on modifier keys but avoding specific solutions would be better.

<Zakim> Ryladog, you wanted to talk about adding 'custom scripted behaviors' to the SCis written

<Ryladog> Can we also add 'custom scripted behaviors' to this?

Joshue: I hear we are getting closer.

Katie: Kim, can we add custom scripted behaviors to this?
... Isn't the issue when someone creates a custom scripted behavior vs when its done through access keys.

<gowerm> Access keys should not be a problem.

<Greg> Katie, today it requires custom-scripted behaviors in HTML, but that's too technology specific. It might be possible in HTML 6 etc.

That is very specific to html. Do we want that in here or in technical documents?

<Zakim> Greg, you wanted to say Reminder that while speech input is the primary driver of this, it also applies to other populations, including users of other types of AT that simulate

<Greg> Reminder that while speech input is the primary driver of this, it also applies to other populations, including users of other types of AT that simulate keyboard input, and also users who simply have more difficulty recognizing when the focus has changed.

Greg: A lot of populations benefit from this.

Joshue: I am happy to see this as speech recognition is become more popular.

<gowerm> no

<gowerm> -1

David: Read text. Is that what we want?

Group needs link to revised text. So does scribe.

<Ryladog> the one we linked to: If single-character key shortcuts are implemented by the web page to activate a control, then a mechanism is available to turn them off or remap them to shortcuts with two or more characters.

<david-macdonald> https://github.com/w3c/wcag21/issues/69#issuecomment-298674688

<Greg> In my proposal that initial "key" should have been "keyboard".

<david-macdonald> If a key shortcut using only printing characters is implemented by the web page to activate a control, then a mechanism is available to turn them off or remap them to a shortcut that uses at least one non-printing key or a string of as many as 25 printing characters.

<Joshue108> === Needs to hit more bases than just speech recognition

<Joshue108> === Kim to do video

Jason: I think the general direction of reworking it so it is a more general mechism approach. I wrote concerns in survey. Please address these.

<AWK> === issues about internationalization

<david-macdonald> that is what "a mechanism is available" says

=== Ensure more general application

<Joshue108> === SC text or statement of need could be clearer

Jason: I think I understand the purpose of breaking out the approach into the techniques. I've written a survey response that takes issue with the rationale

RESOLUTION: Leave Open

<Greg> I see a few problems with the proposal that David just pasted in. (1) change the first "key" to "keyboard"; (2) "to activate a control" should add "or trigger an action"; (3) it mixes singular ("a") with plural ("them"); (4) "as many as" doesn't make it clear whether the minimum is the page's or the user's choice.

<AWK> +Jatin

zakim end meeting

<AWK> trackbot. end meeting

<AWK> 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/Current version of the SC: https://rawgit.com/w3c/wcag21/plain-language-minimum_ISSUE-30/guidelines/sc/21/plain-language-minimum.html//
Succeeded: s/oops!//
Succeeded: s/Ken:/Kim:/
Default Present: AWK, Jake, ChrisLoiselle, Melanie_Philipp, Wilco, Rachael, JF, LisaSeeman, allanj, jasonjgw, Bruce_Bailey, marcjohlic, Greg_Lowney, Lauriat, MikeGower, kirkwood, Laura, Kathy, KimD, Katie_Haritos-Shea, shwetank, steverep, Pietro, Davidmacdonald, MichaelC, Joshue108, david-macdonald, Jatin
Present: AWK Greg_Lowney Laura LisaSeeman Melanie_Philipp MikeGower Rachael Wilco jasonjgw kirkwood marcjohlic
Regrets: EA_Draffan Pietro kirkwood couldn’t find meeting#
Found Scribe: Rachael
Inferring ScribeNick: Rachael
Found Date: 04 May 2017
Guessing minutes URL: http://www.w3.org/2017/05/04-ag-minutes.html
People with action items: 

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