W3C

- DRAFT -

Web Content Accessibility Guidelines Working Group Teleconference

23 Feb 2016

See also: IRC log

Attendees

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
Regrets
Chair
AWK
Scribe
Mike_Elledge

Contents


<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

QuickRef update (Eric)

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.

Low Vision TF update (Jim Allan/AWK)

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.

WCAG2FAQ review request: https://www.w3.org/WAI/WCAG20/wcag2faq.html (volunteers needed)

Techniques and Understanding Review: https://www.w3.org/2002/09/wbs/35422/Feb2016TandU/results, closed

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.

WCAG2FAQ review request: https://www.w3.org/WAI/WCAG20/wcag2faq.html (volunteers needed)

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.

Dpub review (http://w3c.github.io/dpub-accessibility/)

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> public-digipub@w3.org

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.

Extension document issues (https://www.w3.org/2002/09/wbs/35422/Misc20160223/results, list discussion on 2.2)

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> https://www.w3.org/TR/wcag2-ext-req/#ensure-that-web-pages-which-conform-to-wcag-2.0-with-an-extension-also-conform-to-wcag-2.0-on-its-own

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.

Summary of Action Items

Summary of Resolutions

  1. Working group approves Techniques and Understanding document.
  2. Accepted as proposed.
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.144 (CVS log)
$Date: 2016/02/23 17:33:52 $

Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]
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]