Accessibility Guidelines Working Group Teleconference -- 07 Nov 2017

<Kathy> trackbot, start meeting

<trackbot> Meeting: Accessibility Guidelines Working Group Teleconference

<trackbot> Date: 07 November 2017

<MichaelC> meeting: AG TPAC Day 2

<AWK> +AWK

<AWK> Chair: AW

<AWK> Chair: AWK

<AWK> https://www.w3.org/WAI/GL/wiki/Meetings/TPAC_2017

<jeanne> scribe: jeanne

<AWK> https://www.w3.org/WAI/GL/WCAG21/sc-status/

Processing Comments

AWK: This page is the overview of the comments tracking
... there are a lot of zeros, which we need to address

https://www.w3.org/WAI/GL/WCAG21/sc-status/

scribe: don't refresh the page, or it will fail.
... from having 30 people trying to refresh at the same time

Interruptions Minimum

<lisa> 11am-12pm APA/CSS Meeting13:00-14:00 with APA COGA Strategies (with AG-WG) 14:00-15:00 COGA-TF in the APA room and 2pm-3pm APA/Web Platforms Meeting on Editing

AWK: 2 comments on this

http://rawgit.com/w3c/wcag21/master/guidelines/index.html#interruptions-minimum

<bruce_bailey> https://www.w3.org/TR/WCAG21/#interruptions-minimum

Lisa: If people get distracted easily, the more interruptions they get, the less effectivet they are
... people with impaired memory or attention deficit disorder, things become unusable.
... if you are giving distractions, the user needs a way to easily turn that off.
... if there is a setting in the OS "don't interrupt me except for an emergency from my mother" that would be ideal.
... there is a strong need to address this

<bruce_bailey> http://rawgit.com/w3c/wcag21/master/guidelines/index.html#dfn-easily-available

Lisa: it needs to be unified across applications, but even without that we need to be able to turn off interruptions

Alex: Microsoft submitted comments that do not appear.

AWK: We are working on the public comments at this time.
... Jan Richards pointed out that the purpose of some apps is to provide interruptions.

JF: Social media

Alastair: Co-editing a document

Lisa: Since we already said that the user controled it, we have taken care of this issue.

<Joshue108> what number issue are we on?

Lisa: even though it is the main purpose, we want to be able to turn it off, or postpone the interruptions.

John: Concerns: Is this a content authoring problem? If it is handled in the OS, then it isn't a content authoring issue. The application and the system are source, not the author. ALso how can emergencies be identified and coded.

ALex: All the OS, have quiet hours.
... the email has to come in. You can still see your clock, you can still see your battery level discharging if you aren't plugged in.
... there is an emergency alert from the phone from police (FCC regulated notice) the app provider, email, and the laptop OS don't know. They aren't initiated by users, generally.

John: We are in agreement.

Alex: The browser can be set to recognize quiet hours. If you are using a web-based interface, the browser can do a subtle change of content -- incrementing number of emails -- but can suppress a popup notification.
... it can be coded, but is not done yet.

Jason: What is "initiated by the user" mean? If it is informed consent, then it doesn't answer the issue raised by the success criteria.
... it needs a narrower meaning
... it isn't entirely clear what "interrruptions" are. A notification could be an interruptions, but it might not. It isn't clear where the boundaries are.
... there are web sites that initate a prompt from the user agent, "do you want to allow this app to send notifications?" This is not under the control of the web author, it is a function of the user agent.
... some of these are content author responsibilities, some are user agent responsibilitiies
... we need clarifciation around the scope

Lisa: Could there be a link to the Understanding section?

<marcjohlic> Interruptions (Minimum) http://rawgit.com/w3c/wcag21/master/understanding/21/interruptions-minimum.html

Lisa: We intended this to be task related, to allow someone to finish a task uninterrupted, not to turn off all OS notifications.
... there may not be a way to notify an emergency. It is more that if there is a method to allow emergency notifications to get through, then they aren't in violation.
... you have to conform to the OS handling of turning off notifications

<Jan> Here's the understandings document Lisa was referring to: https://docs.google.com/document/d/13hmoaVU563kTio1EZD5mbNxcc0k924qVdZZwWckcbu0/edit#heading=h.8od89ooevt70 - Look for heading "Understanding Interruptions"

Josh: Are we trying to burn through the comments, or are we trying to kick around the success criteria?

AWK: We are trying to burn through the comments

Josh: I really like this success criteria, but I think it is AAA and at the discretion of the author of what is an "unnecessary" interruption as to the core application

<marcjohlic> +1 to Josh - AAA and slight re-word - "unnecessary"

Alex: I think that Josh is confused.

<marcjohlic> Comment 474: https://github.com/w3c/wcag21/issues/474

AWK: Looking at comment 474, there are additional considerations, including error messages, "easily", and scope of interruptions.

<Joshue108> but stand by my comment on the SC in general

<Zakim> AWK, you wanted to review the other public comment

Alex: Josh's comment included "essential exceptions", but essential exceptions are not a part of this SC.
... this SC is in conflict with option 3 of 2.2.1 which is the 20 second extend option

<Zakim> bruce_bailey, you wanted to say that the definition for "easily available" needs quite a bit of work. I think each of the bullets have issues.

<Zakim> Greg, you wanted to note even in apps where real-time updates are core functionality (e.g chat) it's useful for users who read or interact slowly to be able to pause updates that

Bruce: I want to postpone this discussion. I looked at the definition of "easily availalbe" and there are 3 problems with it. I don't think we can resolve this on a timely basis

Greg: In a chat app, to prevent it from being able to scroll up is important.

<Greg> note even in apps where real-time updates are core functionality (e.g chat) it's useful for users who read or interact slowly to be able to pause updates that interrupt their interaction (e.g. scrolling). The Understanding document does not discuss this benefit.

<Joshue108> I guess how many app break the 'enough time' rule?

<Joshue108> loads I guess..

<Zakim> Rachael, you wanted to say, In the understanding document it states "No sudden changes occur on the site." Suggest No sudden changes occur on the site unless live updates is the

