<trackbot> Date: 21 April 2015

<Kenny> Review the current WCAG 2.0 requirements doc http://www.w3.org/TR/wcag2-req/

<Joshue> trackbot, start meeting

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

<trackbot> Date: 21 April 2015

<Joshue> Scribe list: https://www.w3.org/WAI/GL/wiki/Scribe_List

<AWK> https://www.w3.org/2002/09/wbs/35422/21stApril2015/results

<AWK> https://www.w3.org/WAI/GL/wiki/Scribe_List

<Joshue> https://www.w3.org/WAI/GL/wiki/Scribe_List

<scribe> scribe: jon_avila

Group and and prioritise items from the post-WCAG wiki https://www.w3.org/WAI/GL/wiki/Post_WCAG_2

jo: important page because it captures potential gaps in WCAG and issues and people's perception of WCAG -- it's a brain dump
... feel free to look at doc and edit as you see fit.

awk: we need to talk about extension and what is on the table for them. What things do we have existing comments on from the post WCAG wiki -- do those fit into a grouping for cognitive or mobile? Is there another extension that we may need based on looking at these.
... no comments on this survey question -- but wanted to get Makoto to talk about his comment so we can discuss.

makoto: using the same set of criteria WCAG 2.0 - JIS is national standard. Also have same conformance claim requirements.
... need clarification on third party items and how they fit into conformance. Difference in how people interpret third party items. Would like answer from WCAG WG.

jo: Is this a general query or is it related to extensions?

makoto: not sure where it should go.

jo: should log this in Github as an issue. Is that possible for you to input that as a comment into Github?

makoto: Need correct answer by September.

jo: be happy to talk about it now. Relevant topic.

david: clarifying -- this about social media and partial conformance claims

makoto: yes
... big differrenece if you can make a claim or partial claim.
... no law in April of next year -- like ADA or DDA that will make it a requirement -- although not requirement yet.

david: So companies want to use social media but also want to be conformant.

kamoto: e.g. companies use buttons like Facebook like or pintrest

awk: is social media where you are seeing these issues or is social media specifically called out?

kamoto: web content will be in scope of new law. Not clear yet what standards will be referenced.

<Joshue> http://www.comm.twcu.ac.jp/~nabe/data/JIS-WAI/

david: To be clear -- the links to the social media or feed to posting, etc. feedback, etc. that is what you are talking about?
... some of those things can be fixed.

kamoto: sometimes they can and sometimes they can't be fixed.

<Joshue> JA: Is a part of the problem content that you have no control over?

<Joshue> JA: Is there a choice, depending on hosting environments for example?

<Joshue> JA: Who is choosing the content? There is a destinction in where the responsibility lies?

kamoto: pintrest button is invisible in high contrast mode. Can't be fixed.

<Joshue> JA: But that is your choice?

<Joshue> JA: If you choose it, are you not responsible?

<Joshue> JA: Shouldn't you provide an @alt?

david: perhaps need to talk about what the partial conformance claim was meant to do.

JA: I wasn't referring to a text alternative but an alternative to that content

awk: Some redundancy between questions in the post WCAG wiki and those that are being raised by Kamoto
... We should look at this in structured way.

jo: It would be a good place to put it under the post WCAG section of the wiki

<Joshue> https://www.w3.org/WAI/GL/wiki/Post_WCAG_2

kamoto: thank you so much

awk: we don't need to discuss in detail but we need to talk on call about each item and the impact it would have.
... we aren't going through each article on call - we need to dish out actions for people to go through them (blog and article) to get granular details out of them to see if they are already represented or if something needs to be added.

jo: we need to link this in about the extention model as these topics are interconnected. Let's just walk through this document now.
... do we have volunteers to have people provide a brief abstract on each.
... We have ad hoc topics also such as meta data -- do we want to group these under potential extensions?

awk: there is a lot of information and we need to figure out how to approach this.

jo: Document is not exhaustive either -- it's a starting point.

<AWK> Suggested task for first 5 links. People need to read the article, then see if the issues mentioned in the blog post/article are already reflected in the other sections of the post-wcag wiki

jo: several of these topics could span multiple domains such as mobile and cognitive.
... topic of CAPTCHAs spans multiple domains too.

david: how would this work in legislation?

jo: down the road -- important question that but we are not there yet.
... questions are do we need failures, techniques, success criteria, or anti-patterns.

david: suggest success criteria
... if SC already exists -- perhaps we can manage by adding techniques to current WCAG

jo: only mint new SC when there isn't one covered.

david: why does it need to be in an extension at all.

jo: extension could be a collection of techniques

awk: not the way I see it. Extension is normative. Techniques are not.
... extension allows us to add something that doesn't exist and modify something that is there that needs adjustment or clarity.
... extensions could also remove something.
... need to have a solid set of identified issues.

jo: extension models are short. May find that in large part WCAG may apply but need clarification.

david: I would nervous about adding something that would remove a WCAG requirement. Could be very confusing.

lgr: Extensions are being proposed because people are finding problems that aren't covered by the existing success criteria
... Thought that we were saying WCAG is stable and we would make things backward compatible.

jo: yes, that is a concern.

MC: Explore whether how extension could modify WCAG 2.0. Argument is only legitimate if WCAG gives permission. WCAG doesn't give permission to do that as we didn't think of that.
... Perhaps we fix urgent issue with SC by adding extension and then we build list of other issues for next version of guidelines. So something can't be solved by extensions.
... Nowhere in WCAG does it say that extensions can be created to change anything in WCAG. That violations normative requirements of WCAG and leads to confusions that people are expressing.

awk: Does the HTML spec give permission for extensions? e.g. longdesc
... high bar that original spec will see that it can be replaced. Do we need permission of a 7 year old document to write something different?

