See also: IRC log
<AWK> +AWK
AWK: Introduction of Rakesh
Rakesh: Working on Deque India
team. 8 years accessibility. Have written ally blogs.
... Thank you John for helping me join.
<laura> Welcome, Rakesh!
Rakesh: Blog: www.maxability.co.in
zakim
<yatil> http://w3c.github.io/wai-wcag-quickref/?currentsidebar=%23col_customize
<Srini> Srini+
<Srini> Rakesh's blog is http://maxability.co.in
<AWK> +Srini
Eric: Quick update. QuickRef.
Another UI (see link above) revision, checkboxes for activities
referenced with relevant text. Now getting into final version.
Please take a look and let me
... know if anything is missing in Techniques. Almost ready for
final approval.
JF: Eric, what is the timeline for release?
Eric: This is the ally space, want to have ready for CSUN.
AWK: Comments so far that is much better than before, but take a look. Hopefully can get it approved for CSUN.
AWK: Low vision task force. Jim Allan?
JA: Jt task force betw uag and
wcag, now just wcag. First public working draft. Grinding
through process. Will be out soon. Open items being worked on.
Legibility, readability, etc.
... Seems narrowly focus, see if can bring in more issues. Will
continue working on User Requirements, then SCs. Applaud
Cognitive task force and Mobile efforts and will watch
... Will have separate documents with research, rather than TR
process. Many things user requirements that relate to user
settings, somewhat different than what WCAG may be used
to.
... Things that browsers should be doing to give users control
over their environment.
<laura> http://w3c.github.io/low-vision-a11y-tf/requirements.html
AWK: Process of LV task force is
very deliberate, separating out the pieces. 1) user
requirements, 2) identifying difference between WCAG and user
needs (50 found, 33 addressed in WCAG),
... then 3) identifying SC to meet those needs. Currently at 1)
and working on draft
JA: May do difference check with WCAG to see what's there. When get set will move forward.
JF: Difference (delta) with UAG. UAAG has had tepid response from mfrs. If they don't respond, are you looking at alternatives?
JA: Not yet. But as a community thing don't want authors to modify their interfaces in 000's of ways. The browser folks need to step up.
JF: If they dont', maybe create a library?
JA: Extension set was hopeful, but then Firefox changed and extensions went away. Hope Google will continue to add ally extensions. A good idea. Maybe a universal extension language wld help.
AWK: Will next see first public working draft for Low Vision group. Will tell group.
JA: Hope to have it by CSUN.
AWK: 7 approves, no disapproves.
Mark had comment. Typo item.
... It should say jan 6, 2015. Will check with MC and ask him
to update.
... Any other comments or thoughts?
... Any objections to publishing?
RESOLUTION: Working group approves Techniques and Understanding document.
AWK: Will go out for final review
and then after two days will be published.
... Have built in more time to schedule so will be in time for
CSUN. To preserve MC sanity.
... Will be sent out for Call for Consensus.
AWK: If you haven't seen page,
there is a WCAG FAQ. July 2013 was last update.
... Not our first priority, but if anyone wants to make
comments or review please do. Revise or add information or
clarify, please volunteer, or give informal feedback.
... Would like to have more up to date.
MK: Was curious where to send comments. Public Working Group address?
<MichaelC> https://lists.w3.org/Archives/Public/w3c-wai-gl/2016JanMar/0181.html
AWK: Yes. Believe MC sent email out about it. Thursday, Feb 18th.
AWK: Call for review. Digital Pub
group has done work, digital ally and wants feedback from
working group on Github. Would like to have couple of people to
review.
... Not worried about massive problems, but always good to look
it over.
MK: Getting a 404 error. Extra set of quotes?
<AWK> http://w3c.github.io/dpub-accessibility/
AWK: Good URL is above.
<laura> Wayne’s dPub Reccommendations: https://github.com/w3c/wcag/issues/163 and related email: https://lists.w3.org/Archives/Public/w3c-wai-gl/2016JanMar/0240.html
<MoeKraft> thanks
JN: Different clients do different things, can cause problems.
AWK: Any takers?
JF: What to do with footnotes, is one issue. David was working on that...
<Joshue108> Footnotes extension notes from Shane McCarron and David McD http://shane.spec-ops.io/notes/
<Srini> What's the expected timeline for this?
<Joshue108> Davids discussion paper http://davidmacd.com/blog/html51-footnotes.html
AWK: Alistar and Mike Elledge
volunteered to look it over.
... Timeline?
JO: No real timeline. Just heads up.
<Srini> Thanks...
JF: They're anxiously eager.
AWK: Be brutally honest.
... Any review is better than none.
MK: Wayne has put feedback in Github. How do you want feedback?
<JF> +1 to the fact that feedback is more valuable than how it is delivered
<Joshue108> [email protected]
AWK: Up to whomever looks at it. If email is easier we will forward to them. If put in Github pls send follow-up note to rest of group. See dpub email address above.
AWK: Survey with some results.
Comments from Gregg. Some responses back. Accept responses as
written (6). Some of concern from Gregg that doc is not aware
of things that it should be.
... While worthwhile concern, can provide messaging outside of
doc itself. Lots of Wcag that needs to be reviewed wrt to this,
but don't need to put in document itself.
... Any objections to accepting responses as offered?
... Okay.
RESOLUTION: Accepted as proposed.
AWK: Current discussion with
respect to 2.2. New thread started up. But want to get to point
where we can publish Requirements doc.
... Struggling with 2.2.
AWK: Thought we were in
agreement, that specs may add SC, modify existing SC, may also
change level of SC from A to AA, but not AA To A.
... Must be same or higher level.
... Struggling on how to number, interplay of multiple
extensions. Need agreement and clarity.
<Zakim> MichaelC, you wanted to talk about confounding issues
MC: Think discussion has
confounded issues. Would like to separate them. Numbering is
separate from how WCAG reqs can be modified.
... Adopt a rule not to modify by saying how to reword it.
Instead say "same as it is, ratehr than" so it's a wording
change. May help to accommodate multiple extensions.
... Don't want to revise core. Also discussion got hung up on
numbering. Will go back to that later.
<JF> The text in question is this:
AC: If page conforms to wCAg 2 how can it be modified. Additional by don't see how it can modify them.
<JF> An existing success criterion may change in priority from a lower level to a higher level, but not the other way around. For example, a Level A Success Criteria cannot move to Level AA. A new success criterion may be added. Existing success criterion may be modified, but the resulting change must still satisfy WCAG 2.0 success criteria.
JF: Lower level to higher level: +1, may be added: +1, but problem may be modifying SC. If it is modified it is a new SC. If can use it as dividing line, 3rd point becomes moot.
<Zakim> MichaelC, you wanted to talk about numbering
JF: Alistar summed it up well. Either one or the other.
MC: Thought experiment. Primary example ahs been changing contrast ratio. First 4.5:1, then follow extension to 3:1. An extra cognitive step in what I need to do. Simpler to declare conformance is 5:1.
<Joshue108> +q to talk about modification of SCs really being a new SC
JF: Already have examples wehre new SC follows that has stricter requirement. Minimum contrast (AA), then stricter criteria (AAA). Same with text.
<Joshue108> I also dont think they should map too explicitly to any TF either. I've concerns about that.
MC: Numbering: First, do not
think we should number extension same as SC. Extension SC
should be in own scheme to avoid confusion. Each extension
needs handle, like COGA 1.1.1
... Can explore both options of changing SC and adding new SC
if approach it that way.
<Zakim> Joshue, you wanted to talk about modification of SCs really being a new SC
JF: Disagree with that. Already have hard time getting ppl to do AAA. So having COGA, Mobile, LV in separate docs will lead to mess.
MC: Sounds like objection to Extension, ratehr than numbering scheme.
JF: Are we going to say WCAG + mobile + LV + COGA, how will anyone follow that? Opposed to keeping them in separate docs. Especially since wcag wants to promote universal design.
<jon_avila> When the mobile TF note used different numbering from the WCAG guidelines numbers there was much confusion. So I'd recommend at very least putting the relevant SC into the existing guidelines, 1,2,3,4, etc.
JO: John hear what you're saying.
But to address first things first. UD is aspirational, and
requires wading in the mud. Devil is in the details.
Implementing this in the world, extensions is kind of an
experiment.
... Exploratory. Hope will lead to a great WCAG Next. Have
concerns about terra levels?
... Maybe modification needs clarification. Some extensions
could modify current WCAG SC, so should be new SC.
<Zakim> JF, you wanted to strongly disagree with Michael's suggestion
<Zakim> MichaelC, you wanted to say how HTML extensions differ from WCAG extensions and to say concerns about extension ghettoization are about whether to have extensions, not how to have
MC: 2 pts. First, HTML attribute.
One key difference is that you can create extensions in HTML5.
WCAG does not say that. So have to have conformance plus
extension.
... Also lots of policy that can't disturb. Therefore
extensions have to be optional. Ghetto-ization is a concern.
Possible that there will be cherry-picking. For some a way
toget things out there, for others
... ghetto-ization. Want to separate conversations.
JF: Aware of politics of disturbing WCAG 2.0 But if bringing forward SC criteria, which is what we're talking about; new or fine-tune to make things better. WCAG 2.0 seems like an
<Zakim> AWK, you wanted to say that there are other numbering possibilities that are not specific to disability groups or even to individual TFs
JF: impenetrable document. If SC comes forward and we're in agreement, goes into extension document that's part of WCAG 2.0, so there is one document, and not different ones from groups.
<JF> +1 to the concern around forking
AWK: There is concern about how
things are numbered. JF concern is most impactful about daily
use of documents. Linear growth as opposed to forking specs
through ppls option to conform to one
... extension or another.
... Are there problems with that. Effectively a WCAG 2.1, 2.2,
2.3 or something different?
... Like the idea, but want to make sure it isn't
problematic.
<Zakim> yatil, you wanted to say either WCAG 2.0 or WCAG 2.0 with all extensions – WCAG 2.0E
Eric: Share John's concerns. Don't want cherrypicking. Conform to all extensions, or none. Like one document suggestion. Another possibility to re-release WCAG 2.0, similar to HTML5,
<Zakim> MichaelC, you wanted to explore monolithic revision-extension vs piecemeal extension plus version update and to say cannot change WCAG 2.0; can only do a version update
Eric: so ppl can conform to one or other.
MC: Cannot release WCAG 2.0 with
extension clause. Only can release new WCAG 2.0. Would thrown
W3C processes into sea. Maybe preferable to release new WCAG,
but that's what it is.
... Want specific groups to be able to get new advice quickly.
Also talking about WCAG 2.1 that includes them. Have to look at
combined extension. Publish individually or combined. Doesn't
seem
<Zakim> Joshue, you wanted to say I don't understand why its a disaster the TFs are working from the basis of user needs and to say what form the extensions take may not be explicitly
MC: much difference to me. But may have impact on timing.
JO: Don't understand why it's
disaster to address user needs. Want to find mapping between
groups, but may apply to more than one task force. More generic
the extensions the better.
... Ppl already cherry pick already.
JF: Whether one document or individual publications. From conformance standpoint, referring to one document is easier. When company comes to us, want to be able to say "Conform to WCAG 2.0". Think everyone is looking for us to move toward 2.1.
<SarahHorton> +1
JF: Tech changes, things overlooked in 2.0. Until ready to publish 2.1, why not release updates? Can be in conformance to either. Conformance referencing is difficult with multiple docs.
JO: Great to be able to say 2.1. Reality is it won't go any faster.
JF: If we don't start working on it will wind up with another 508.
JO: Are working on it. Incremental changes don't go fast.
JF: May get some conflicting
guidance. Color contrast ratio to 5:1. Then LV task force said,
no, need to allow to be less contrast.
... So okay with TF coming forward with different extensions,
then this task force's respons to sort through it.
JO: How different from now?
JF: Ghetto-ization from particular task force docs.
<Zakim> MichaelC, you wanted to say I don' t personally differentiate between "1" and "more than 1" and to poll how many people are concerned about extension proliferation
JO: But haven't decided that. Need to generalize extensions.
MC: Don't see diff betw 1 and
more than 1. Single monolithic extension doesn't make logical
sense. If want to do one extension, should do 2.1. If want to
do incrementally, have to have multicple extensions.
... Either will have some conflict, or say extensions not
working for us. Want to have more input from ppl on call.
Thought we had agreed to idea of extensions.
JO: Think we should keep going with extensions. An experimentation effort. Get that have to be careful with numbering. But focused efforts is a good idea.
<Srini> If we agree to go with extensions, we need to make sure we don't call them "optional" that would be ddangerous
JF: MC think I Answered why concerend with 1 vs. more than 1. Conformance reporting.
MC: Once say Wcag plus extensions is just as complex.
<Jan> JR: Think we should keep going with extensions. An experimentation effort. Get that have to be careful with numbering. But focused efforts is a good idea.
JF: Simpler to say "WCAG plus
extensions".
... Rather than daisy-chaining.
... Real world problem.
<Zakim> JF, you wanted to say that the problem is with conformance reporting
Greg: Whether extensions are
right way to go. Depends on what you want extensions to be.
Three approaches: 1) udpate doc for new technologies, 2) make
corrections and 3) address needs of specific populations.
... Example: Document explicitly for ppl who are blind. They
are fundamentally different. How to define extension depends on
how want them to be used.
... Maybe we're ahead of ourselves in trying how to define how
they will be used.
JF: Have a problem with that approach.
AWK: Can see how a problem if it is Coga vs. LV, less problem with Mobile. Don't want wcag for different ppl.
JF: Everyone is having a hard time figuring this out and we're experts. How do we expect others to deal iwth it.
JO: I think we're getting ahead of ourselves. How we do this will need to be addressed.
<Greg> To clarify what I was saying, it might be ahead of ourselves in trying to define framework for extensions without a clear understanding of what types of extensions we want to support. Of the three potential types of extensions I listed, we have to decide which of those, or others, we do or don't want to support. That can help narrow the scope and complexity of the extensions framework.
<JF> +1 to training issues as well
Alistar: Also have concerns if got to point of Conformance reporting with Wcag plus. Don't have problem with user-centered groups.
JF: Packaging is important.
<Joshue108> +1 to Sarah
<JF> +1 to Sarah
Sarah: Agree with concerns with extensions being identified with particular disabilities. Task forces makes sense. Also agree with JF that document can be used to address particular issues. Extensions may be problematic term. How about Expansions?
AWK: Most of points we're talking about can go in different directions. Need to find a way to finalize requirmenbts document. Continue to discuss on list. Josh and I will talk about it. Continue discussion on list.
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) Succeeded: s/Rikash/Rakesh/ Succeeded: s/Rikash/Rakesh/ Succeeded: s/UAG/UAAG/ Succeeded: s/3:1/5:1/ Succeeded: s/COGA 1.1./COGA 1.1.1/ Succeeded: s/thml/HTML/ No ScribeNick specified. Guessing ScribeNick: Mike_Elledge Inferring Scribes: Mike_Elledge Default Present: Michael_Cooper, Alastair_Campbell, Andrew_Kirkpatrick, Joshue_O_Connor, Katie_Haritos-Shea, Kim_Dirks, Laura_Carlson, Lisa_Seeman, Mike_Elledge, Moe_Kraft, Rakesh_Paladugula, Sarah_Horton, Wayne_Dick, MoeKraft, David, AWK, marcjohlic, JamesNurthen, JF, Joshue108, jon_avila, AlastairC, EricE, Elledge, Sarah_Swierenga, Srini Present: Michael_Cooper Alastair_Campbell Andrew_Kirkpatrick Joshue_O_Connor Katie_Haritos-Shea Kim_Dirks Laura_Carlson Lisa_Seeman Mike_Elledge Moe_Kraft Rakesh_Paladugula Sarah_Horton Wayne_Dick MoeKraft David AWK marcjohlic JamesNurthen JF Joshue108 jon_avila AlastairC EricE Elledge Sarah_Swierenga Srini Laura Mike Kim Dirks JimAllan Found Date: 23 Feb 2016 Guessing minutes URL: http://www.w3.org/2016/02/23-wai-wcag-minutes.html People with action items: WARNING: Input appears to use implicit continuation lines. You may need the "-implicitContinuations" option.[End of scribe.perl diagnostic output]