<Greg> It might be possible to distinguish between major updates like that and minor updates like a clock; the latter can be a problem for people who have trouble with distractions (unless they're using AT that can pay attention to aria live, etc.).

<Rachael> Define Interruption: Secondary information, pop-ups, or actions that are not part of the workflow sequence such as error and timeout messages or the key purpose of the application such as live updates..

Greg: major and minor updates are handled by ARIA, but only for those using Assistive Technologies

Rachael: Proposal (above)

<Joshue108> I wonder if the proposed SC could ironed out / merged with 2.2.1 in future future release?

<bruce_bailey> @JF, the SC does not *require* emergencies to go through

John: What is the nature of "emergency"? An advertisement? Is this handled by whitelisting from the OS, or meta data tagging of what an emergency

<alastairc> I like Rachael's definition, might help if it were defining 'unnecessary interruptions' though, then don't need the emergency / essential exceptions.

<Joshue108> Thanks for clarification Alex btw

<jamesn> emergency

<jamesn> definition: sudden, unexpected situation or occurrence that requires immediate action to preserve health, safety, or property

Lisa: There is a definitoin of emergency
... It is a defined term, it is not undefinted.

Jason: regarding emergency, this in included in WCAG 2.0.
... this could be used as a defintion for other places in 2.0
... it's a good idea in general
... there is a lot of work that needs to be done to clarify the scope

<JF> Editorial note: the term "emergency" is not linked to the definition of that term in the glossary

<lisa> can someone try and work on it

<Joshue108> I suggest that Alexs point about conflicts with 2.2.1 are adressed also

<lisa> good idea

AWK: We have been talking about this for 40 minutes. Should we move on?

<Zakim> gowerm, you wanted to say I'm concerned that there are existing Issues that have covered most of the concerns expressed this morning. They have not been addressed

Marc: There are a number of issues on this, and there should be more done by the success criteria manager.

<Zakim> bruce_bailey, you wanted to ask where to put concerns

Lisa: I took it over from someone else, could someone else take over as SC manager?

<marcjohlic> My comment around Interruptions: “Unless they are initiated by the user" is problematic if we're saying that just by virtue of going to a particular site (FB, Twitter, stock etc) they are "initiating" consent. Any author could simply say “users know that by coming to our site that they will be blasted with updates” - it’s the nature of our site.. timely information yada yada yada. Needs to be AAA - or somehow tightened up.

AWK: Implement a new branch or open a wiki page for comments

<alastairc> I put a comments summary page for zoom linked from here: https://www.w3.org/WAI/GL/wiki/Accepted_WCAG_2.1_SC

David: I'm concerned about the momentum about this uccess criteria. Do we want to decide if this is going to go into the final
... is it ultimately going to be achievable?
... we are going to final draft in 2 weeks

<lisa> +1 to rachel!!

<JF> a reluctant +1 to David - this remains very immature at this time, with lots of unanswered questions

AWK: In order for things to make it into CR, we have to have agreement on the text, that we have addressed comments, that we will have techniques for it.
... if we are still discussing the core concepts, that makes it more difficult.

RESOLUTION: We leave Interruptions Minimum open

Character Key Shortcuts

<marcjohlic> Character Key Shortcuts Understanding: https://rawgit.com/w3c/wcag21/character-key-shortcuts/understanding/21/character-key-shortcuts.html

<marcjohlic> Character Key Shortcuts SC http://rawgit.com/w3c/wcag21/master/guidelines/index.html#character-key-shortcuts

AWK: #556, does this rule out single key shortcut?

Kathy: It is covered in the Understanding document. Accesskeys are not included.

<marcjohlic> Issue #556 https://github.com/w3c/wcag21/issues/556

<bruce_bailey> https://w3c.github.io/wcag21/guidelines/#character-key-shortcuts

Kathy: The definition of character key handles it. An accesskey has a modifier, so they are excluded from the defintion of character key.

John: When you have single character keys, the user can change to a modifier key.

Kathy: Two character keys are still a problem. It requires an option for adding a modifier key
... that is in the Understanding document. Do we need to put that in the SC.

Jon: For a speech input user, turning the single key character shortcut off, prevents inadvertent triggering of an action not desired by the user.

Marc: I've written the response for 556

<gowerm> The [definition of character key](https://w3c.github.io/wcag21/guidelines/#dfn-character-keys) is:

<gowerm> > **character key**

<gowerm> single printable Unicode code point, any keyboard character that is printable, i.e. letters of the alphabet including capitals, punctuation, numbers, and symbols

<gowerm> Note that the Space and Enter keys, which return empty spaces rather than characters, are not character keys.

<gowerm> An accesskey has a modifier, so they are excluded from the defintion of character key.

Kathy: that looks fine

<gowerm> https://github.com/w3c/wcag21/issues/556

Kathy: There are two videos that illustrate the problem. Reference those videos

<Zakim> Wilco, you wanted to ask if we should mention modifier keys in the note

Wilco: Can we add a note of when it is not applicable.

Kathy: This is thoroughly covered in Understanding

John: I think adding the "modifier" to the sentence

Kathy: It's a good change

John: I'll take an action to create a definition of "modifier" key.

<jamesn> https://www.w3.org/TR/uievents-key/#keys-modifier

Kathy: It's anything but a character key. It could be a space bar, or NUM LOCK, etc. Some would be stupid to use some of them (like Delete).

<Kathy_> A modifier key modifies the action of another key when the keys are pressed at the same time. Common modifier keys include Shift, Function, Control, Alt, Command, and Option.

<Greg> The fact that Jan (an experienced WAI person) was confused by this proves that the wording could be clarified. I'd append "(e.g. a modifier key)" to the SC language.

John: If we are struggling with the language, then others will

Kathy: we had modfier key in the SC orginally, we are going around and around.

AWK: We need a response that we disagree that this is not the intent of the SC, and we think that the videos and Understanding [link] makes that clear.
... The second part is that we made a minor change based on the suggestion
... According to James some clarification of when the single key is acceptable is needed.

James: There was a survey with no objections

<Brooks> scribenick:Brooks

<jon_avila> scribe: jon_avila

awk: comments from survey refine terminology related to added exception for key when has focus
... current operating approach is Steve's last refinement. Addresses JamesN comment.

shwentank: asking about ambiguity with some examples of printable keys

<AWK> "If a keyboard shortcut consisting entirely of one or more character keys is implemented by the content, then a mechanism is available to turn it off or to remap it to a shortcut that uses at least one non-character key, unless the keyboard shortcut is only active when the user interface component has focus."

crystal: asking about when controls don't have focus - and single letter keys are pressed.
... question about which UI are active or not active
... asking what do you mean when it has focus or not have focus?

awk: example would be a select element - a list of US states - you type c for connecticut -- that's kb shortcut.
... when it has focus that's ok for c to move to conneticut
... reason for last phrase is to ackwonledge need for keys to perform first letter selection

crystal: asked about pressing r in a list of inbox emails

kathyW: suggests watching video for examples.

crystal: asking about understanding issues as they have added keystrokes to help some users but they don't want to negatively impact other people.

awk: any other comments about resolution of 501?

steve: suggested some options that might work better to associate the UI components with the keyobard shortcut.

awk: what about "only when associated UI component has focus"?

awk: linkage between shortcut and UI it applies to
... any objections?

ryladog: would like EO to focus on this issue in a video

alex: is term "associated UI component clear"?
... term associated is unclear.

kathyW: associatin the keyboard shortcut with the user interface component

alex: looks like editorial thing

<gowerm> editorial!

<Zakim> steverep, you wanted to say I probably meant something like "associated" instead of "particular"

awk: any objections to accept this as amended?

<AWK> ""If a keyboard shortcut consisting entirely of one or more character keys is implemented by the content, then a mechanism is available to turn it off or to remap it to a shortcut that uses at least one non-character key, unless the keyboard shortcut for a user interface component is only active when that component has focus.""

Greg L: question about the word "that"

gregl: would the wording allow multiple divs be implemented for a listbox

<steverep> Alternative: "If a keyboard shortcut consisting entirely of one or more character keys is implemented by the content and is active independent of focus, then a mechanism is available to turn it off or to remap it to a shortcut that uses at least one non-character key."

Greg1 is ambiguous for component - we mean conglomeration of the pieces.

<gowerm> Understanding doc

<laura> Understanding

<Jan> +1 to understanding document

<gowerm> "component can include a complex widget"

<gowerm> "If a keyboard shortcut consisting entirely of one or more character keys is implemented by the content, then a mechanism is available to turn it off or to remap it to a shortcut that is either user determined or uses at least one non-character key, unless the keyboard shortcut for a user interface component is only active when that component has focus.

awk: cleared objections from GregL

<Greg> "'that component' can include a set of related components, e.g. a custom menu implemented as a set of separate DIVs."

gowerm: have included "either user determined or"

<Greg> Can you please paste a link to the specific Issue under discussion?

awk: a solution could be to turn off or if it's remapped - either remap to include modifier or to change the letter to someting else.

<KimD> https://github.com/w3c/wcag21/issues/451

gowerm: don't want to restrict allow single character key

<Jan> +1 to the comment that this SC is becoming clunky because of all the additional phrases.

kathyw: don't think we should have that language in there.

kathy: other methods can come with device sensory - it's unrestricted now -- why restrict.

ryladog: agree with KathyW - let's not -- we can use understanding doc to come up with ideas

awk: to clarify the currently languages already allows for user determined.
... we don't need to specify

<Zakim> JF, you wanted to ask that if "remapping" needs to happen, isn't that already a user choice?

jf: remapping is user choice. no benefit to add excess verbosity.

jamesn: could use word "can" - concerned that language says remapped requires modifier keys. Propose that it can include one non-character key.

<Wilco> +1 to "can use"

jf: happy with that

<AWK> "If a keyboard shortcut consisting entirely of one or more character keys is implemented by the content, then a mechanism is available to turn it off or to remap it to a shortcut that can use at least one non-character key, unless the keyboard shortcut for a user interface component is only active when that component has focus."

<JF> +1 to current draft

ryladog: agree with proposal

<Zakim> steverep, you wanted to ask how this is not already covered by the SC? Perhaps a note similar to 2.1.1?

steverep: can this be covered by 2.1.1 note
... don't want to say all shortcuts have to have a modifier -- note to say we aren't discouraging it -- just a way to change it. In the same way that keyboard says it's not discouraging pointer input.

gowerm: don't want to change it to "can"

awk: per Mike G's agreement we will clarify this in the understanding document.
... have some note for 2.1.1. in light of Steve's comment

steverep: should say in this SC that there is nothing wrong with a single key shortcut. All of that can go in understanding.

awk: any objections to accepting the current proposal?
... didn't change from last agreed upon text.

<gowerm> https://github.com/w3c/wcag21/issues/451

Refer to the closed issue #451 for comments to put in understanding doc

RESOLUTION: accept comments and amend understanding document per issue #451

awk: we have 45 minutes until break - after that EO will come in
... take a break now instead. Be back at 10:35 PT
... starting up next
... attempting to get Lisa on phone for COGA SC

<Rachael> I updated https://www.w3.org/WAI/GL/wiki/2.2.8_responses with our discussion yesterday

awk: Sharon asked if EO can come in at 11 instead of 11:30 PT
... want to talk about Timeouts as this is a time she is available
... concurrent input mechanisms up

<lisa> i am calling in

<AWK> https://w3c.github.io/wcag21/guidelines/#concurrent-input-mechanisms

awk: IBM has concerns to confirm it has been achieved and conv reflects this concern
... technology specific techniques may be only guide to testing.

<Zakim> gowerm, you wanted to say I'm fine with withdrawing and putting in a note

gowerm: what do you do to pass for a website?

<lisa> on tha call

davidMac: ask the developer if they have done anything that restricts

<Kathy_> https://rawgit.com/w3c/wcag21/concurrent-input-mechanisms/understanding/21/concurrent-input-mechanisms.html

gowerm: carefully defined failures may be needed

kathyw: the failure that we have is looking at presence of event handlers and CSS media queries

awk: sufficient techniques is to use input agnostic handlers

kathyw: not sure if we need to change the SC language -- but these failures are what we came up with when writing understanding docs

awk: inspect code and event handlers or CSS and might identify failures by interacting with it

<Greg> Current topic is IBM comment on 2.5.2 Concurrent Input Mechanisms · Issue #458 · w3c/wcag21 · GitHub https://github.com/w3c/wcag21/issues/458

kathyw: won't be able to test everything single device -- will have to look at events

davidmac: may have to dig through JS

james: how many people will be looking at JS libraries inspecting gthe code to find this

awk: comment from GregV - needs better name and has grammar
... third comment is about essential - SteveRep had suggested change

steverep: just link to definition needed

awk: onerous to test it - that is the question to figure out.

gowerm: with techniques and test process that is defined will provide clarity
... could say something like not failing failure techniques would be sufficient to pass

kathw: have two proposed sufficient techniques and two failures
... need to clearly define test procedure - Patrick has done some work and we have some articles and resources available

<gowerm> https://github.com/w3c/wcag21/issues/64#issuecomment-266046876

bruce_bailey: looking at 2.0 to see if we cover doing no harm - could we say two input modalities or more? We need to have a positive assertion.

kathy: primary way of interacting on mobile is touch. On pc with keyboard or mouse.
... could do sensor, keyboard, etc. to mobile - open to changing

<Zakim> bruce_bailey, you wanted to assert the requirement in positive language

<Zakim> JF, you wanted to Mike Gower's comment about Failure Techniques

jf: intent of WCAG is to be affirmative - needs to be a measurable condition.

kathy: concurrent part allows users to switch been inputs.

jf: picked up on affirmative - keep that spirit

kathyw: don't want to lose spirit.

ryladog: web content allows instead of does not restrict.

<Rachael> Katy's proposal: Web content allows the use of all input modalities available on a platform except where the restriction is essential, required to ensure the security of the content, or respect user settings.

ryladog: get positive thing - but just as valid is outcome based that allow for multiple ways

<Zakim> Wilco, you wanted to talk about testing events

bruce_bailey: web content allows multiple input modalities available on platform.

<Rachael> Web content allows the use of multiple input modalities available on a platform except where the restriction is essential, required to ensure the security of the content, or respect user settings.

wilco: finite APIs are available today - may be laborious - hard to find what event are being listened for - unless you analyze code.

<Kathy_> Web content allows the use of multiple input modalities that are available on a platform except where the restriction is essential, required to ensure the security of the content, or respect user settings.

gowerm: posted as a consideration - very hard for users to figure out when issue is something related to platform or app is failing? How do I know if it's the OS?

kathyw: that's why you need to look at the code.

ryladog: indieUI stuff - half went to web and some to CSS - will be a way to use independent event hanlders.

jamesn: when do you need to be able to switch between modalities. Do you need to switch half way through?

kathyw: at any point is what we currently have.

ryladog: as supported by platform- will be limitation by other APIs, etc.

<AWK> "Web content allows the use of multiple input modalities that are available on a platform except where the restriction is essential, required to ensure the security of the content, or respect user settings."

kathyw: can we take a poll?

alex: friendly amendment - respect device and user settings? Can be locked by kiosk, etc.

<Jan> should you change "the" restriction to "a" restriction?

alex: could be platform, device, or other settings.

awk: user or platform settings? assuming they are set by a user.

alex: As long as we clarify user or platform.

gowerm: this was also raised related to accessibility supported with platform settings.

wilco: wonder about novel platforms that require you to have a laser pointer.

kathy: that would be essential.

alex: thinking about locked down environment where something is locked by administrator
... no AT in closed environment. don't recommend WCAG try to solve this for closed functionality

<Ryladog> "Web content allows the use of multiple input modalities that are available except where the restriction is essential, required to ensure the security of the content, or respect user or platform settings."

ryladog: what about we remove on the platform?

<AWK> Available in the world?

kathyw: the point was that we need the ones on the platform. We wanted touch available if platform supports it rather than just two available that aren't on the platform.

awk: needs scope to world or in this context.

ryladog: suggestion was based on us using bullets

<lisa> joining apa now

bruce_bailey: isn't security part of essential?

kathyw: restriction is about input modality?

<AWK> Latest: "Web content allows the use of multiple input modalities that are available on a platform except where the restriction is essential, required to ensure the security of the content, or respect user or platform settings."

awk: enough critical mass of EO visitors -- we will pause and pick this up after

<Kathy_> Web content allows the use of multiple input modalities that are available on a platform except where the input modality is essential, required to ensure the security of the content, or respect user or platform settings.

awk: will confirm Lisa's schedule

<lisa> 1-2 i defintly can not make

<AWK> lisa - 3pm?

<lisa> 2-3 i can make if we cancel the coga meeting which we can do if the group is ok with that

<AWK> oh - 2pm is ok?

<lisa> 3pm is clear :)

<AWK> done - timeouts at 2pm

<AWK> (have Rachael talking to me also)

<Brooks> scribenick: Brooks

EO and AGWG

AWK: Main thing we want to talk about is content of Understanding documents

<lisa> can be free if we cancel the coga TF meeting. ask jan and John if they are ok with that

AWK: there's a lot of important info we need to get across. Both working groups should discuss.

Brent: Interested in working on Understanding documents on 2.1 as a joint collaboration. Brought up over a year ago.

<steverep> Could the speaker please move closer to a mic?

Brent: We have pulled together a small group who realize this will be a heavy effort through April.

Sharron: We are in the middle of redesigning web site. Massive editing underway. 70-100 documents are in scope.
... We are ready to take this on. Next step: How are we going to work together.

<Zakim> bruce_bailey, you wanted to say that "required to ensure security" is one example of essential

DavidMac: We have the Understanding documents, which is about 1 page per SC. There are 23 SCs now in WCAG 2.1.
... Main thing we are missing now is techniques and failures.

AWK: Techniques and failures are out of scope.
... We have rough draft content, and none of it is finalized. We have to have new Understanding content. Must harmonize old with new Understanding content.

Katie: Based on Silver research on need for clarity, we are counting on EO to help with new Understanding content
... One SC we have to support speech users are videos created by KimP. We want help from EO on integrating this.

<Zakim> gowerm, you wanted to say that there were also questions about how this is an accessibility issue, as opposed to a UX issue

Sharron: We need to sync it up with formatting, etc.

KathyW: Request with Understanding: We need to add in mobile language to exisiting Understanding docs in 2.0.
... Can we have someone from EO group to partner? We'd like to walk EO through the intent of the relevant Understanding docs.
... We aren't as user focused with what we have now. It would be good to have a benchmark of how long each doc is and how much info is included.

AWK: The vision for the Understanding docs: moving out of TR space.

<Joshue108> sounds good to me Kathy.

AWK: Used to be updated every 18 months, now every six months.
... More frequent updates make it so there is very little change between update cycles.
... Hopefully, the AGWG might not be responsible for Understanding doc updates with help of EO.
... When we have 2.1, there will much more substantial comments coming in to our group. There will be a spike.
... We will have a GitHub repository to handle these comments. EO might be able to help with assistance from AGWG, such as joint task force.
... Both groups will need to work together. Both groups need one another.

<Zakim> yatil, you wanted to say writing style guide (draft) https://www.w3.org/WAI/EO/wiki/Style and to say understandable might have important impact on the guidelines

Eric: EO is developing a styleguide. https://www.w3.org/WAI/EO/wiki/Style
... EO is a really small group, so capacity might be limited due to size.

DavidMac: Perception is that WCAG is really long. EO management of Understanding document may change this perception.

<Zakim> Makoto, you wanted to say examples and readability of Understanding docs.

<Ryladog> Want to clarify my comment about Kim Patch's Single Character Key Usage for Voice/Speech Recognition Users VIDEO. The video is done, We would like EO's help in adding transcript and AD and including/housing it with the WAI Perspectives Videos so that we can point to it from the Understanding 2.1 document for the new Character Key Shortcuts success criteria.

<Ryladog> Success Criterion 2.4.11 Character Key Shortcuts. (Level A) [NEW]. If a keyboard shortcut consisting entirely of one or more character keys is implemented by the content, then a mechanism is available to turn it off or to remap it to a shortcut that uses at least one non-character key.

Makoto: We reviewed working draft of WCAG 2.1. It is difficult to understand intent of new SC. Readability is key. Must be able to be translated.
... Having graphic/working examples is very helpful for people who don't speak English to understand and translate documents into other languages.

<Sharron> ...could all Understanding docs have graphic and video to support non-English speakers like me.

<JF> +1 to Makoto

Makoto: I'd like to see easily readable documents including videos.

<Zakim> AWK, you wanted to speak to capacity issue and to also say that moving to dynamic updates will help support greater participation from external sources

<shawn> [Shawn notes that the Low Vision Task Force is working on more graphic examples and maybe video]

Judy: Andrew, I would encourage you to identify a clear contact for who is responsible for each piece of this collaboration.

AWK: I agree. We need to determine who is going to do what.
... There are people on the WCAG group who may prefer to work on Understading docs, so we have the capacity to help EO group out.
... Related to Makoto's point, adding all of the extra context (such as examples, videos) starts to get difficult. We may want to partner with exteral resources to help out. Hopefully the GitHub change will support this.

Sharron: Sometimes a video is worth a thousand words, so using this mode may reduce the length and complexity of written documentation.

<JF> +1 to sharron, with the additional point that those "thousand words" that is the picture doesn't really need translating ;)

Alex: How much shelf life will 2.1 have? If 2.1 shelf life is short, how do we optimize efforts with Silver Task Force? Don't want to do a bunch of work that is quickly outdated.

AWK: Work on this should be adaptable and repurposed.

<Ryladog> +1 to AG owning Understanding, EO helping to improve the langauge and help with visualizations

Shadi: Understanding documents needs a very close eye from the AGWG, even with a strong relationship with EO. Time pressure will limit what we can do in the short term.
... It's a good idea to port Understanding documents to non-TR format. Should be addressed after 2.1 is done.

<Zakim> bruce_bailey, you wanted to say that have Understanding on github really should be inviting

KathyW: Agree that AGWG should still own Understanding docs. EO can help us keep writing style consistent, which will help English and non-English speakers.

Bruce: Glad to move Understanding docs to GitHub. This will facilitate quick updates and contributions.

AWK: A concern to moving to GitHub is likely that we'll have more misinterpretations coming in, but on the good side, we can fix things faster. The benefits outweigh the detriments.

Shawn: Why would there be more errors? We can still have a good approval process that's shorter.

AWK: We make mistakes now. It's unrealistic to say that we can do things faster and not necessarily have more errors as part of the change.

Wilco: Moving to GitHub will facilitate collaboration with the open source community. GitHub use might reduce the number of errors.

<jnurthen> +1 to Wilco

AWK: We should add Understanding documents in the current mold until 2.1 is finished. What can we ask EO group to help out with?

Brent: We want to have good understanding with what is currently been drafted with 2.1 Understanding document. We want to figure out AG leads and process. What are the next steps for engaging the two groups to work together?

<Kathy_> https://www.w3.org/WAI/GL/wiki/Accepted_WCAG_2.1_SC

<Ryladog> Here is another example: https://rawgit.com/w3c/wcag21/concurrent-input-mechanisms/understanding/21/concurrent-input-mechanisms.html

AWK: Now we are in the draft stages. We have a WCAG 2.1 repository, including an Understanding section with 1 html file for each 2.0 and for each 2.1 SC.
... We have html file templates that structure the Understanding documents, including intent, benefits, resources, sufficient techniques and failures.

Brent: Is the intent to use the current structure and format?

AWK: We need to focus on staying in the same mold due to time and capacity issues.
... We can identify which SC are candidates for early work, and which ones should be addressed later on.

Katie: We have managers for each SC. Most SC have Understanding content drafted. It's really taking what's there and turning it into something that's understandable. Let's start on new SC, then move to old SC.

Sharron: How does the division of work between new and old Understanding docs impact consistency? Are we just looking for consistency right now in new SC?

KathyW: I would like to see Mobile coverage in existing Understanding docs.

Sharron: We completely agree with you on that.

AWK: Part of the gap analysis is understanding what is currently covered for Mobile.

KathyW: Some instances require a simple example be added, other instances will require more.
... We just haven't had time to do the work yet. Other task forces need to add their info into 2.1 Understanding documents.

AWK: What does the EO think about next steps? Should we set up a call?

Sharron: We know our core group who is ready to go.

Brent: We need a main AG contact as a starting point.

AWK: On the AG side, we'll likely be focused on SC and techniques. The Understanding content is likely ready to be picked up by EO group with assistance from AG contacts.

KathyW: Should we connect EO with task force coordinators?

AWK: Let's set up a time for a call.

DavidMac: We should work to share info on how GitHub is set up.

Brent: Do you have the list of more stable SC ready for us to review?

AWK: That's something that we can provide, but with some discussion beforehand.

Brent: It would be great to have a list of stable SC and places where Mobile info should be inserted as part of the initial call between our groups.

<AWK> AGWG needs to provide: 1) Best SC to start with 2) What additional additions to existing understanding documents 3) who are main POC

