W3C

- DRAFT -

Accessibility Guidelines Working Group Teleconference

11 May 2017

See also: IRC log

Attendees

Present
AWK, jasonjgw, Greg_Lowney, MichaelC, Lisa, JF, Katie_Haritos-Shea, KimD, Rachael, MikeGower
Regrets
Alastair, Laura_Carlson, Loiselle, Peitro
Chair
SV_MEETING_CHAIR
Scribe
JF

Contents


<AWK_> +MichaelC

<AWK_> +Lisa

<Hp> nick lisa\

<Hp> nick lisa

<scribe> scribe: JF

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

AWK: list discussio happening. Feels like Jason still has the most concerns
... I am hearing that you do not feel there is enough value for this

JW: I sent an email that outlines my concerns

<AWK_> Current proposal: For each time limit set by the content where user-entered data 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.

the current proposal has limited value: the use-cases are not actually showing that this proposed SC is the right way forward

JW: I have acknowledged 2 proposals, including enhancing 2.5 (?), or advancing 2.2.1 by removing some of the options - limiting it to authenticated sessions

<Ryladog> 2.2.5

JW: the idea is to trya nd solve the problem more directly

AWK: one suggestion then is to edit 2.2.1? (or more accurately creating a new SC that mirrors 2.2.1 with adjustments

JW: there are a couple of different options that look interesting however

LS: Couple of things

the orignal proposal was to edit 2.2.1, but we were told no to taht

LS: Agree that we've cut-out a lot of what we wanted to do, but in dicussions there were so many problems in the original proposal, we figured we'd scale this back to something easier to accomplish, and build on that
... the COGA TF advanced this not because it is that urgent, but that we felt it was pretty straight-forward

This doesn't address all the issues, but it is a good start

<Ryladog> 2.2.5 Re-authenticating: When an authenticated session expires, the user can continue the activity without loss of data after re-authenticating. (Level AAA)

KHS: Liked Andrews suggestion to edit current SC - move 2.2.5 to AA from AAA
... we know there are pieces missing with 2.2.1, but if we pull down 2.2.5 and make some adjustments then we may actually move this forward

LS: cn live with the proposal of moving 2.2.5 from AAA to AA (per Anderews suggestion)

<interaccess> +1 to moving 2.2.5 re-auth to AA.

<Joshue108> +1 to moving 2.2.5 re-auth to AA.

<Joshue108> ?

KHS: if we move it, we should also edit it

AWK: there is a difference here between authenticated sessions and non-authenticated
... would the modified proposal then work? Give the user a heads-up before a session expires - aka helps manage expectations

LS: it helps it a lot
... 2 things: 1, you don't waste your time, and 2) you don't experience a "failure" after investing time

<Zakim> AWK, you wanted to ask if the current proposal helps address the user need

Alex: when it comes to a real-time event, does that consititute a time-out? This makes a big difference

<lisa> can i have the link to the current proposal

<AWK> AWK: the modified proposal isn't talking about timeouts but time limits imposed by the content

I wook on date-retention issues in EU today, and you need explicit user-consent before retaining any data

But first, what is in and what is out?

AWK: real-time event would be out... this is about time-limits imposed by the content

if it is something that the content has control over, it should express that

but if it is controlled external from the content (gives examples) then it is excempt

<AWK> "For each time limit set by the content where user-entered data 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."

AWK: what was the other concern Alex?

<lisa> +1 to alex

Alex: definately need the consent of the user, else it is a privacy violation
... authentication does not directly link privacy consent

AWK: 2.2.5 states "can", not MUST

so we'd likely need to also include language related to privacy rules

AWK: if there is a legal requirement to NOT save the date (aka privacy, etc.) then the requirement is just to advise in advance of the time-limit

JW: there may still be a need for exceptions related to real time, etc.

also open to the idea of an edit to 2.2.1

JW: if those are distinct proposals, i think they cover the issues, but would want to see concrete text first
... agree with Andrew on some of the conditions/restrictions
... what we really want is for users to be subjected to fewer time-outs, as few as possible
... however like others, I don't think I will be supporting proposals that don't really achieve the intended goals (due to watering-down/compromise, etc.)

LS: we will need a mechanism to move this forwardAWK: Agreed
... we need to look at the comments - there were some real issues. For example, if we demand consent, will that impose additional barriers. Also around data-storage, etc.

KHS: this is clearly an important user-need

so whatever we do, we need to do something

byThe privacy component and consent seems the issue

entities are responsible to protect user-data - this is being done already

attempting to define a time beyond 24 hours may be unachievable

<AWK> JF: mentioned before - concern is that if the content provides the timeout then it isn't enough, other sources of timeouts

AWK - looking at the understanding document of 2.2.1 - we state that if it is a server setting for your site that you have control over, then it impacts...

my response however was if it is limits set by the content, it allows us to avoid it inter-mingling with some of the real-time issues bing rasied

<Ryladog> To help JF; My comment was, lets accept what we have today, pasted in here above by AWK. It addresses a very important user need, needing to the time they have to complete something. I am also saying that 2.2.5 would need to add user-consent to the timeout dialog, to maintain the data for 24 hours. The site has the responsibility to protect the privacy of their users data, and they do this today. Defining a reasonable amount of time say 24 hours is reasonable

AWK: what we have now is that we do not have a lot of time left. If we don't get something done with this, it will drop to the bottom of the queue again

so I am suggesting a new survey for next tuesday's call, and then send out a CfC around 2.2.5 and our intent

<AWK> https://www.w3.org/WAI/GL/wiki/WCAG_2.1_SC_status#Issue_14_-_Timeouts

AWK: We are in a new process attempting to keep track of these issues - provides link

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

<Joshue108> My broader question is around how many AAA SCs could be edited and bumped to AA?

<Joshue108> There are many that seem similar IMHO.

we've also added a new section "OPen Issues and Surveys" - we will collectively maintain these to attempt to narrow the funnel of inofmration we've got

<Joshue108> Also has testability improved for some so they could be upgraded (sic)?

hearing some concerns from Jason, but not "dead"

<lisa> maybe we can have the a "can live with option"

AL: what is thhis 2 week thing?

AWK: every two weeks we attempt to focus on just 3 issues

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

AWK: is Kim Patch here?

KP: yes

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

AWK: this doesn't seem to have as much focus as other issues at this time

looking through this one... where are people thinking this is at?

are there still concerns that haven't been addressed?

<Kim> Short name: Character key shortcuts

<Kim> SC:

<Kim> "If a shortcut consisting entirely of character keys is implemented by the web page to activate a control, then a mechanism is available to turn it off or to remap it to a shortcut that uses at least one non-printing key."

<Kim> Definition:

<Kim> Character key: any keyboard character that is printable, i.e. letters of the alphabet including capitals, punctuation, numbers, and symbols.

AWK: so this appears to be a substantial change

KP: yes, it is, to address Gregg (Gregg?)'s concerns

AWK: now confused - what is this actually trying to say

<Greg> That was Greg's concern, not Gregg's.

AWK: do people have multiple shortcut keys for applications?

GL: strings of character keys, used by things like VIM text editor (etc.) often use non-letter keys to start sequences, for example ;x for exit

if the focus is in the wrong place however, those characters can be typed, but interpretted not as text but as comands

this is what we are attempting to avoid

GL: another example... typing ahead. If you cannot see the screen, you can find yourself typing ahaead and thus triggering a problem as well
... in the latest draft, one of those still had the "non-printing key" which should be actually the printing key

KP: deliberately left that, but can change it

<AWK> JF: It seems that one of the things that would be manifest with this kind of problem

<Kim> "If a shortcut consisting entirely of character keys is implemented by the web page to activate a control, then a mechanism is available to turn it off or to remap it to a shortcut that uses at least one character key."

<AWK> ... is that this is related to role=application content

<AWK> ... so all keyboard responsibility falls to the author

<Kim> "If a shortcut consisting entirely of character keys is implemented by the web page to activate a control, then a mechanism is available to turn it off or to remap it to a shortcut that uses at least one non-character key."

<AWK> === concern that people may think that we are talking about accesskey even though we are not

<Ryladog> We had talked about adding 'custom scripted behaviors' or 'custom behaviors'

<Zakim> Greg, you wanted to point out that today's HTML does not support unmodified keyboard shortcuts, but those might be supported in future versions or other web standard languages, or

<AWK> === might be applicable only to web applications (role=application)

GL: while this is correct today, there is no guarnetee thta this is the expected behavior for all time

we should contemplate HTML6 may change

<Joshue108> +1 to JF

<Greg> Today's HTML does not support unmodified keyboard shortcuts, but those might be supported in future versions or other web standard languages, or by unusual user agents.

KHS: this is why I suggested "custom behaviors", after which we can better define that

<Zakim> Joshue, you wanted to ask if role=application is used on GMAIL example?

JOC: want to examine this a bit more if we use role-"application" as a means of constraining this

<Greg> So anyone can get out of this SC by not using role=application? Would that cause them to fail any other SC?

JOC: Is role application used in the GMAIL example that supports Kim P's use case?

MG: Katie's language is not specifically talking about role=applications, but it would vcover that use-case

KHS: will drop text into IRC

<Joshue108> +1 to Lisa

LS: don't think there is a requirement to use role="application", but there is not specific requirement - no existing SC today

<Joshue108> ok

<Greg> I do not agree with restricting this to custom behaviors, for the reasons I've already stated: that HTML 6 might allow the author to specify unmodified shortcut keys, which would not be "custom behaviors" but should be covered by this SC.

<Ryladog> "When building custom behaviorsiIf a shortcut consisting entirely of character keys is implemented in a by the web page to activate a control, then a mechanism is available to turn it off or to remap it to a shortcut that uses at least one non-printing key."

AL: only read the old version... if you do have this behavior - a single printable character - then we are proposing two options? Turn it off or re-map it (to something that uses a non-printable character / modifier key as well)
... question about space bar - is that a non-printable or printable character key?

<Ryladog> "When building custom behaviors if a shortcut consisting entirely of character keys is implemented in a by the web page to activate a control, then a mechanism is available to turn it off or to remap it to a shortcut that uses at least one non-printing key."

AL: seeking clarity here before I voice an opinion

<Ryladog> "When building custom behaviors if a shortcut consisting entirely of character keys is implemented by the web page to activate a control, then a mechanism is available to turn it off or to remap it to a shortcut that uses at least one non-printing key."

<gowerm> Spacebar is not just a substitution to the Enter key

obviously space-bar is used in different applications - but if somebody presses the space-bar and then a focusable element, then that is fine?

KP: yes

<Greg> Space should definitely be covered: anything which is part of a normal text string that can be pasted in is potentially a problem. Hmm, of course, by that logic newline is also potentially a problem. But don't forget that this originally didn't apply to the control that had focus, so that was not a problem.

<AWK> AWK: the space bar is likely not going to come up often since it is used for other things often (pgdn, button activation)

KP: in my mind, the space-bar is not a character key - the list of character-keys are provided...

<Greg> Kim, don't you have spaces in voice macros, that are automatically "typed in" when you give a command?

AL: in languages like CJK, you have to use combinations to form certain characters

<Kim> you dont voice spaces

AL: so the question is, has this been reviewed agaisnt non-latin languages (I18n)?

<AWK> === have we considered other keyboards like for CJK?

KP: don't thin it makes a difference (for speech users)

MG: feel the focus on this is saying "You hae to use a modifier key" - wondering if we put the focus there? would that solve the issue?

if a shortcut does not involve a modifier key, then...

KP: escape key, ctrl key, etc.

<AWK> === can this be simplified by making the focus be on using a modifier key?

+1 to Mike's thinking, needs fine-tuning thought

JW: my concerns remain unaddressed. I would be interested in seeing the form that this takes after we apply some of the other constraints articulated (role="application, i18n issues, etc.)

<Greg> Mike, the wording was supposed to allow use of Esc or F10 or PgDn, which unfortunately merely requiring a modifier key would still exclude. However, maybe we can include wording about modifier keys as well as non-character keys.

KP: did you look at the video?

<AWK> Video showing the problem: https://youtu.be/OPjfpDU9S08

JW: doesn't address my concerns

<gowerm> If a shortcut consists of only one or more printable character keys, then a mechanism is available to turn it off or to remap it to a shortcut that includes a modifier key

KP: if there is anything in GitHub that is not addressed, please ensure that the concerns/questions are there

<gowerm> If a shortcut consists only of one or more printable character keys, then a mechanism is available to turn it off or to remap it to a shortcut that includes a modifier key

AWK: seems there is no resolution on this now

KP: pasting in latest, as concerned that there are multiple different versions flying aroudn

<Kim> "If a shortcut consisting entirely of character keys is implemented by the web page to activate a control, then a mechanism is available to turn it off or to remap it to a shortcut that uses at least one non-character key.

KP: reminder to look at the GitHub thread too please

<gowerm> Greg: Esc or F10 or PgDn, are not printable characters

trackbot, end meeting

Summary of Action Items

Summary of Resolutions

[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.152 (CVS log)
$Date: 2017/05/11 16:39:40 $

Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]
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/does anyone know if GMail uses role="applications" when they usae single-key shortcuts?/Is role application used in the GMAIL example that supports Kim P's use case?/
Default Present: AWK, jasonjgw, Greg_Lowney, MichaelC, Lisa, JF, Katie_Haritos-Shea, KimD, Rachael, MikeGower

WARNING: Replacing previous Present list. (Old list: AWK, Joshue, JakeAbma, Detlev, Mike, Elledge, kirkwood, alastairc, steverep, MikeGower, shwetank, Laura, Makoto, Katie_Haritos-Shea, KimD, Melanie_Philipp)
Use 'Present+ ... ' if you meant to add people without replacing the list,
such as: <dbooth> Present+ AWK

Present: AWK jasonjgw Greg_Lowney MichaelC Lisa JF Katie_Haritos-Shea KimD Rachael MikeGower
Regrets: Alastair Laura_Carlson Loiselle Peitro
Found Scribe: JF
Inferring ScribeNick: JF

WARNING: No meeting chair found!
You should specify the meeting chair like this:
<dbooth> Chair: dbooth

Found Date: 11 May 2017
Guessing minutes URL: http://www.w3.org/2017/05/11-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]