<alastairc> scribe: Mike_Elledge
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.
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.
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
<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.
<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
<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?
<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?
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
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]