<Zakim> shawn, you wanted to plug https://www.w3.org/wiki/WAI_site_@_TPAC_2017

Shawn: If you are a SC manager, look at what we are doing with the WAI redesign.

Charlotte: Looking for people to give informal usability feedback for the WAI site.

gowerm: we need to summarize intent for EO group.

<gowerm> To clarify, I put in a Request for a Plain Language restatement of the SC language at the top of the intent.

<laura> no worries.

<Ryladog> test

<AWK> Web content allows the use of multiple input modalities that are available on a platform except where the restriction is essential, required to ensure the security of the content, or respect user or platform settings.

Concurrent Input Mechanisms

AWK: We talked about putting the language into multiple bulleted items.

JamesN: This seems completely untestable at the moment. Every single control needs to be available by multiple input modalities. Very hard to test every single control in every single state.

AWK: Could two inputs mean keyboard and mouse?

<Ryladog> Restriction is essential: bullet 1, required to ensure the security of the content. bullet 2, required to respect user platform settings settings. bullet 3, required to respect

JamesN: Yes.

Katie: Proposal (see IRC for content)
... I was going back to Bruce's point about "essential."

<alastairc> jnurthen wouldn't it be possible to run a script that highlights input-specific events, then test just those?

Shadi: I think if you are thinking about testing, you would need to do that manually if not an HTML component.

<Zakim> bruce_bailey, you wanted to say this is not so different than 1.1.1

Bruce: This no different than any testing. If you don't have any problems, such as testing for keyboard accessibility, then there's no problem.

JamesN: Events are all going to be at the page level.

<lisa> big change. apa droped the coga item. i am free at 1

<Ryladog> Suggestion: Web content allows the use of multiple input modalities that are available on a platform except where the restriction is essential. Essential Restrictions are: -- required to ensure the security of the content -- required to respect user settings -- required to respect platform settings

Jon_Avila: It's very difficult to try to capture where events are attached.

DavidMac: This was a late SC that came to the table by Patrick. Flickr was sniffing for touch, and determined that he didn't need to use a mouse (Surface device).

AWK: We started out with this issue requiring a mouse. We started out discussing this as general usability issue. Making it so that is finite (more testable) may be better due to testing constraints related to time and resources.

DavidMac: This issue came up on its own. Maybe we could pull this issue down to the limited context of touch screens where we don't allow disabling mouse use.

Katie: We need to continue to leave this open due to evolving APIs. Device-independent event handlers are being implemented in HTML5 and CSS. There's going to be a greater number of devices and event handlers.

AWK: There is a risk if we have nothing.

Katie: Should we have a list of things, but not limit it as being all-inclusive?

Wilco: It's not that its difficult to test, it's easier because there are tools that are being developed.

Katie: Other orgs are coming up with ways to test for this stuff, not just for accessibility purposes.

JamesN: We have to have specific hardware to test for this. You have to have a touch laptop.
... How else do I test it?

Wilco: You need to test on the device you support.

JamesN: If I have a page that's designed for touch and pointer, and I'll I have is a Mac, I can't test this.

<Zakim> JF, you wanted to respond to jamesn

AWK: If the concern is around testing, perhaps that is where we are seeking additional feedback. Could put it in the CR as "at risk."

<Ryladog> +1 to AWK about asking for feedback on ways and tools to test this...

JamesN: This might be an issue where folks will cross their fingers and wait until someone says its a problem.

<shwetank> +q

JF: There is problem, but we could hope that someone will have a touch laptop to test for usability at least.

DavidMac: It looks like this would be very hard to fail this. How would you fail this, passing 2.1.1?

<Wilco> +1 about David's "multiple" concern

<Zakim> gowerm, you wanted to say Testing is going to depend on the techniques that are created.

gowerm: in 2.0, there's a SC to test for keyboard modality. If we come up with tests that explicitly shows how to test for two different modalities, then maybe that's good enough.

<gowerm> As long as there are clear things a tester needs to do to sign off on the SC, it can be usable, then anyone who finds a failure of concurrent input has a place to fail it.

