<Joshue108> zakim agenda?

<AWK> +AWK

<AWK> trackbot, start meeting

<trackbot> Meeting: Web Content Accessibility Guidelines Working Group Teleconference

<trackbot> Date: 30 August 2016

<KimD> +KimD

https://www.w3.org/WAI/GL/wiki/Scribe_List

<scribe> scribe: marcjohlic

TPAC Agenda (https://www.w3.org/WAI/GL/wiki/Meetings/TPAC_2016)

<Joshue108> https://www.w3.org/WAI/GL/wiki/Meetings/TPAC_2016

JOC: Have a basic agenda loaded into the wiki page
... Meetings going from 8:30A to 6P (local time). Lunch will be provided
... Logistics, greeting, getting wifi going: .5 hr Review COGA SC Proposals - 1.5 hr Review MATF SC Proposals - 1.5 hr Review LVTF SC Proposals - 1.5 hr Work on 'Silver' - 3 hr DPUB meeting - 1 hr ACT TF meeting - .75 hr New SC numbering methods - 1 hr New Charter - .5 hr
... Potential other topics: GitHub process for WG members

WCAG 2.1 requirements/progress

Soliciting wider review of our work.

scribe: Have not actually allocated days yet, but would like to hear from folks whether they have other meetings they need to attend etc?
... How does group feel about this agenda?

<Zakim> AWK, you wanted to comment on silver meeting timing

AWK: Had a call w/ Silver subgroup. Looking at a 3 hour time - tentatively targeting Tues AM as a time for that. Soft stake in the ground. Don't want to have it Monday morning.

JOC: OK let's stick that in for Tues. Adding to the wiki now. Silver Tues AM

JF: Looking at the agenda - see review of COGA, MATF, and LV - put aside 4 hours and WCAG 2.1 progress. Is that different? Or part of the 3 proposals? Curious to know where we are

JOC: The 2.1 item would be any other business around requirements. The first parts are the TFs

AWK: In terms of where these are being collected: the idea is that they will be collected in GH 2.1 repo as Issues. By Dec 1st we expect that we'll have some in there. Not all, but some. Dec is the target.
... The other item would be around other topics related

<davidmacdonald> test

JF: The question is: you have WCAG 2.1 requirements/ progress - and the TFs above. What is the difference?

AWK: The reason 2.1 progress / reqs is there - there is a document that we need to publish as a Note wich is the WCAG 2.1 reqs document. We can't publish a WCAG 2.1 draft yet. We've done a lot of work on the reqs document, but to wrap it up more that's something we'll have to spend some time on at the meeting

JF: Will be there the entire week - but spreading time across several activities

DM: Will we talk about DPUB?

JOC: Yes, DPUB will come in and talk with us.. As will Automation group

JF: Any discussions with EO?

AWK: We will - not on the list. Will add to the wiki now. Have been talking w/ EO about meeting.
... Suggest putting DPUB or ACT meetings at a time where they aren't in the middle of say Silver discussions - but other than that pretty wide open for scheduling
... We'll have 7 hours of working time (excludes lunch and breaks) and we have 11.25 hours of topics on the agenda
... Are there topics that are of greater interest to folks? Or topics we're missing?

JOC: Next week we'll have an actual schedule. A lot to do - bit of a marathon session.

Publication of Techniques and Understanding Documents (https://www.w3.org/2002/09/wbs/35422/fall2016pubs/)

JOC: We have new Techs and Understanding docs that we are ready to publish
... Survey appears to have unanimous consent to publish

RESOLUTION: WG agrees to publish updated Techniques and Understanding documents.

Survey: Initial Review of Proposed SC (https://www.w3.org/2002/09/wbs/35422/NewSC_initialthoughts/)

JOC: Looking to collect feedback on proposals from TFs. Any issues in the template we're askign them to use? Any major issues in what is being submitted? Comments?

AWK: And we really only got these yesterday. Initial post had a broken link. The idea is to get some thoughts and feedback to the TFs
... these are not in the official template yet or submitted as Issues in GH yet, but thought it might be a good idea to get some initial feedback

<Joshue108> No Accidental Activation

<Joshue108> https://www.w3.org/WAI/GL/mobile-a11y-tf/wiki/Proposed_revision_of_2.5.3

JOC: General feedback was pretty positive.
... This one comes from the Mobile TF

JF: Proposed reqs of 2.5.3? We don't have a 2.5.3 in WCAG?

DM: This is an internal doc - references 2.5.3 of our internal workings. Could become a new SC with a new Guideline. We will let WG decide new numbering

JF: Suggest we look at new Guidelines before we look at SC

<Joshue108> New Guideline Pointer Accessible: Make it easier for users to operate pointer functionality.

JOC: New Guideline is listed in document

<scribe> "New Guideline Pointer Accessible: Make it easier for users to operate pointer functionality. "

<jeanne> https://w3c.github.io/Mobile-A11y-Extension/#touch-and-pointer

<Joshue108> thanks Jeanne!

<jeanne> This is the Extension that we originally were working on. 2.5 is the Guideline. There is also an Intent of the Guideline 2.5

AWK: Looking at it from the point of: "What is this requiring? Is there a rational basis for this?" TF may say this aligns with Guideline XYZ but as a WG we may suggest other. So at this point it's just a matter of looking at the proposed document and giving initial feedback.

JOC: Take a few mins to read through

<Greg_Lowney> I think it would be better if we separate out use of the platform’s generic activation/click event to become the first bullet item, separate from the remainder of the item (explicitly happening on the up-event). This is so it is not the content’s responsibility to detect and work around cases where a niche client platform triggers activation on the down event

<Greg_Lowney> or a hover.

JN: Concerned about us writing something in there that supports touch. We may need to add a caveat into these "Where device supports touch" - avoid issues we've had with Keyboard

JF: Right now - all guidelines are dependent on an input type that is beyond what author can control

JS: We've addressed a lot of these issues in the definitions. We've discussed these quite a bit in the TF.
... This is why we're looking to change from "touch" to "pointer"

JF: This is why it may be helpful to go back to the guideline first.

JS: This is addressing custom widgets

JF: That needs to be explicit and not implied

JOC: It almost looks like this is required for some things - a way of denoting that would be calling that out in the SC - when this is required.

AWK: It's different from what we have in other SC because it's specific around an event. I'm wondering what the problem specifically is that maybe doesn't exist for mouse users.. or is there a problem for mouse users that we don't cover in WCAG 2? I'm wondering whether this might be too specific - maybe doesn't need to say it happens on the up event, but that users can stop it from...
... proceeding - or define at what point they can't reverse it.

<jamesn> +1 to AWK

AWK: trying to determine if this affects mouse users

DM: The problem we were trying to resolve was really about a mobile device (initially). Folks w/ dexterity issues may have difficulties touchign the right thing. This would allow them to stop if they touched the wrong item. All of these would be talking about pointer events.
... We were primarily thinking finger as the pointer, but certainly applies to all pointer devices.

JOC: When I read the guideline, i was wondering if it would be better that instead of "easier" just make it "touch and pointer events need to be operable". Wasn't sure why it was framed as "make it easier"

DM: We're borrowing from 1.4 Guideline. Guidelines themselves are not testable themselves - they are not made to be requirements themselves - just buckets to hold SC
... this SC is saying that if you do these things it will make it easier for users

<Greg_Lowney> Re John’s comment original comment re sounding like it requires touch, this proposed SC is explicitly scoped with "For single pointer activation", so it only applies where that is supported.

<Greg_Lowney> Perhaps the first line could be worded to make that clearer to less-technical readers that the target audience is authors who override default behavior. Separating out a new first bullet as I suggested earlier might help with that. The Description could also start with a sentence making this very clear.

DM: The first bullet does say implicitly or explicity - so it is right there. Maybe a better way of saying that.

<Zakim> JF, you wanted to note that the default of "up-event" isn't noted in the SC

GL: It is there, but that point is at the end. If the bullet item is "use default actions of a click event" - could even put in () "the default in most systems"

JF: +1 to GL, no where do i see where it says the default. On most native events, that's the default anyhow.

<laura> +1

<Greg_Lowney> For example: 1. Use platform's generic activation/click event (usually the default); ...

<Greg_Lowney> 2. When explicitly specifying sub-events, activation is on the up-event;

JF: this will impact a small number of content authors. We need to call out that this is related to custom content creation. When you're creating your own custom component that it activates on the up event and now the down.

DM: We can bring GL's language back to the group
... big takeaway is that we need to make it explicit in the SC that the default is up event

JOC: We'll leave this open for another week or so and come back to them.

JF: Currently shows as a Level A requirement. Scares me that there may be some platforms that can't support this.

AWK: We as a group will work on leveling at a later point

<Zakim> AWK, you wanted to say that this feels too specific when compared to 2.1.1, which seems to be the more direct analog

AWK: I think we should be careful in saying that it only applies to custom because just because this is default in current doesn't mean it won't change.
... in looking at 2.1.1 compared to this one - we don't have anything for the keyboard that is as specific as this - like saying you need to be able to cancel. For example we don't say that if you hit enter on a link you have to be able to cancel that before releasing the key.
... wonder if what we really should be doing is: " for pointer users you need to be able to interact with all content and functionality". Wonder if that helps avoid some of the challenges we'll find with detailed wording.
... maybe the additional wording is something we need to deal with in Silver

JOC: Complicated stuff and we have to strike a balance between the reader understanding what's required from them w/o causing too much confusion. There are times we don't want to be prescriptive

DM: I don't know that i would map this to keyboard because this is specific when you're touching a screen. With keyboard your hands are on the keyboard all the time, but this is a specific problem with accidentally touching the screen.

<Zakim> steverep, you wanted to question whether this SC invalidates all drag and drop actions?

JOC: I would like to see the SC call out that it is specific to touch and pointer

SR: Where do drag and drop events fit into this?

<AWK> I'm not sure that I agree that the sort of problem here doesn't exist for keyboard users. We should discuss more.

DM: Good question and is something we need to bring back to the TF

SR: As a follow-up it doesn't read as mobile only or tap only right now.

<Greg_Lowney> This applies to "For single pointer activation", which is usually considered a separate class of action from drag-and-drop operations.

JF: You grab with the mouse down and that starts the event

KHS: Some of this is relevant to the Indie UI stuff that is being transferred to HTML and CSS. May include movements on a map and 3D, chessboard etc. Have to keep that in mind w/ some of these mobile reqs

DM: The entire section has been remapped on Patrick's suggestion on pointer events. Bullet 5 covers exceptions such as drag and drop, but may need better language to call that out

<davidmacdonald> There is an exception in the SC about events that would be invalidated would not be required on the up-event

KHS: When talking about UI independent components, in a few years they won't be custom it will just be how we do HTML. Not sure we need that kind of info because we don't want to tie it down because of how things are done today

JOC: Generally happy with the way this is going? Or questions? Generally content?

<JF> +1 to AWK

AWK: Not entirely content with it yet - would like to see how we make this parallel w/ keyboard reqs

<AWK> AWK: There is a lot of good information in there, yes

New SC: Provide Rapid and Direct Feedback

<Joshue108> https://rawgit.com/w3c/coga/master/extension/rapid-and-direct-feedback.html

JOC: This relates to feedback loops

JF: Noted that it's related to Guideline 3.3. Don't know if that's really what we're doing here

JOC: Seem to me to be two different things

JF: This may actually be a 3.1 make content readable and understandable

AWK: or make operate in predictable ways

JF: This is immediately after user takes action they are given some feedback.

DM: No req in WCAG now except in 4.1.2 that's close to it

JF: I think it's closer to 3.1 or 3.2 than 3.3

<Joshue108> This is closer to good usability.

<Joshue108> Seeing the term 'feedback loop' in this SC name would be good.

JOC: Guideline or principle is up in the air, but this seems useful. Question on where it should live

<Joshue108> ack

DM: Had proposed - there's a long thread - about notifications and programmatic notifications. I see this SC encompasses that. Check Issue under WCAG 2.1 Issues

JOC: Please flag that to Lisa

<Greg_Lowney> The second sentence could be read as forcing authors to let users to turn off audio feedback in the content, rather than at their client end (e.g. muting the client).

GL: No problem with the goal, but problem with wording
... Could be something handled on the client side rather than requiring author to do that

JOC: Good comment - pls flag it to Lisa Seeman

<Greg_Lowney> Similarly, the first sentence requires visual, but not all platforms support that.

JK: I'm on the COGA TF and I can alert Lisa to that

GL: Happy to talk with her directly if she would like. Happy to work w/ the team on that

4. New SC: Touch with Assistive Technology

https://www.w3.org/WAI/GL/mobile-a11y-tf/wiki/Proposed_SC_Pointer_with_Assistive_Technology

MC: reluctant to use "touch" at the SC level
... this one is not using the generic wording such as pointer

DM: In general under 2.5 we were going to use "pointer" but for this one we were specifically talking about touch. Definiing pointer as a bucket: touch, stylus, mouse. But this one we really meant touch

MC: At the very least we may need to be brought up to date on the thinking

DM: There were discussions - we'd be glad to take it back to the group and discuss it more

MC: And if there are pushbacks that's fine - we just need that information here as well

JF: Concerned that this is starting to get into some conditional SC. Not all content - but specific content. INteresting concept that we havent' dealt with before.
... "IF" a pointer or touch screen is involved, then this applies - if not, it doesn't. I think this is the first time we're doing this
... if WCAG is supposed to be agnostic, but we're introducing SC that are dependent

<AWK> worth pointing out that this can be a problem on desktop systems with AT also

AWK: Not sure if we can avoid having SC that only apply to certain situations. Maybe in Silver we need to look at how we handle these kinds

<AWK> e.g. if you build a web app that needs to respond to a keyboard shortcut "h" then a JAWS user not in forms mode won't have access to that feature easily

DM: Believe there are all kinds of places.. Media - if you don't have multimedia those dont' apply. If you don't have images, those don't apply. If you don't have color, those don't apply.

MC: There are times where it will be conditional, but best to minimize that

<Zakim> Ryladog, you wanted to say that we have conditional multimedia SC, and many pages do not contain multimedia

KHS: Think we have to just not be so concerned about these things at this point and time. Think we need to collect these - and in the end if we can decide these cover all paradigm then great, but don't stop collecting these

JOC: We'll leave these open so that we can discuss more next week.

tackbot, end meeting

trackbot, end meeting

This is scribe.perl Revision: 1.144  of Date: 2015/11/17 08:39:34  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Found Scribe: marcjohlic
Inferring ScribeNick: marcjohlic
Default Present: AWK, JF, steverep, marcjohlic, Joshue108, Mike, Elledge, GregL, KimD, jeanne, kirkwood, jon_avila, Laura, David, MacDonald, Katie_Haritos-Shea
Present: AWK JF steverep marcjohlic Joshue108 Mike Elledge GregL KimD jeanne kirkwood jon_avila Laura David MacDonald Katie_Haritos-Shea
Found Date: 30 Aug 2016
Guessing minutes URL: http://www.w3.org/2016/08/30-wai-wcag-minutes.html
People with action items: