W3C

- DRAFT -

Accessibility Guidelines Working Group Teleconference

17 Jul 2018

Attendees

Present
Roy, jeanne, AMace, alastairc, Mike_Elledge, bruce_bailey, Greg_Lowney, Chuck, MichaelC, JakeAbma, Lauriat, kirkwood, Laura, gowerm, Judy, Glenda, david-macdonald, Katie_Haritos-Shea, JF, KimD
Regrets
Brooks
Chair
alastairc
Scribe
Mike_Elledge, Chuck, alastairc

Contents


<alastairc> scribe: Mike_Elledge

TPAC Registration reminder https://www.w3.org/2002/09/wbs/35125/TPAC2018/

ac: TPAC registration reminder. If going, pls register. Link is in IRC. Michael, a count?

MC: Not in front of me.

AC: Assume more on call than attending TPAC. Gets more expensive so better now to registers.

MC: 5 so far. One staff, one contact.

<Detlev> still waiting for funding approval (EU money) for TPAC

MC: Cost goes up in next couple of weeks.

Process discussion and feedback collection https://lists.w3.org/Archives/Public/w3c-wai-gl/2018JulSep/0063.html

ac: Sent an email to list yesterday, link in IRC. Request for feedback. A little time now that 2.1 is complete to look at how it went.

<Chuck> Apparently not

<Chuck> There is activity and discussion going on.

ac: some aspects in decision and success criteria, so know those. Published on time. But want feed back for improvments.
... Anyone else having issues with sound (andrew did)?
... Ways to give feedback, now have survey, if want to give privately use email to Andrew, Michael or me, also some ombudsmen.
... Timeline, provide wide window until mid-august.

chuck: Mike who?

ac: Michael cooper.
... Can contact all or one.
... Will review comments after mid-August. Assess them, themes, then move from there. Mid-September to present back to WG for discussion, chairs, restructuring as needed.
... Then tpac for call and consensus.
... other questions?
... Think about how it went and give feedback so we can improve in future.

Silver requirements feedback reminder: https://www.w3.org/2002/09/wbs/35422/silverReqFeedback/

ac: Silver requirements. May have Jean and Shaun on line.

<laura> David’s issue: https://github.com/w3c/silver/issues/22

ac: People who have fed back, useful from David, MG and Bruce.

Bruce: New idea of supporting user testing and UX should not be required, may be more flexible ways of testing.

Jean: PUlled from requiements, or not do.

Bruce: Too concepts need to be more differentiated.

<alastairc> https://www.w3.org/2002/09/wbs/35422/silverReqFeedback/results

ac: Some confusion that I didn't see so much. Had read it as not getting rid of testability, but exploring other ways of testing.

<bruce_bailey> Concept of user testing (or useability testing) as measure of conformance is new.

<bruce_bailey> I think that should separated out from idea of minimal and better as conformance metrics.

ac: Pass/Fail conformance. These are things to explore, not that they are required. Means of testing conformance. Not replacing testability.
... Other areas exploring.

Jean: Yes, do expect to refine requirements as we review prototypes. Examples are not what we are going to do, but possibilities.

ac: When have chance to review davids and Andrew's comments.

<Zakim> bruce_bailey, you wanted to say that edit could just be to have those as separate sentence

Jean: Mike Gower's comments on flexibiluty, too.

Bruce: Acutal edit, if examples are separated into tow sentences will do it. Measurability flexibilty if user testing used.

Jean: Group should not have problem with that. Helpful.

Bruce: Measureability if minimal if a better mode of conformance.

ac: Will be editing over the summer, so review and make comments to requirements document.

<laura> Agree with David. His latest proposed verbiage is a good compromise for the "Opportunities" section. https://github.com/w3c/silver/issues/22#issuecomment-405413467

Mike G: How do scopes differ.

Jean: Will look into that.

ac: Flexible strucutre is being able to add thingns eaislty vs. muliple ways of presenting in interface.

dm: Any decisions about responding to allowing us to have a fallback fi measurability doesn't work.

jean: Would rather work on prototype to show how it shuld be done. A better way forward rather than hedging our bets.
... help us come together on it. Examples of how it should be done.

dm: How does that fit with timing. Are we deciding on reqs doc now?

ac: Reqs doc is scopiing work, not saying every sc is measuarable, that we will try it and see if it works.
... More working on rather than outcome.

<laura> So is the requirements document on hold until the protopye are finished?

dm: hedging interesting use of word. Excited by idea of measurability, want to make sure that if there is a huge pushcbac,, that we need P/F, don't want to cut off branch
... when we haven't had buyin from industry. Prudent to investigate it. Such a huge change.

jean: Have been investigating and gotten industry and legal input. Direction we're going bec of input from groups.

dm: Understand.

jean: Why we're going in that direction. If doesn't work ahven' lost anything. What's in req doc are things were confident about.
... Will be doing user testing with stakeholders alrealdy identified. Will have data that ppl need. Give us a couple of weeks.
... You'll be able to look at. User testing not yet, mid-August.

dm: ARe we signing off on req doc before we're convinced.

jean: Req doc not final. It's the first draft. Will work on prototypes. Then refine req doc. Then take it to group again.
... We have edits that we're going to make.

dm: MC, help me understand.

mc: Is statement of what wg plans. At moment from task force. There will be other stages. A starting point to give structure.

dm: Not committing to measurability at this point.

mc: No, it is exploration. Final not for another year.

<AWK> We aren't voting right now anyway - providing questions and advice

dm: A year until we are commting to measurability.

ac: Iterative process. Providing questinos and advice. Scope of work.

dm: Helps. Looking at requirements draft. We'll be exploring whether we'll be going in one direction or another.

ac: Maybe confusion since such an early look at things.

mc: Important to have reqs at beginning of process, otherwise haven't set a plan. We'll be seeing how they pan out.
... About ready to do an initial version of what Silver may look like. As things are looked into will be modified. An iteration in several months.
... As std becomes mature, reqs gel, and are adjusted. At least two more rounds.

dm: My fear is that we could find out that industry could paint us into a corner, and that we'll be forced into measurability. So long as we can reverse course I'm less worrked.

detlev: When I read reqs doc, main point will be if we want to bring things into measurability that are hard to put in P/F format. Long scale from awful to good. how do we put in P/F. End points of awful and quite good. How do we deal with the squish middle? Need to measure, for example, amount of time to get through navigation.
... Then abstract what is good and bad, and put into a quantifiable model that can be handed out to customaer as second layer of advice.

jean: Come work with us on conformance.

detlev: Would love to. but don't know if I can commit time to it.

jean: Working offline, trying to work async around time ppl have. You are all welcome to join us.

ac: SC from 2.x likely to be included. But focus of work is what else can we do. Not dropping things.

Katie: Reqs doc looks good to me. Appreciate all the work that has goen into research and focus, how you build soemthging meaningful.

<Glenda> +1 to moving our energy (as a group) to Silver

katie: Would be awesome if we could move to silver, this is a good foundation for solid foundatin. Not living with old paradigm.

<laura> +1 to moving our energy (as a group) to Silver

Katie: A solid piece we should be working on.

ac: Also last agenda item.
... other questions or comments.

dm: Url for async activity taking place?

jean: Go to w3c.github.silver

<gowerm> • Github Silver repo https://github.com/w3c/silver

<gowerm> • Silver Google Drive https://drive.google.com/drive/folders/19-9CE4c14vDZYheaKoriz-TjYl2rreiJ.

dm: Where it's all happening?

jean: Transitioining to github, so not that much there. Have stuff in Google drive, wiki. So lots to move over.

zakim next item

Techniques for approval: https://www.w3.org/2002/09/wbs/35422/techs2/

<alastairc> https://rawgit.com/w3c/wcag/tech-failure-viewport-units/techniques/failures/viewport-units-for-text.html

ac: Techniques link goes to questionnaire. We have two techniques. Failure of viewports units (Jim). 3 ready for pub, a few comments.
... MG what is meant by zoom feature of browser. I updated.

Mg: Pinch to zoom seems to be designated feature of device. Want clarity not that everybody would think that p 2 z would be zoom in browser.
... Not sure that p 2 z would be correct description.

<jon_avila> I agree with Alistair -- this can't really be tested on mobile browser.

<Detlev> what about the Dolphin browse for Android? it does reflow, if memory serves..

ac: P 2 Z is magnification, not same as desktop zoom. Need to reflow. Addressed in reflow by saying has to adjust.

<jon_avila> Pinch zoom would not be used to test this as it just magnifies current layout.

katie: True today, but not nec in future.

<jon_avila> If it changes in future then we can change the technique or introduce a new one.

<JakeAbma> +q

<jon_avila> This test/SC is aimed at low vision user on desktop and not really aimed at mobile.

ac: Implications overlap with reflow. On mobile devices don't have that. Have multiple methods to meet SC.

<gowerm> Thanks, Alastair. Your rewording addresses my concern for clarity

katie: If tech specific, not necessarily wrong.

wilco: Not convinced about testing methodology. For viewports, but doesn't mentiond viewports. Ways of getting around this.
... Good at poking holes in rules (that's my job).

ac: Why it doesn't mention viewport units. Doesn
... call to use viewport units.
... Disagree with failure, or how worded.

<jon_avila> My suggestion was to rename the failure to say using vw without another means

<Zakim> Wilco, you wanted to mention transform, and ACT

wilco: Disagree with using viewport units.

<alastairc> q/

ac: Success technique.

wilco: One way to address success or failure.

<jon_avila> pinching is different in my experience

detlev: Want to reflect on pinching, can do that on mac. Use it a lot. Be aware that its not specific to mobile, but apple.

ac: Command vs. p 2 z.

<jon_avila> in Windows pinch is different then browser zoom as it doesn't trigger layout change but uses magnification

detlev: can pinch as well as zoom in. Some apps prevent that.

ac: Not strictly layout vs. desktop. There are two diff kinds of layouts.

<JF> +1 to Jon

ja: Windows get mobile mag. Control on mouse or command key on mac, zoom differently--get breakpoints.

<AWK> -1 to Jon's idea, as this is already built into failures

<gowerm> +1 to Jon. I had been thinking of some kind of qualifier but was worried about length of Failure title

ja: Should be clear about that. Propose that we change wording, add specific technique when we don't have p 2 z.
... Lots of other ways to pass. Important to have method for different circumstances. Makes fo rlong title to technique.

<AWK> from https://www.w3.org/TR/UNDERSTANDING-WCAG20/understanding-techniques.html:"Content that has a failure does not meet WCAG success criteria, unless an alternate version is provided without the failure."

ac: Quite a few failures where aria could solve problem.

<alastairc> q/

<AWK> working on it

ak: Wilco comment is good one. Provide context, liek "use viewport units". Then info about failure. Jon suggested "in case something else can be done." don't agree, say page can pass if alternate technique is available. Would have to add to many failure titles.

<jon_avila> example of similar wording https://www.w3.org/TR/WCAG-TECHS/F16.html

<jon_avila> I'm ok with AWK's approach

ak: Not sure if going through each comment is productive. But same idea is used in description. should think aobut if we want to add that to title.

ac: Update description to introduce it better. Revise content to include procedure.

wilco: Concern not with title or viewport, more about test procedure is really different from descrition. Suggest right test procedure that explicitly looks at text, and make sure that there isn't some other method that solves issues.

<alastairc> https://www.w3.org/2002/09/wbs/35422/techs2/results

<jon_avila> Another techniques with wording with mechanism https://www.w3.org/TR/WCAG-TECHS/F7.html

ac: Look at what is in results.

ja: Other techniques that have similar appraoch. Fine with Andrew's appraoch.

<Chuck> Need to change scribe

ac: Want to avoid long titles.

<Chuck> Scribe: Chuck

<Mike_Elledge> ja: Agree, just have doen before.

<AWK> Scribe list updated in wiki

ac: I think we can probably go ahead with Andrew's changes in that, but it's substantial. Run past creator of the technique. Go back to github and re-review next week.

Text Spacing Override

<Zakim> Wilco, you wanted to talk about test procedure

AWK: sum up comment with one issue, very similar to last time, there is still no technique that we're really talking about.
... Description doesn't tell you what to do in a technique. It's still "don't mess things up". Seems like we are telling them nothing, and...
... Techniques should tell them something. "Make sure sized to M units" is a technique. In this I don't know... we aren't being clear on the technique.

ac: It's one where there's... it's difficult to describe. First example the units aren't that important except that it's allowing space. Do you think it would be better...
... to calculate space required?

AWK: Right now this sounds like a general technique, but it's positioned as a CSS technique. Bottom line... what am I suppose to do here? The procedure for this...
... Is saying "do this and see if it breaks or not". You have no idea how to go about confirming that it doesn't break.

ac: I don't know how to say that in a more specific way. We could turn it around to a failure technique, but that wouldn't be particularly specfiic. It's...

<Zakim> AWK, you wanted to say that there is still no technique

ac: A new kind of success criteria where we are allowing the user a bit of override. I can't think of another similar techique.
... Not sure where to go with this one. We need somewhere else to put the test procedure.

AWK: We need to determine what we tell someone about how to do this. Maybe we break it down into much smaller items. Like item 3 is a technique...
... "Don't set height property on a paragraph so..."... That is a technique. It's very specific, it is telling them what to do.

ac: Example 1 is more specific. Maybe we need to explain that better.

AWK: I don't have a prob with example 1 or 2. That's not what the example or test procedure is talking about. Same problem, it's not providing a context.
... ...for each image on a page, do this... and we would need to have somethings that says "..." and this sort of thing would need to be tested.

ac: Sort of back to the drawing board on this one.

laura: maybe we should have separate techniques.

mg: If you follow my comments in the understanding doc and go down to sufficient techniques #4, they didn't actually create a general technique...
... They put it as a qualifying paragraph and listed a bunch of techniques to meet this combination technique... <reads from text>
... They list a bunch of bulleted techniques. It all seems highly relevant to what's going on. I don't know the background with the pre-amble, but I suspect it has something to do with the current discussion.

ac: ...It seems relatively straight forward to test, but breaking things down means that there isn't any one thing to cover everything.

mg: I thought that using "Liquid Layout"... I know it's more for reflow in some ways, it may be worth investigating if it can be modified to be a technique that can be used for this.
... Or if Liquid Layout more or less covers this.

ac: Sort of but not really. If you use an M unit that doesn't necessarily pass. The EM container doesn't increase, just the content. That doesn't necessarily hep.

mg: Have a look back at #4 in sufficient techniques for resize text.

ac: Maybe Laura and I can catchup after.

Laura: Thanks

Drag and Drop in Pointer SC

<alastairc> https://github.com/w3c/wcag/issues/403#issuecomment-401413996

ac: Hopefully people have had a chance to look at this and think about it. To summarize: detlev raised an issue where he was looking at an example
... and realized the pointer gesture success criteria could be read as making it a failure, which didn't seem quite right.
... where I think we got to was agreeing that drag and drop wouldn't be requiring a particular gesture. You could kind of read it either way...

<AWK> See change in https://github.com/w3c/wcag/pull/379/files

ac: in d&d all that matters is where you drop the item. Detlev's response is that this kind of d&d is not covered by this success criteria (out of scope).
... I think there was a technique as well. Detlev does that summarize what you were thinking, have you had chance to think some more?

Detlev: That's it. We could have a vote on whether or not anybody would object to that kind of understanding text. There are mentions in ...
... But that may be a separate issue.

<alastairc> acl da

ac: I think it does that if we agree on that understanding there will be some changes made.

david: In the description we steel some language from 2.1.1 , that would be "doesn't depend on the path of the users movements, therefore not a path or gesture based..."

<gowerm> +1 to using the 'does not depend on path' language from 2.1.1

david: Maybe we could leverage that in the paragraph.

ac: Anybody object to response?

awk: Which response are we talking about?

ac: The one I link to under agenda 5.

awk: The path based op.... that's in pull request 379 then?

ac: Yes if we agree on that response. There's a technique 380 that needs updating.
... Only concern I had with using the text from from 2.1.1 is that the actual success criteria text talks about path based gestures. We need to be careful about that.
... Last call, any objections?

mg: I pasted in the text, with qualifier from 2.1.1.

<AWK> Can we get the text edits in place?

mg: I thought that was important from last week. Not just the end point, but also how you get there. I don't think it's captured in this response.

<Detlev> q

ac: What Michael just put in...

mg: Not suggesting verbatim.

<Zakim> gowerm, you wanted to say "except where the underlying function requires input that depends on the path of the user's movement and not just the endpoints"

Detlev: Why do we need to bring that in? That formulation seems strange and convoluted. Difficult to get. Is the reference to earlier text needed?
... I would rather keep it simple. If everyone else agrees, go for it.

David: I think we can do without it.

ac: Key line for me is it does not use pre-defined gestures. Works for me.

mg: pre-defined gestures includes O/S gestures which are already excluded.

Detlev: I think we are talking about author defined gestures and not user agent gestures.
... I think it has already been narrowed down to author defined.

ac: Yes, note does that.

David: Would it make sense to use author-defined instead of pre-defined gestures?
... In the paragraph I think will be introduced into understanding documents.

ac: This is detlev's response to himself. We are trying to agree with this... and then there is a change to the understanding document.

<AWK> perhaps "it does not depend on pre-defined gestures in the same way as the swiping or dragging of content or controls"

AWK: If we want to have an attachment to 2.1.1, talking about depending on gestures, can we change one of these uses?
... Can we say doesn't depend on pre-defined gestures?
... Or is it about the whole gesture rather than the start and end point.
... It's the end point that's the crux, and we don't talk about that.

detlev: I'm happy with all changes, just on the exact wording I'm not so worried about.

ac: That's all we need to cover... we all agree this is not applying to drag and drop.
... Pull request is 379. As long as everyone is happy with substance, we can move on to updating understanding document.

AWK: Are there changes to the text we are making, or not? Not clear on what we are moving on from.

<alastairc> https://github.com/w3c/wcag/issues/403#issuecomment-405642478

ac: The proposed response to the issue...

AWK: We can't close the issue unless we agree to the text.

ac: I put your slight change in the proposed response, and just linked to ...

<gowerm> "...or the drawing of specific shape patterns which depends on the path of the user's movement and not just the endpoints."

AWK: I wasn't sure if that was John's comment, that it needed the end-point part or just the depends was enough.

<gowerm> "...or the drawing of specific shape patterns which depend on the path of the user's movement and not just the endpoints."

<missed some talking>

<gowerm> "...or the drawing of specific shape patterns, which depend on the path of the user's movement and not just the endpoints."

awk: Yes I like that.

<jon_avila> I like that wording with the end points as it helps people understand more clearly why we made our decision.

ac: <reading proposal>

gm: And I would put a comment after patterns.

detlev: sounds good to me.

ac: Any objections?

dm: WE could just drop pre-defined?

ac: Let's keep the explanation. Took us a while to get there.
... given that... the pull request for the understanding document... just scanning to see if it needs updating to match what we just discussed.
... I think it's very similar.

<alastairc> https://github.com/w3c/wcag/pull/379/files

ac: That's the change bit if people are happy with that. AWK do we need a cfc for this?

awk: nope

ac: I think we can go ahead and resolve to accep

RESOLUTION: Accept proposed response and pull request 379.

gm: Before we move on, I'm having problems figuring out where to post techniques when ready for the five person review. Which doc is best to go id a task.

ac: In terms of start to end process for techniques you mean.

gm: "I am ready to have techniques to be ready by the five, or I want to be one of the five". Where is the page?

Techniques process

<alastairc> https://www.w3.org/WAI/GL/wiki/Wcag21-techniques#Creating_Technique_documents

dm: I want an update on how we are doing techniques now.

ac: I put a link in to creating techniques documents.

dm: Looks like what I need.

ac: <describes process>
... not sure we need step 3.
... tell the chairs, I'd like to tag these things.
... Does that answer the question?

<alastairc> https://github.com/w3c/wcag/pulls?q=is%3Apr+is%3Aopen+label%3A%22Ready+for+initial+review%22

gm: Rather than crawl through the whole thread I should be able to find them doing that.

ac: Using pasted link...
... Techniques has a pink level.

gm: Might be useful to put the link in, it's just faster to spot the links in the document.

ac: sure

gm: And I would add myself as a reviewer?

ac: You can, but basic premis is that if you look at preview document, just give it a thumbs up, +1 comment. If you have comments make them in the pull request.
... Other q or c?

Silver, WCAG 2.2, and AG focus moving forward.

ac: last agenda item is around silver. In terms of what we are looking at for the moment, we do have a lot to do on techniques.
... We are making good progress but it's a long list, will take a while to get through. I've already had questions from GDS, "...where are those techniques"?
... It's being noticed. Need to make good progress. It's our main focus.

<Detlev> sorry, have to drop out...

ac: Question of 2.2 or silver, but that's a separate issue. Larger question of if we do a 2.2.
... That's up for discussion at the moment. There are a few factors. It will depend on how long we think it will be for Silver to be a viable replacement for 2.x.
... Will depend on what sc will be reasonable to add to 2.2 and how much effort is required. Not decided, but is a question we need to tackle.

<Zakim> JF, you wanted to ask about publishing updates to other documents (i.e., Understanding Docs)

jf: Related to the larger discussion.. agree we need to focus on techniques. We've been making editorial changes, looks like we've not pushed any updates since initial release.

ac: I think that's true. There's been a few editorial changes to 2.1, but not many understanding updates and no techniques approved.

jf: I had someone reached out to 1.4.11, my two techniques have not been published. I was asked when they would be avail, and they're not there.

ac: Probably because they have not been written or approved.

JF: old techniques.
... There's a success and a failure technique, but not published.

ac: May need to run the publishing process.
... There's also understaning workflows.

gm: Do you mean not referenceable?

jf: It is NOT in the understanding document in 1.4.11.

<AWK> Where are these linked from?

gm: It's a matter of running the generator. I've not been triggered to do that.

JF: Part of the larger discussion: Where are we at with the work we are doing now? We should figure that out.

AWK: Our intent is that we do it every Wednesday unless we don't have anything new. Today we did some changes based on detlev's issues.

<alastairc> I'm not seeing a difference between https://w3c.github.io/wcag21/understanding/reflow.html and https://www.w3.org/WAI/WCAG21/Understanding/reflow.html

awk: Those can go out. When we have a new technique that can go through... the plan would be to get pushed out next day. If there is something wrong with
... understanding documents that is editorial, we can get that updated and corrected soon. Can do anytime. Don't want to do this every 15 minutes or every day,
... But the intent is to get the changes rolling on an ongoing basis.

jf: I'm good with that, as long as we have a regular rythm. We currently have a gap. I'd like to see that document updated.
... I had some concerns about it. The success technique and failure technique says... <describes>. I'm talking about understanding doc for sc 1.4.11

<JF> https://www.w3.org/WAI/WCAG21/Understanding/non-text-contrast.html

ac: I think we were expecting to have a techique which would have triggered a repub, but we got stalled. Michael and I can talk about it later.

jf: ok, let's get back to larger discussion.

awk: I'm looking at the page "understanding non text contrast". Is it the one that says... there's one that says draft.

jf: I'm looking at the url I pasted in irc. 3-4 weeks ago we had consensus decision that we would add two...

awk: So they should be listed down in under sufficient techniques or advisory techniques?

jf: That's right. We added a failure technique that we agreed to add 3 weeks ago.

ac: I'm not seeing some of the changes I thought we made. We'll have a look.
... Any other q & c around focus around 2.2, Silver? Katie made her pitch earlier (for Silver)?

dm: That's my feeling also, we move our focus to Silver. We have to get techniques out of the way. We'll be motivated if we work on Silver next.
... I'm reading blogs, there seems to be a lot of apathy around 2.2 in the wild.
... I don't see a lot of satisfaction... I know there may be differences of opinions, I don't think there's a lot we can win doing 2.2.

<Glenda> +1 +1 +1 +1 Hi Ho Silver!

dm: That's my sense. Let's move over to Silver after techniques. Make this a real consensus rather than being handed something already solid.
... It's so important and a big change. We should be involved.

ac: Devils advocate: My feeling that there were some SC that if we had just ... if we weren't trying to tackle everything at the same time I think there might be smaller piece of work than 2.1.

<JF> +1 to Alastair

ac: If there's no desire to do that, then no point in taking it forward. Would be interesting to keep an eye out in case we get different feedback than what David is finding.

jf: My largest concern. As far as Silver activity is concerned, we are talking about structure. I know we want to have as up to date as possible... given the cycles related to charter...

<david-macdonald> http://tinyurl.com/jmo9st4. Proposed SCs not accepted into 2.1

jf: I don't think we will succeed at lobying for changes to the charter, a bit pre-mature for Silver. I would like to see us continue working on additional SC for 2.2.
... Until we have a first working draft of Silver.

<kirkwood> +1 to JF

<Wilco> +1 to JF

gm: Concur with JF. There are some reasons why 2.1 went the way it went. We could make some smart and realistic goals for 2.2.
... identify a bite-sized deliverable for 2.2. Would let us move the ball along while we work on this much larger task.

<Zakim> gowerm, you wanted to say I'm all for 2.2

<Zakim> bruce_bailey, you wanted to say I would like us to be working on 2.5 or 2.9

bruce: I'd like for us to be working on a version that would be sited by 508, Silver is not on that schedule.
... 2.5, 2.9... feature complete version of 2.2. Not just what we can get done in 18 months.

ac: Are you suggesting we plan for 7 years ahead?

bruce: I don't know. We aren't chartered for this. Looks like we have to work in 18 month chunks. It would do us well to look forward to feature complete versions.

ac: I wonder what feature complete would look like?

Glenda: Suggest that we all step back from extra things that we could have included in 2.1, and think about the progress that has been made for blind, keyboard only, deaf.
... We have come a long way. Keeping that in mind, what have we done for Cognitive?
... We need to focus our energy and stop pushing Cognative off. We need to spend the next sprint on Cognitive.

<jon_avila> we only got 1 cognitive criteria at Level A/AA for 2.1

<kirkwood> +1 to Glenda

katie: I think we can push back and provide realistic requirements in a charter that is longer than 18 months or doesn't talk about producing in 18 months.
... This is a spec that requires results to be excellent. We have to make the point to.... it's not an unusual thought to go away from 18 months.
... It's not just a done deal that we have to take that. The more they get involved in other specificiations that impacts regulations... extended timeline for privacy requirements.
... To work on just one little piece, they have an extended period of time. We have control to an extent.

AWK: Main point of this topic/agenda item is that the wg is not ready to make the decision. We are not chartered for either. We want to make sure wg spends it's time finishing 2.1
... Which are very much needed. Part of what we are doing is to think about what comes next, but to understand that we really aren't making that decision for many months.
... We need to focus on the non-normative documents.

ac: To some degree we will hold that potential work as a carrot beyond techniques.
... Devil's advocate for Glenda's point. There's some balance in the decisions. If we re-charter middle of next year, if it looks like Silver's model needs work and pieces aren't fitting together...
... That process could take a while. If we could pick out half a dozen coga sc that could be done in less than a year, would that be a good thing to do?

dm: Nothing has changed....

ac: Accessible authentication.
... fido bit is done. Some of the others if re-worked would be potential good sc we could get consensus on.
... Part of problem was that there were so many new sc, if we prioritized and did some prep, there's good sc to be done. We aren't making this decision yet.

wilco: Agree with you. Silver seems so very far away, far from a done deal. Not going to happen any time soon.

Chuck has to go.

<alastairc> scribe:alastairc

<kirkwood> Agreed, on COGA and very helpful for aging population and fantasitcally helpful to a very large community. The larger group buy in would be very helpful.

<gowerm> On the 2.1 front, I have a technique and working examples that need to be reviewed. https://github.com/w3c/wcag/pull/431 https://github.com/w3c/wcag/pull/432

trackbot end meeting

Summary of Action Items

Summary of Resolutions

  1. Accept proposed response and pull request 379.
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.152 (CVS log)
$Date: 2018/07/17 17:02:28 $

Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]
This is scribe.perl Revision: 1.152  of Date: 2017/02/06 11:04:15  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: Irssi_ISO8601_Log_Text_Format (score 1.00)

Succeeded: s/7 months ahead/7 years ahead/
Default Present: Roy, jeanne, AMace, alastairc, Mike_Elledge, bruce_bailey, Greg_Lowney, Chuck, MichaelC, JakeAbma, Lauriat, kirkwood, Laura, gowerm, Judy, Glenda, david-macdonald, Katie_Haritos-Shea, JF, KimD
Present: Roy jeanne AMace alastairc Mike_Elledge bruce_bailey Greg_Lowney Chuck MichaelC JakeAbma Lauriat kirkwood Laura gowerm Judy Glenda david-macdonald Katie_Haritos-Shea JF KimD
Regrets: Brooks
Found Scribe: Mike_Elledge
Inferring ScribeNick: Mike_Elledge
Found Scribe: Chuck
Inferring ScribeNick: Chuck
Found Scribe: alastairc
Inferring ScribeNick: alastairc
Scribes: Mike_Elledge, Chuck, alastairc
ScribeNicks: Mike_Elledge, Chuck, alastairc
Found Date: 17 Jul 2018
People with action items: 

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


WARNING: IRC log location not specified!  (You can ignore this 
warning if you do not want the generated minutes to contain 
a link to the original IRC log.)


[End of scribe.perl diagnostic output]