shwetank: Would it work to say don't allow intentionally restricting everything but one input modality?

<Greg> ...don't add the phrase, then should change "respect" to "respects" to match the singular "restriction".)

<Zakim> Wilco, you wanted to talk about "multiple" vs "restrict"

Jon_Avila: Concurrent is the important part of this: Allow users to freely switch between different modalities to interact with content.

Wilco: The point here is to not restrict input modalities. Why do we not want to say "don't restrict?"

Alex: It's hard to prove a negative.

<Zakim> Greg, you wanted to says the final clause would be more accurate to say "or required to respect", because lots of things respect settings in a way that has nothing to do with being

<Greg> “Web content allows the use of multiple input modalities that are available on a platform except where the restriction is essential, required to ensure the security of the content, or essential to respect user or platform settings.”

greg: proposal (see IRC)

<AWK> Web content allows the use of multiple input modalities that are available on a platform except where

<AWK> • the restriction is essential

<AWK> • required to ensure the security of the content

<AWK> • required to respect user or platform settings.

<lisa> back in

<Rachael> All functionality of the content is operable through a mouse and touch modality, except where the restriction is essential, required to ensure the security of the content, or essential to respect user or platform settings.

Rachael: Would "allow touch" and "allow mouse" be more straightforward?

<lisa> ah

<Joshue108> You could eat John?

<laura> Thanks.

<lisa> back

<lisa> just hearing static for now

<lisa> no, calling in

<lisa> can you hear anything Josh?

<lisa> ah..

<jamesn> scribe: jamesn

concurrent SC

<AWK> "Web content allows the use of multiple input modalities that are available on a platform except where

<AWK> • the restriction is essential

<AWK> • required to ensure the security of the content

<AWK> • required to respect user or platform settings.

<AWK> "

AWK: Current language above
... concerns that saying multiple doesn't do anything
... all would be better for what is meant

<AWK> Web content allows the use of all input modalities that are available on a platform except where

<AWK> • the restriction is essential

<AWK> • required to ensure the security of the content

<AWK> • required to respect user or platform settings.

Kathy: suggested change was to go back to original language and make AAA

AWK: Is this something people could support?
... retains core intent and allows testing tools to support it
... does anyone have concerns about that approach?

Kathy: The input modality is essential

<Ryladog> Web content allows the use of multiple input modalities that are available on a platform except where the restriction is essential.

<Ryladog> Essential Restrictions are:

<Ryladog> -- required to ensure the security of the content

<Ryladog> -- required to respect user settings

<Ryladog> -- required to respect platform settings

DMD: had an SC where everything has to work with a pointer device. This requires everything else too... this is much wider. Couldn't get the pointer device one through.

Kathy: there is the exception where if everything is required. There is an exception in the first bullet

<AWK> Web content allows the use of all input modalities that are available on a platform except where:

<AWK> • the use of a specific input modality is essential

<AWK> • required to ensure the security of the content

<AWK> • required to respect user or platform settings.

<alastairc> (pre-typing my point) - how does an author know about the platform? We have a multitude of devices/platforms/inputs, as an author I *cannot* know what the user has. What is in my control is the scripted events used, not what the user has.

Alastair: 2.0 avoided putting user agent stuff into the SC

AWK: we did for keyboard access
... you need to have a claim that you have accessiblity support
... and in your conf claim you need to indicate the technologies you rely upon
... for this not to move to AAA will require substantial editing.

<alastairc> greg: platform is used very little, just two uses in the new mobile SC from what I can see?

AWK: at the same time - recognise that it is important that content support all the modalities it can

JW: technologies relied upon are web technologies that is not a restriction on the user agents that could be used or the modalities that could be supported
... think the word allows and allows all suggests that the content author need proivide positive support for input modalities on a platform

<Greg> Alastair, that would make it an easy change, although there may be other SC where a similar issue comes up (e.g. supported user agent").

JW: that is complex - when we last discussed there was controversy as to whether On screen keyboards needed to be provided

<Greg> s/(e. g. supported/(e.g. "supported/

JW: that kind of poisitve statement challenges the testability of the proposal
... prefer the language in the current PWD which seeks to ....
... without specific provision being made in the content
... more readily testable

<Ryladog> Web content allows the use of multiple input modalities that are available on a platform, except where a restriction on the modality is essential.

<Ryladog> Essential Restrictions are:

KHS: pasting in some language

<Ryladog> • required to ensure the security of the content

<Ryladog> • required to respect user settings

<Ryladog> • required to respect platform settings

Kathy: mutiple is not going to work

<Zakim> bruce_bailey, you wanted to ask about using WCAG 2.0 style conformance claims as a way to test SC?

Kathy: Jason talking about restricting - prefer going back to that

<Zakim> Greg, you wanted to suggest that we use the term "supported platform" throughout the document, and define that as platforms listed in the conformance claim. It would not be a

BB: need to keep in mind accessibility supported. Trying to write a conformance claim doesn't really help us

<alastairc> Would rather something like: "Web content does not restrict the use of input modalities except where ..."

<Greg> We should address an ongoing source of confusion. It would help if we could use the term "supported platform" throughout the document, and define that as platforms listed in the conformance claim. It would not be a substantive change, but would make the current meaning more obvious to readers, as currently it is the source of much confusion--even in the working group.

<Greg> Also, you dropped the "or"; you need to explicitly say "all of ... and" or "at least one of ... or".

<alastairc> I think we need to avoid 'platform' if possible as WCAG 2.0 did. The benefit of 'content' guidelines is that they are testable in the content without a specific user-agent.

AWK: OS , user agent and AT - expressed in the conformance claim

<Greg> We may be able to copy the definition of Platform from UAAG.

<Greg> Personally I don’t see a problem with “all” modalities supported by the platform, given that it is not hard to enumerate the input modalities supported by the claimed platforms.

<Greg> Also, it would help considerably to have a list use cases demonstrating behaviors we want to prohibit and others we don't want to fail. Do we have any? (There's nothing in Understanding yet.)

KHS: vital that we need to fall back on accessibility support - can say at least 2 modalities or at least 2 or 3 - or device independant event handlers

Kathy: 2 modalities on the device. could still use keyboard and touch

JW: per greg's proposal. difficulty is that it requires .... don't think it is a good tradeoff

<bruce_bailey> Here is Katie's proposal:

<bruce_bailey> Web content uses device indepent device handlers or allows for the use of at least two input modalities.

JW: the accessibility problems haven't been well defined. switching modalities (can go from modality a to modality b) part way through the interaction in the circumstances where they could have started with b
... on the other hand we have a desire in some quarters to require UIs to be operable with all modalities... not sure what the author responsibilites are
... the right approach is which of the use cases should be covered by this proposal
... different modalities ... positively supported by the author ... perhaps easier in silver

AWK: not feeling like we have consensus here to resolve comments or change SC text.
... straw poll

a) Leave open for future work

b) accept one of the versions at AAA

DMD: have never really run up against this being a problem
... so i don't know what the problem is
... I know where this came from.

AWK: do we have other examples contrived or real which this solves