<AWK> HTML5 says "Work on extending this specification typically proceeds through extension specifications which should be consulted to see what new features are being reviewed."

MC: Looking at HTML spec -- it doesn't say one way or another in normative way about extension. Status section does mention extension. Points to working group discussion. This gets into lawyer type stuff -- issues with interpretation, etc.
... just being a messenger about the challenges Good to be cautious because sites that could cause harmonization issues for extensions that remove WCAG requirements

awk: Same issue could applies to HTML5 conformance with longdesc.

MC: longdesc adds a feature that was removed.

awk: don't object to core idea that we need to be very careful. I want to make sure that we have a good sense of what we want to do and what others want us to do and the implications of those things as we build out the plan of how we do it. What does backwards compatible actually mean?

jo: we have flexibility on how we scope out extension. Longdesc adds a feature that was previously there. If we allow extension to alter perceived standard of WCAG SC that could be a real problem.

<David> +1

jo: we could define that extension don't override existing SC but complement or add to them but not override or nullify

david: I would oppose anything that alters WCAG. If we want to override WCAG then we need to go to WCAG 3.

<Joshue> JA: The work the mobile TF is doing could be an extension.

<Joshue> JA: There are other things in teh current SCs where we could be adding failures or new SCs. Not just one or the other.

<Joshue> JOC: Would that not just be WCAG 3.0?

<Joshue> JA: I'm not suggesting that.

<Joshue> JA: Don't want too much of the mobile stuff just to extensions.

<Joshue> JA: We need to document things clearly.

awk: agree that mobile work will be extension and techniques that fall under the current SC.
... what in your mind (David) is different between WCAG 3 and an extension? Small changes through an series of extensions could get wrapped into a new big thing.

david: e.g. if I add a coat to my clothes that extends. If I change my undershirt from cotton wool and then put on the coat -- that is actually changing my clothes not just extension them. I don't mind add layers even though there is risk to that.
... don't mind discussing everything -- but best to keep WCAG solid but just add things. Yes, that may add contrived things.

jo: Don't think we can change WCAG 2.0 at all.

lgr; content that conformance to wcag plus extension and if you remove extension content still conforms to WCAG. This allows you to make stricter requirement. Upward compatible

<Joshue> Could we have content that conforms to the extension and not WCAG 2.0?

lgr: WCAG 3 would just throw the door wide open to change level of SC.
... moving something from Level AA to A would fit extension model while move Level AA to AAA would not fit the extension model.

<Joshue> consistent extension, like it

<Zakim> AWK, you wanted to say that adding an extension doesn't change a country's law that referenced WCAG 2.0 until the law changes to be WCAG 2.0 + extension.

JN: extension could be free to create a Level A contrast SC because there is no contrast requirement at level A.

awk: Reason why I want us to be familiar with post WCAG items is because some of these will and some won't fit into the model that LGR discussed
... If we have an extension that modifies WCAG and a country has a policy on that -- doesn't effect them until the adopt extension.
... Extension doesn't operate in changing adopted standards.

jo: positive use case for extension to use as a framework for organizing

<Joshue> JA: One other difference would be how we get gov to adopt extensions sooner?

<Joshue> JA: We hope they would do that more easily than adopting a WCAG 3.0.

<Joshue> JA: That is intersting to stakeholders, but there is a lack of awareness.

<Joshue> JA: Agencies are free to accept additional a11y standards.

<Joshue> JA: This would fall under the 508 refresh, and is a nice flexible model, so +1.

<Joshue> JA: Even with WCAG 3.0, there will still be a need for extensions!

<Joshue> JA: Right now, I support this.

marc: what if something can't be done or doesn't apply for mobile, how does that fit in?
... trying to think of something like that -- would that be ok? For example, something doesn't apply?

JN: If something doesn't apply isn't it out of scope and automatically applies?

<Zakim> jamesn, you wanted to talk about the potential complexity issue of all this

marc: just wondering what wording we would use for situations where something does apply.

JN: Or perhaps there is a better way. e.g. a thought control interface but not a keyboard interface.
... Like extension idea -- but concerned about complexity of having these additional items on top could be problematic. Also concerned with multiple extensions and conflicts between the two?

<Zakim> MichaelC, you wanted to say we will need clear requirements and explainers

MC: Valid warning on extension working together. Will need good guidance and explainer document. Regarding conflicts -- important issue.
... Perhaps we could forbid extensions that conflict with each other. That is a decision we will have to make.
... we don't allow we will need to be on top of observing conflicts and work them out before acceptance.

jo: Fantastic information here in the call.
... we will need a framework for extensions to make sure we have unique but consistent requirements
... Any other questions?

*thanks

<AWK> trackbot, end meeting

This is scribe.perl Revision: 1.140  of Date: 2014-11-06 18:16:30  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Succeeded: s/Extension is not normative./Extension is normative./
Succeeded: s/Extension is normative./Extension is normative. Techniques are not./
Succeeded: s/Don't think we change WCAG 2.0 at all./Don't think we can change WCAG 2.0 at all./
Found Scribe: jon_avila
Inferring ScribeNick: jon_avila
Default Present: Joshue, AWK, Makoto, David_MacDonald, Michael_Cooper, EricE, Kenny, +1.703.359.aaaa, jon_avila, Loretta, MoeKraft, [IPcaller], Marc_Johlic, +1.650.464.aabb, James_Nurthen
Present: Joshue AWK Makoto David_MacDonald Michael_Cooper EricE Kenny +1.703.359.aaaa jon_avila Loretta MoeKraft [IPcaller] Marc_Johlic +1.650.464.aabb James_Nurthen
Regrets: Alan Kathy Christophe
Found Date: 21 Apr 2015
Guessing minutes URL: http://www.w3.org/2015/04/21-wai-wcag-minutes.html
People with action items: 

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