<KimD> +1 to keeping "old" language (pre today's edits) and move to AAA

JA: in theory this is important - but don't have time to get it where it needs to be

<Ryladog> a

<Kathy> b

<Rachael> a

<alastairc> Greg: b

<Greg> a

<Wilco> a

<maryjom> b

<Alex> b

<jon_avila> b

<JF> b

<Brooks> a

<Makoto> b

<KimD> b

<marcjohlic> b

<david-macdonald> b

<Greg> Alastair, whoever you heard was not me voting b.

<bruce_bailey> b

<alastairc> Sorry Greg, I think I started typing something else, then put b, that was my B.

<bruce_bailey> My try:

<bruce_bailey> Unless a user makes a setting to the contrary, Web content allows the use of touch and pointer input modalities that are available on a platform, except where a restriction on the modality is essential.

<bruce_bailey> Here is a version for JF:

<bruce_bailey> Unless a user makes a setting to the contrary, Web content allows the use of all multiple input modalities that are available on a platform, except where a restriction on the modality is essential

DMD: can anybody not live with AAA with the unrestrivted language in the current draft

AL: I think the problem is so rare that we have already reached the point of diminishing return

RESOLUTION: Move Concurrent input to AAA

<david-macdonald_> scribe: David-macdonald

<david-macdonald_> awk: Rachel has some suggested language and comments

<Greg> David, mark the new topic?

<david-macdonald_> 20 hrs vs 24 hrs

<bruce_bailey> @David, write TOPIC:

<lisa> i looked at the summary

<Rachael> https://www.w3.org/WAI/GL/wiki/2.2.8_responses#Proposal

<david-macdonald_> Rachel: i'll run down the summary of issues. its in irc

<AWK> https://www.w3.org/WAI/GL/wiki/index.php?title=2.2.8_responses

<david-macdonald_> first issue, u of mass... thinks it shou'd be AAA

<david-macdonald_> comment about logout...

<david-macdonald_> rachel, my proposal by a definition of user activity.

<scribe> scribe: david-macdonald

<lisa> i can hear about every 3rd word

awk: not clear to everyone "enough time" SC in 2.0

banking site, don't touch keys mouse for 3 minutes, we'll log you out.

they could either save all data, or just say we'll time out on this interval

lisa: I like directin

<Ryladog> +1 to this new proposal for AA

20 hrs better for standard worse for user

<david-macdonald_> scribe: david-macdonald_

lisa: easier to say same time tomorrow rather than same time tomorrow minus 4 hours.

<Zakim> KimD, you wanted to ask about situation where all activity occurs in AT buffer, so user may be active w/o being recognized by browser

<lisa> we want people to be able to stop for the day, have a nice supper, pick it up tomorow

kim: just trying to understand. what kind of users will be affected?

<lisa> well peaple with LD or autisim

<lisa> when you are tiered your skills gets much much worce\

<lisa> and you need to take a brake

<lisa> sometimes you just need a hsort brake, have a cup of tea and then carry on

<lisa> but with autisim it is usealy the next day

brooks: would there be confusion by users about the timeout being about inactivety or just using the contact

awk: not a problem.

<lisa> tax returns

<lisa> is a good example

<lisa> any goverment service

<lisa> people with autism will need a longer brake then 12 hours

JF: trying to imagine a situation where I'm going to be in session for 24 hours, as to whether easy calculation perhaps 12 hours. i can't imagine a scenarionwhere someone will be in a system for 20 or 24 hours.

awk: that 24 hours is for how long the data is retained...

<Zakim> JF, you wanted to ask about 12 hours instead of 20 or 24...

lisa: would like more than 12 hours... they quit for the day and want to come back tomorrow.

<jon_avila> lisa would it help if the system actually gave the the time such as 2pm tomorrow?

<lisa> often that day yes, if you are warned then you know

only lose information. in state... in security situations 12 hrs would even would be too long... they will be save, write to database

<lisa> or you can at least decide not to do it

awk: anyone have an idea of oreserve data vs, leaving the session open.

<lisa> but if i know i cant fill in the form that at least i know to sto[p

<lisa> happens to me all the time...

JF: can't think of situation where an authenticated state would be left open for long.

awk: would we be better to just warn.

<johnkirkwood> Want to ensure addressing cognitive overload by letting user know that a form timeout

<johnkirkwood> By letting the user know upfront

Lisa: I'm ok... it drives me mad to not know how much time I have of inactivity.

the warning helps a lot

Rachael: tax form. is saved indefinately, a year.

jason: in the second conjuction, until the user reestablishes an authenticated session

alex: for security reason, the timeouts can be dynamically generated based on threat level, not a soecific time, based on machine learning, may not be able to give you heads up.

david: concerned that people will be confused about how much time they have to do the activity instead of how much inactivity

lisa: i prefere that we don't go with 20hsrs but if it makes a difference with level I could live with it.

jf: second clause still requires that it be saved.
... on the server side you are still going to have to save the data

rachel: turbo tax autosaves...

brooks: would there be a problem, user has a bad day, rage post, wander take a nap. they want to delete

awk: broad consensus for first phrase barring alex's concern about machine learning
... exception. if the length of inactivity changed, the user is notified.

lisa: I could live with this.

<Zakim> Wilco, you wanted to ask if having a user submit a draft is sufficient

<johnkirkwood> user inactivity timeout period may change for your security purposes

wilco: would it help if we explicitly require a save button.

bruce: Alex's scenario can be addressed in the understanding. 2.2.8 could be really short.

<AWK> 2.2.8 Where data can be lost due to user inactivity, users are:

<AWK> * warned at the start of a process about the length of inactivity that generates the timeout

<AWK> * notified if the length of inactivity changes during the session.

<AWK> * unless the data is preserved for a minimum of 20 hours of user inactivity or the data is part of the log-in process.

alex: I'm fine with what you have... warned start of process, notified if inactivity changes.

<AWK> (Level AA)

<lisa> +1

<Rachael> +1 AA

<johnkirkwood> could we use the word “notified” instead of “warned” for the furst bullet?

<johnkirkwood> furst/first

jf: i have concerns with it also at AA

<lisa> acl l

jonathan avila: it says lost data, don't we want to say timeout.

bruce: length of inactivity that can cause loss of dat

james: what is the start of a process

awk: if you start a timer you know the start

jf: i'm concerned about 3rd bullet

<lisa> 3rd bulet only makes it easier to conform

alex: i'd much rather not have it at AA

<AWK> 2.2.8 Where data can be lost due to user inactivity, users are:

<AWK> * notified at the start of a process about the length of inactivity that will cause data loss.

<AWK> * notified if the length of inactivity changes during the session.

awk: they ca put the notification anywhere on thenpage, but many situations will put it somewhere useful when there is reaoestate.

<Rachael> User Inactivity: Any continuous period of time where no user actions occur that trigger tracked client or sever activity. The method of tracking will be determined by the web site or application and should be consistent with the way the site or application determines time outs. Include in Understanding/Techniques Document

akex: notified at start of process is too vague

<Jan> The "process" is linked to the gathering of some kind of data

jason: warning of the change of timeout could notify bad guys

<Greg> Could simply saying "*estimated* length of inactivity" get around Alex's concern with the original proposal? That means estimated at the start of the session or activity, so acknowledges that it's subject to change, and also that it's not necessarily exact due to other factors.

<Greg> The second bullet is ambiguous: we want to make it clear that it does not mean showing a count-down timer that must be updated continuously as the *remaining* time decreases. Perhaps say “total time of inactivity” and elaborate in the Understanding document?

<Greg> Also, Once again it should be explicitly say “at least one of the following:”. Definitely needs grammatical editing.

<Jan> -q jan

awk: estimated time... don't know the answer

<Zakim> Greg, you wanted to say Could saying "*estimated* length of inactivity" get around Alex's concern? That means estimated at the start of the session or activity, so acknowledges

<Zakim> gowerm, you wanted to say "where data can be lost" is up to interpretations and to say this seems to be creating a May Contain Peanuts scenario

lisa: gives more opportunities to write techniques...

michael: we put this a triple A ... we are trying to wordsmith it and move it to be required at AA

the requirement to have warning on pages, massive about of pushback for sinple forms

<AWK> does the 4 field form implement an inactivity timer?

on the other hand complex screen, how invasive will they be...

jf: clarity, have we dropped third bullet?

awk: haven't concluded but are quering..

<marcjohlic> Following to Mike's comments - same concern here.. Can we qualify this SC (especially if we're talking AA) with some criteria similar to 3.3.4?? Something like " pages that cause legal commitments or financial transactions for the user to occur"

david: time outs are on the back end. front end devs may not have access to that information so wouldn't know what to put in that message

Glenda: That's right, I sometimes wait for weeks for front end devs to figure it out time outs

<Zakim> KimD, you wanted to say not all customers have the same time-out

<Zakim> marcjohlic, you wanted to say Following to Mike's comments - same concern here.. Can we qualify this SC (especially if we're talking AA) with some criteria similar to 3.3.4??

kim: I think for end user could be complicated
... think it should be at AAA

marc: at AA would need qualifiers on legal of financial.

awk: can we go with AAA, with 20 hours, new bullet on if timeout changes.

<marcjohlic> +1 can support at AAA, but would still prefer it to have qualifiers of legal, financial, and data - similar to 3.3.4..

alex: neet to define when the process changes

JF: WHEN THE PROCESS STARTS

<bruce_bailey> Here is an excerpt from 2.1.1 (A):

<Rachael> scribe: Rachael

<bruce_bailey> If a time limits is set by the content, the users is warned before encountering it.

<bruce_bailey> Here is the excerpt with a qualifier:

<bruce_bailey> If a time limit [that can lead to loss of user data due to user inactivity] is set by the content, the user is warned before encountering it.

AWK: We will finish Time Outs in 15 minutes

<AWK> User Inactivity: Any continuous period of time where no user activity occurs. The method of tracking will be determined by the web site or application.

AWK: Proposed definition is above.

JF: the method of tracking user inactivity will be...

<AWK> User Inactivity: Any continuous period of time where no user activity occurs. The method of tracking user inactivity will be determined by the web site or application.

James: Question, if I choose to track user inactivity as only the time you hit the letter a, then that's ok?

AWK: Yes, not smart from a business sense, but ok

Jon_avila: Is the word tracking going to be problematic?

AWK: we could use monitoring

Kim & AWK: clarify that this is a definition

Bruce: The format is not typical for WCAG definitions. You should be able to substitute it for the term.

AWK: I think that is no longer true.
... Should the second part be a note?

General agreement

AWK: We have proposals for a version of the SC that will work.

<AWK> 2.2.8 Where data can be lost due to user inactivity, users are warned about the estimated length of inactivity that generates the timeout.

<AWK> 2.2.8 Where data can be lost due to user inactivity, users are warned about the estimated length of inactivity that generates the timeout unless the data is preserved for a minimum of 20 hours of user inactivity.

<AWK> 2.2.8 For each user inactivity limit

<AWK> set by the content, users are warned in advance about the duration of inactivity allowed and what happens if the limit is exceeded.

AWK: The third would mean that the site could tell the user more details such as that the data would be lost or kept.

More in line with 2.0. Tells the user what the length of inactivity is and what will happen

Lisa: I like the third but I think we need a limit so people have an alternate where they don't have to bother the user because they are holding onto the data for a reasonable amount of time.

AWK: Do you need to logged in?

Lisa: No

AWK: If you are not logged in, how do you get back to the data? You will have to do something to get back to the data.

Lisa: You haven't closed your browser.

If you closed your browser, that is on you.

AWK: What if there is a save as option?

JF: Where is it being saved?

Lisa: Give it a name and save the session on the server. Session variable

Glenda: We have 4 minutes

<lisa> https://www.w3schools.com/php/php_sessions.asp

<marcjohlic> Option 1 - AAA - Keep it simple..

JF and Lisa: Discussion of session saving.

AWK: Does anyone know more about session time outs?

James: Its not quite as simple as saving to a session variable. Most time out in less than 24 hours. Possible and people do it for all sorts of reasons but its not simple.

Wilco seconds that

AWK: What do we want to do?

<gowerm> The original text, changed to 20 hours. No need for bullets

<Zakim> gowerm, you wanted to say that Timing Adjustable seems to already meet some of the new language and to say that Timing Adjustable seems to already meet some of the new language

<Wilco> All 3 work fine as AAA

Lisa preferrs the middle one.

<gowerm> The original text, changed to 20 hours, with definition of user inactivity. No need for bullets.

<Alex> option C for AAA

<JF> Option C @ AAA

AWK: The third gives more latitude. The middle one provides two options: Tell in advance or preserve 20+ hours

<marcjohlic> Option A @ AAA - keep it simple

Kim: If the help documentation tells the user about the timeout, is that enough?

We are not specifying how users are warned.

<Brooks> Option 1 @ AAA - make it clear what the best practice is

I think we need to clarify this in the understanding

AWK: WE can clarify it in understanding

gowerm: I think the original language covers it. They key thing is warning the user about the time out. as a AAA it seems reasonable to me.

AWK: Also you had mentioned a login process and we struck that.

gowerm: You can add that login doesn't involve loss of data in the understanding

AWK: Ok.

Is there any objection to the second item:

<AWK> 2.2.8 Where data can be lost due to user inactivity, users are warned about the estimated length of inactivity that generates the data loss unless the data is preserved for a minimum of 20 hours of user inactivity.

<AWK> At AAA

<bruce_bailey> +1

<gowerm> +1

<johnkirkwood> +1

<david-macdonald> +1

<Alex> 0

<JF> 0

<Kathy> +1

+1 though I'd still like to see it at AA. AAA is better than nothing.

<Wilco> +1

<Makoto> +1 at AAA

<lisa> +1 though I'd still like to see it at AA. AAA is better than nothing.

<jon_avila> +1

<Greg> 0

<marcjohlic> +1

<Jan> +1

<jamesn> +1

<KimD> +1

<Brooks> +1

RESOLUTION: Accepted as amended

<bruce_bailey> https://w3c.github.io/wcag21/guidelines/#target-size

AWK: Moving to Target Size

#559 Use of plain text links is prohibited? Suggested response is that they are not prohibited but that you add padding.

Kim: There is padding, we have an example, but this AAA

JF: If it is the same example, then you end up with overlap during resizing.

Kim: Correct. You can have text links but not close together.

AWK: You can have more line spacing or larger text size but it is difficult which is why its AAA

JF: Footer text on banking site, the links have to meet this?

Kim: At AAA yes. At AA, no

Jon_avila: Through user agent control is it exempt?

Kim: Its exempt at AA.

If no customization what-so-ever, including color, then its exempt.

AWK: Putting together word document with proposed responses.

David: Its not doable. To me its not realistic. We are just stating this and it undermines the value of the other AAA.

Kim: I think you can have a site where you have all of them. You have to limit the links that are nearby.

Andrew: Its tricky with a paragraph that had multiple links.

<Zakim> Wilco, you wanted to talk about how this effects other criteria

Kim: If we want to restrict it more we can apply what we did with Zoom

Wilco: This seems completely unfeasible to me. Or you need a really high line height, much higher that the other line height specification.

Kim: We are balancing end user need with what is feasible.

At AA, I'm not sure we're helping any users.

AWK: If that is true, than we shouldn't include this.

Kim: Yes, there is limited benefit.

James: the Extra padding is interesting because if you put too much extra padding on, it can cause problems for other users.

<Zakim> steverep, you wanted to say that I will not go along with any responses or techniques suggesting that extra padding and negative margin is an acceptable way to meet the SC even at

AWK: Steve is on queue and then I'd like to skim through the rest of the comments.

Steve: I will not go along with any responses or techniques suggesting that extra padding and negative margin is an acceptable way to meet the SC even at AAA. There are issues with focus and overlap that have been brought up over and over again.

AWK: Same concerns as Wilco. The issues we have for this include: Maybe plain text links should always be allowed. in page and inline are similar.

Kim: They are distinct.

James: What is the use case for in page exception?

Kim: You are not relying on that for functionality because you can always scroll down.

James: Now you are talking about functionality. Can we word it to get rid of that?

What if there were four buttons that do the same thing but 3 are ok but 1 isn't. Then what?

Kim: We had an exception for that. Only 1 button.

James: Can we say "All the functionality has to have the correct target size..." and then we get rid of two exceptions.

AWK: Lets keep going. Public comment: Target size is very difficult to test. Agree useful best practice.

Kim: We are using CSS pixels

Glenda: Is it time consuming?

Kim: It can be tested with a script.

James: how do you know what is activatable?

Kim: There is the possibility that some items will not be identifiable.

James: I have a larger item with an onclick event with a keyboard accessible smaller button inside. How do you know the larger area size?

Kathy: Sribe has been messing up. All Kathyshould be Kathy
... Research paper on user's ability to touch things. What makes it touchable?

AWK: I am wondering how far the human interface guidelines for google, apple, MS, etc go

Kathy: We also got university touch studies.

David: If we don't have something about target size, there will be some who will say we are deficient. Its a bit part of mobile. The exceptions were well thought out.

for people w/ dexterity problems, they really need 100 px.

<jamesn> BBC guidelines state: Provide padding around links to ensure all actionable controls are at least 7mm across. Use larger controls, i.e. 9mm, or increase the padding around the content to ensure a large touch area.

<jamesn> 7mm is 26px

We aren't going to hit that crowd. WE're making it better for people with mild spasmatic behavior. I'm in favor of the success criteria. The AAA is difficult. We could say user interface components are 44

Something tat is not links.

<Zakim> Wilco, you wanted to ask about an exception if the space isn't available

<jamesn> http://www.bbc.co.uk/guidelines/futuremedia/accessibility/mobile/design/touch-target-size

<lisa> it is nearly 3 am here. Any chance of doing more coga stuff or should i go to sleeeeeep

Wilco: Was it considered that if the space isn't available to have it smaller?

Kathy: That is why the 5 links are there.

Wilco: that is one example. What about others?

James: I've seen BBC cited. They are 26 pixels for links

<lisa> ok..

AWK: WE haven't excluded all text links

David and AWK: Discuss in a block of text exemption.

Kathy: Its been added and removed.

AWK: last comment. Multiple items reviewed.
... A lot of challenging comments. Recognize this is important. BBC has a best practice instead of a standard.

What do we feel that we can do that is testable and doable?

Wilco: I think 44 height is only doable if that is available in the UI. Otherwise, its too high

AWK: Does the reflow and zoom support this at all?

Kathy: No

Jon_avila: We should try to work some exceptions in but I think should try for AAA

Bruce: IF that is too high, can we pick a lower number?

John: 18 is standard, 26 would be reasonable

Kathy: There was a reasoning for doing 22 instead of 26. we could do 44x22 but not specify dimensions so we support other languages.

Jason: We have a complex set of comments. The underlying concern is that the more exceptions there are.. we already have 7. That has to be a record.

The more exceptions, the less the benefits

The real solution is to have technologies to solve the problem on hte user agent side.

So when the approach it, they enlarge it. This is something that needs an assistive technology solution. We still need good defaults.

Kathy: There are a lot of users who will benefit who don't have AT

James: What Bruce said.

Kathy: If we change it to 44x22 can we remove some of the exceptions and leave it at AA?

Adding more exceptions makes it pointless and harder to test.

Glenda: we need automated testing.

<AWK> ack kathyq?

Kathy: If we take 44x22 and review exceptions and see what we can remove

Crystal: I'm curious about hte 44 pixels. In the office button we solve this not by enlarging the button but by adding padding.

AWK: Is the padding interactive in the office example?

Kathy: Yes

Crystal: Its an interesting experience.

Kathy: You switch the office to the touch mode. WE can go back to spacing. It was taken out the first round of review.

It was an option but it was removed.

Kathy: The size of the target for pointer inputs is at least 22 by 44 CSS pixels except when:

Customizable should say.

Wilco: Is this handled through conforming?

AWK: We should look at conforming alternate version as an option.

Kathy: The 2nd one is equivalent. We likely keep that in.

AWK: When it says the target is available. It sounds like the target itself.

Kathy: The function is available through an equivelent link or control on the same page that is at least 22 by 33 CSS pixels

Essential: Keep that

AWK: Something like a footnote could have trouble. Very short links would have the height but if it has one or two letters.

Kathy: so we keep in-page links

AWK: Inline. How many characters would it take to get to 44 pixels?

Alex: That won't work so well with Chinese

Kathy: sounds like we can't remove that one either
... Grouped can be removed. We just changed that one.

User agent control: leave that one in.

AWK: Targets that are text links must have at least one dimension that is the lower bound.

So one dimension would be 22 pixels

Kathy: We really don't get rid of the complexity.

Do people feel better about it being AA if we make it 22x44?

General agreement.

Glenda: Step in the right direction.

Kathy: Does anyone have an objection?

AWK: Is it better to say Text links should have a lower amount? Then we reduce the pain of exceptions.

Kathy: We could combine inline and in-page

Text links could also address menus.

Alex: If you look at Word, there are triangles. That is not going to be big enough. Do I need an equivilent way of doing that?

Kathy: Yes

So it would fall under an exception.

Crystal: You mean another way to set bullets or change the target size?

Kathy: To change the target size

Alex: the mechanism is not to change the target size but to change the bullet in a way that meets the target size.

Kathy: Yes.

AWK is editing on Wiki.

<AWK> https://www.w3.org/WAI/GL/wiki/WCAG_2.1/targets

AWK: Width or height vs any dimension. Diagonal is not an OK measurement dimension

Current proposal:

The size of the target for pointer inputs is at least 44 by 22 CSS pixels except when:

Customizable - A mechanism is available to change the size of the target independent of the level of page magnification;

Equivalent - The target is available through an equivalent conforming link or control on the same page;;

Essential - A particular presentation of target is essential to the information being conveyed;

Text links - The target is a text link with a size that is at least 22 pixels in width or height;

User Agent Control - The appearance of the target is determined by the user agent and is not modified by the author.

AWK: Discussion of conforming.
... Example: a widget to adjust target size similar to ones that support text size.

David: we don't have an exception in 1.4.3 for a high contrast button which we recommend. I rely on the conforming alternative language. I think this falls in the same category.

Kathy: In that case, we have a technique so we could add it to the understanding and technique

James: If an exception is not explicit it doesn't exist.

Jon_Avila: WCAG says you can have a conforming alternative.

AWK: So you are saying that we don't need equivilent as well?

Discussion about whether Customizable and Equivilent can be removed or just costomizable

David: Position is an important part of links so I wouldn't count that.

AWK: So all the big links are at the bottom?

David: If you pull out customizable you only have 4 exemptions

<Zakim> AWK, you wanted to ask if a web page without CSS containing links would pass

AWK: Can we get rid of Customizable?

Jason: No

It should be solved with user agents

The burdens don't need to remain on the author

Kathy: I think we can take it out.

Bruce: If you take it out, then zoom can meet the success criteria

AWK: If zoom is independent of the page, that is why it doesn't meet

Jon_Avila: We havent said to date that users can meet contrast with a custom stylesheet so this shouldn't work differently.

Kathy: It is clear having it in there.

Alex: If all the OS and User agents supported zoom, what is the problem? Why would I need a floor?

Kathy: If there is a mechanism in the user agent independent of magnifying the screen, you wouldn't need this.

The target size has increased independent of magnifying the screen.

David: If you take it out, then zoom meets this.

<alastairc> The only real method of testing the size of web content is using CSS pixels, which are unchanged by zooming in.

<alastairc> I.e. zoom does not help.

Jon_avila: the problem with zoom is that there isn't a responsive view to mobile. I support not zooming.

Why do you need the second bullet?

Jon_avila: I don't think we need it. Its already covered.

AWK: Reading conforming alternate version

Bruce: We've discussed this.

<Zakim> Rachael, you wanted to say Can we add without zoom to the top statement?

David: We've used conforming alternate language. Its technically a different page but in the trenches.

Rachael: The size of the target for pointer inputs is at least 44 by 22 CSS pixels without zoom except when:

AWK: Thoughts?

Kathy: Then Customizable becomes a conforming alternative. The requirement is you do it without zoom right in the SC text.

Then can we take out the next one?

General no

James: The language does not allow a conforming alternative on the same page.

<alastairc> If you measure in CSS pixels, the measure does not change when you zoom!

Kathy: That is why we used CSS pixels

General consensus: That needs to go in understanding

Alex: Is there a date picker that conforms with this?

Kathy: Its the same with a keyboard, piano, etc. They are all known entities where the layout is required so exempt under Essential.

Alex: I'm having trouble justifying the date picker.

AWK: Color picker, piano layout, onscreen keyboard, etc.

Kathy: These are exempt under Essential

Alex: If I have a table of any kind, then its exempt.

AWK: Those can expand. The table can be larger.

Alex: Then you run out of real estate.

AWK: We've made substantial changes and I'm not hearing complete and utter comfort but more so than we had before. That might get us to another working draft on this if not CR.

During that time, we need to be thinking of what ifs.

AWK: In understanding conformance, Alternatives can be provided on the same page...

If you're doing that, what do we have to do to make it clear that something is the conforming alternate version?

Jon_avila: nothing. We don't require that label on the conforming alternate page.

General agreement that it should be

AWK: We can remove it.

Kathy: We should put it in understanding.

<AWK> proposal to put "Equivalent - An equivalent and conforming target is available on the same page;" in understanding

David: I want to put it in queue that I think at AAA level we should roll back what we had in AA to AAA.

Alex: I want it clearly in the text that just because someone found something small, it isn't an issue.

<JF> +1 to Alex

This is normative and understanding is not.

General agreement to keeping it in. Conformance is not always brought in.

<Zakim> bruce_bailey, you wanted to comment on Alternatives can also be provided on the same page. For example creating an equivalent to a user interface control.

Bruce: That isn't about a conforming alternate version Its about conforming. I'm sympathetic to what Alex is saying. I suggest putting it in as a Note. More obvious as a note than in understanding. Because its established in conformance, I'd rather it not be in the exceptions.

If we include it, we should add it to every SC.

<maryjom> +1 to Bruce

+1 to note

<Jan> +1 to note

Alex: I can't accept it as a note.

Not all standards have pulled the notes

Bruce: We can't stop governments from doing the wrong thing.

<lisa> should i call back in or are we rapping up

<AWK> https://www.w3.org/WAI/GL/wiki/WCAG_2.1/targets

<lisa> thanks. it is 4 am here..

<lisa> good night all

RESOLUTION: Accepted for next draft https://www.w3.org/WAI/GL/wiki/WCAG_2.1/targets

AWK: If we don't address all comments, can we release the next working draft?

<steverep> Waiting on queue... not sure what amendment is

Michael: The process does not forbid us to release the next draft without addressing all comments. The issue is down the road. It won't be the last working draft so we slip

AWK: What do we have that we don't have comments that need to be resolved. What does that look like? How do we get more of the ones with comments in there.

Michael: You want a working draft with only SC without comments?

AWK: WE can only put out what we have consensus on. We can either get consensus or remove the items

Michael: That won't work because there may not be consensus to remove

JF: Can we do an up/down vote on which to remove?

<steverep> Saw the draft. I will be objecting. Sorry.

AWK: We would not have unanimity but may get consensus?

Michael: Another option that I don't recommend is to skip the next draft but still publish in January

JF: There is a huge risk to that

Can we divide up into groups?

Michael: Team A, Team B, Team C. It wasn't ideal but worked.

AWK: We did that for 9 months.

Can we divide into groups tomorrow?

Majority of folks are here tomorrow.

Michael: Sign up as a break out session.

AWK: Break out tomorrow and get further progress on ones that remain
... Conclusion: Break out tomorrow. Information coming

- DRAFT -

Accessibility Guidelines Working Group Teleconference

07 Nov 2017

Attendees

Contents

Processing Comments

Interruptions Minimum

Character Key Shortcuts

EO and AGWG

Concurrent Input Mechanisms

concurrent SC

Summary of Action Items

Summary of Resolutions

Scribe.perl diagnostic output