Web Content Accessibility Guidelines Working Group Teleconference

13 Oct 2015


See also: IRC log


AWK, wayne, EricE, Laura, Kathy, marcjohlic, MichaelC, David_MacDonald, jon_avila, JamesN, Joshue108, Lisa_Seeman, kenny, Joshue
Jonathan_Avila, Eric_Eggert, Bailey_Bruce, Wayne_Dick


<trackbot> Date: 13 October 2015

<AWK> Trackbot, what meeting is this?

<trackbot> Sorry, AWK, I don't understand 'Trackbot, what meeting is this?'. Please refer to <http://www.w3.org/2005/06/tracker/irc> for help.

<Joshue> trackbot, start meeting

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

<trackbot> Date: 13 October 2015

<AWK> trackbot, status

<AWK> +



<AWK> Scribe: DanielFrank

I will definitely need a little help, but happy to do it :)

<laura> Scribing Commands and Related Info: https://www.w3.org/WAI/GL/wiki/Scribing_Commands_and_Related_Info

<jamesn> is that noise me?

<jamesn> or is anyone else getting it?

<David> +David

Extension Requirements Survey: https://www.w3.org/2002/09/wbs/35422/extension_req/

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

Joshue: Continuing from last week, the Extensions Framework

<David> CAN'T HEAR ANYTHING IN WEBEX.... will try back

<Kathy> + Kathy

<jamesn> yeah i can't hear anything other than clicks

<Joshue> ok

<Joshue> we'll wait

Joshue: Last week we spoke about various aspects of the draft, talked about some wording changes

<scribe> Scribe: DanielFrank

James: I don't see how we can guarantee extensions are not going to contradict each other

Joshue: Agree that we cannot do that. I would suggest we minimize those sorts of situations as best we can.

James: Anyone writing an extension should understand it may conflict with another extension, and this should be documented in the extension
... We can't require two of them when they conflict

Joshue: Would like to open that up to the floor

Kathy: As far as the conflicts go, I agree with James that we are going to have potential conflicts. But that's really hard to have in the extension documents themselves. Should be in an overarching document. Concerned that with changes to documents and lack of visibility in each other's work, that could be an issue.

Joshue: A potential avenue here where we use that kind of language. We try to reduce conflict and dissonance in our work, but not explicitly call it out.

Kathy: Agree, but the extensions themselves are for specific things or audiences. If you do your evaluations and say this is what we need to support, then we'll want to include those extensions as part of what we are looking at in addition to WCAG 2.0. Need an overarching document to explain what they are, how they are used, and any potential conflicts.

Joshue: I thought that's what this document was
... I also wonder are we potentially playing with weasel words here? Compatibility is good, but sometimes what's good for one group isn't good for another.

Kathy: e.g., high contrast isn't good for certain people with cognitive or learning disabilities. Doing one thing doesn't work for everybody.

David: First thing, Lisa was concerned on last call, she gave a scenario, for people in Israel when there were bomb warnings people would sing their favorite song four times rather than count.
... Here is a possible place where there could be a conflict. I started to say that we have conforming alternatives in our conformance requirements, nothing wrong with having multiple versions of something in WCAG
... You can have e.g. a cognitive view of something. We can make our own conformance requirements in our extensions.
... concerned that developers will just throw up their hands over extensions conflicting with each other
... Our conforming alternatives can address most of that stuff

Joshue: One of the benefits of not calling out conflict at all is that it's kind of germane or inherent in the discussion that we want to reduce conflict
... There may be no need to call out conflict. As Kathy points out, we may not able to hit all bases. I don't know if agree with David.
... the alternate conforming version may not be the way to do this. Want to make it as easy as possible for developers to implement. WCAG is already complicated for many people.

Andrew: Some of what were were talking about, is how to balance with this. Fragmentation is a significant concern with extensions, conflicts between them. People picking and choosing because of conflicts between them.
... We don't wan't people to feel that extensions are favoring one group over another. If we allow conflict, that may happen, but if they don't conflict, we may end up with a race to the finish to avoid conflicts.
... maybe we need to be thinking about one big extension rather than smaller extensions.
... I agree we want to make sure we are addressing areas where WCAG is not doing such a good job currently: low vision, cognitive, mobile. We want to wrap things together so there are fewer potential sources of conflict.

James: Confirming alternate versions are a potential way to resolve any conflicts. I don't want to get into that, though, because it's a huge testing burden on people.

David: We want to minimize conforming alternatives, we've always said. e.g., here is a text version of the site. James is right, it's a testing nightmare. It's an escape valve.

James N: But then you get in a situation where everything is an alternate conforming version

Joshue: This brings up a question about calling out explicitly conflict in this document. I thought it was a good idea because it would focus our attention on areas where there are conflicts.
... my preference is to test this and test it hard. That means you need to call out conflicts.
... We could remove references to conflicts within the framework documents. My gut tells me that's not necessarily the best way to go.
... Andrew touched on whether we should have what we call a monoglot version vs. polyglot version, where we actually have all the extensions in one bundle vs. many.
... I would like us to discuss this.

Laura: I agree. We need to minimize conflicts as much as possible. I think it's good to have the "must" in there, but might be open to "should not conflict."

Joshue: Explicitly calling it out in our requirements document may be a way of resolving conflicts more quickly. Do people feel if we didn't have that language in the framework document, would it be lacking?

David: Not totally against it. If we leave it in, there isn't much room to negotiate.
... I prefer to say no conflict, then meld it into 2.1 or 3.0 later
... we could very quickly after getting a new charter come out with a draft of a 2.1 or 3.0 because we would have it all done.

Joshue: Is there a w3c requirement to call out conflict?

Michael: As far as I know, w3c process doesn't define the process of extensions. We would want to look at precedent.
... I haven't heard of a case where a WG produced conflicting extensions. A lot of people would have concerns about it, and you'd have to justify it.
... we need to look for precedence and good sense. Maybe the quality assurance document addresses this.
... we would want a pointer to the requirements and say explicitly either way whether extensions can conflict, and if they can we should say some stuff about it.

Joshue: Could it be beneficial in some cases when there is conflict?

Michael: We could say that, but it may be argued that this fragments the conformance model. We would have to address that.

<David> michael your volume is super high

Michael: we have to say how we expect the world to manage in the face of conflicts.
... we would have to say how the conformance model works

Joshue: At this point, should we be calling out conflict as an idea or ideal? Do we need to explicitly reference it at this point?

Kathy: I think it's more in the audience space where conflict could arise. Not necessarily on the technology, e.g., mobile.
... more on the user needs and what we are doing. What happens if we find something that really helps users with cognitive disability, but we can't have conflicts. It's saying that all users are the same, and we can only put something into extensions that only benefits all users.
... Users are different, and we all need to think of that a little.

Joshue: Damn straight!
... Maybe there is such a thing as positive conflict. We need to recognize the diversity of user needs.

<Zakim> MichaelC, you wanted to say we need to address the topic of conflict, since it´s clearly an issue. We need to either say we will allow it, or we will not. We should not ¨wait and

Michael: I think we have to expressly address the issue of conflict in requirements. We can't leave it unsaid, or wait and see.
... different user groups: We need to think about stability of the guidelines. WCAG 2.0 was set up with the intention of being universal and stable. Explicitly fragmenting the targeted user groups might be too much for the 2.0 version of WCAG.
... We might want to structure that into a future version of the guidelines where the core guidelines have that flexibility built into it.
... Could erode the stability of WCAG 2.0
... Philosophical concern: Is it inherently untrue that a set of guidelines can meet all user needs? Pitting user groups against each other could create a massive problem for the community.

Joshue: One take-away is that we are going to have to mention conflict and how we deal with it. We can't take references to conflict out of the document.
... Second thing, Is this down to the nature of the various TFs, do we have silos with different agendas? Is this something we should continue to do?

Michael: I believe that the TFs have been effective in corralling people with a common interest to focus on a detailed topic. It's natural and appropriate that they represent certain user groups.
... The intended structure has been that the TFs work in their silos, though there is some cross membership and we want to coordinate more at the TF facilitator level.
... they need to publish their deliverables through the core working group for review of these sorts of problems.

Joshue: I get a sense there may be trouble ahead

David: I guarantee there will be trouble ahead, and there is no way to do a world wide standard without trouble ahead
... this whole thing about conflict between disability user groups is not new to us. e.g., curb cuts in Ottawa. Conflict resolved between mobility and blind communities by putting ridges in the cuts, but bringing them down to grade.
... I would like to find a way to accommodate the conflicts. It's a very different Web now, easier to provide another view, different versions of things.
... We may be able to do this, with a requirement that there be no conflicts.

Joshue: May not be able to happen. As we push this out down the road I don't think we can mandate there are and will be no conflicts.
... we will talk more about this on the editors' call

Michael: Practically, if we have a requirement for no conflicts, we will try harder to resolve conflicts than if we say conflicts are OK. If we have a motivation to resolve conflicts, we are more likely to work to do that. With no requirement for resolution, things will fragment.

Joshue: That was the original motivation for doing this. Having said that, I do see that if we do use language that there must not be conflict, when people see conflict they will think that the WCAG process and extension model have failed.
... In fact, user needs are not equal.

David: everyone is very concerned that there is a lot of screen reader focus in WCAG 2. In fact, it's really hard to make a Web site compatible with screen readers.
... I go in and help people with low vision and blindness in banks all the time. I can tell you blind users have ten times the problems as low vision users.
... I don't think we can use that as an argument for why we can't do it this time.

Kathy: Screen reader users have always been more vocal.
... We need to keep in mind that WCAG was developed with the knowledge that we had. We have the cognitive task force doing more research right now.
... Can we put something that we will strive to have no conflicts, so we are all working toward no conflicts? When we do have a conflict, we have to have a discussion to determine what needs to be done.
... I want to have some leeway to have those discussions. It's fine for the TFs to propose things that may conflict.

Michael: I prefer the approach where we start the requirements saying we are not going to have conflicts, and we will try very hard to resolve any that arise.
... that should go into the first version of requirements

WCAG new errata for review http://www.w3.org/TR/WCAG20/ AND http://www.w3.org/WAI/WCAG20/errata/

Are we on agendum 2 or 3???

Joshue: Would like all extensions to have A or AA status

sorry about that

Item 3 in extension survey

Laura: AA seems to be the relevant existing measure

Kathy: As we were looking at the mobile extensions, we were definitely thinking about having the levels in there, it naturally fits with what we are doing

Joshue: Bruce suggests extensions should have a AA base
... He is surprised and disappointed that there isn't more love for A and AAA

Michael: I am a fan of having levels, because if you do have levels, then if you have something where you debating where it should go, you can say this is A or AA or AAA; otherwise everything will end up in the AAA level.
... Matching the extension level to the WCAG conformance level, the conformance claim becomes really complicated
... You get a real fragmentation around the claimed conformance level where there are so many variations

David: I really hadn't thought of the problem before. It's a rat's nest.
... Conforming at the level you are declaring probably makes sense.

Michael: To contradict what I said earlier, I can see one benefit to having extensions apply to a AA base.

David: There is a lot to help people with low vision and cognitive in AA. Requiring AA is a natural step to going to the next level.

Michael: Basing extensions on a AA base means that it's meaningless to move something from A to AA.

Joshue: If someone has gone to the effort of making a AA compliance Web site, they should be able to make some minimum level of conformance to a particular extension.

<Joshue> DF: Just to comment. Our enterprise policy etc says we have to be A and AA.

<Joshue> DF: We don't make a distinction between them.

<Joshue> DF: Yes

<Joshue> DF: Because of the nature of DOJ enforcement policy we don't make the distinction.

<Joshue> JN: We also see it like that.

James N: As an enterprise vendor, we don't make a distinction, either.

<Joshue> JOC: That opens the question of do we need A and AA at all?

<Joshue> MC: We need more evidence of how WCAG conformance claims are being used.

Michael: It seems we are getting into an area where we have anecdotal evidence for an important decision. We should do more research on that.
... I dn'
... I don't want to depend on anecdotal evidence for that decision

David: In Ontario we have A until 2021, and AA after that

Laura: A number of lawsuits in the US have been settled to AA

<laura> Legal Settlement Agreements that Reference WCAG 2.0 http://www.d.umn.edu/~lcarlson/wcagwg/settlements/

Monoglot vs. Polyglot extensions

Joshue: Should we have all extensions in one document, or separate extension documents?
... If we do the monoglot version, people who are only interested in mobile, or low vision, or cognitive, would still have to satisfy the extension criteria for those.
... The polyglot approach could be easier to implement, but people might only satisfy that one extension

<Zakim> MichaelC, you wanted to say a mono extension is WCAG 2.1 in disguise which might be viewed as a process foul

Michael: I personally view a single extension as WCAG 2.1 in disguise. We have said we are not doing WCAG 2.1, but effectively we would be doing it. That would raise questions.
... also makes it more challenging to address the kind of diversity we are trying to address in extensions
... If you are having extensions, the whole point is to have the possibility of more than one.

Kathy: We should have more than one
... Extensions are specific to an audience or type of site

Joshue: In terms of doing stuff for groups who are not a part of your core when you are building stuff, I am keen to have people go above and beyond.

Kathy: If I've got a software program where the only audience is a user with a learning disability, you don't want to do everything.
... it's going to be a lot to wade through. Now it will be WCAG 2.0 plus the extension stuff. Lots to wade through.

<Joshue> DF: Practically, we are driven by what the compliance reqs are.

<Joshue> DF: There is a gap in terms of mobile.

<Joshue> DF: Likely we would look at mobile first.

<Joshue> DF:Other groups we would not adopt until regulation.

<Zakim> MichaelC, you wanted to say a mono extension does avoid the conflict issue - but I´d rather address the conflict issue than combine the extensions and to say we might want to

Michael: I am in favor of polyglot. Would rather solve the conflict issue in that context.
... If you're doing an extension, you are targeting a user group. We should probably have a principle saying that we expect extensions to become part of the core guidelines in the next update.
... We need to be very careful about saying a certain user group is not in your audience. That's why accessibility is a big problem on the Web.

David: We would mostly be doing our extension development on our own, and then we would integrate them and be ready for 2.1 or 3.0.
... One extension is less complicated
... I don't have a strong objection to working up 3 or 4 extensions, and reconciling them on these calls

WCAG errata

<Joshue> Errata: http://www.w3.org/WAI/WCAG20/errata/

Andrew: May as well get purely editorial changes in

If I can figure it out

Where do I find the group mailing list?

To where?

<Joshue> WCAG <w3c-wai-gl@w3.org>

Yes, I seem to have dropped

<laura> Bye

<Joshue> trackbot, end meeting

Summary of Action Items

[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.140 (CVS log)
$Date: 2015/10/13 16:34:12 $

Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]
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/Kathy/Laura/
Found Scribe: DanielFrank
Inferring ScribeNick: DanielFrank
Found Scribe: DanielFrank
Inferring ScribeNick: DanielFrank
Default Present: AWK, wayne, EricE, Laura, Kathy, marcjohlic, MichaelC, David_MacDonald, jon_avila, JamesN, Joshue108, Lisa_Seeman, kenny
Present: AWK wayne EricE Laura Kathy marcjohlic MichaelC David_MacDonald jon_avila JamesN Joshue108 Lisa_Seeman kenny Joshue
Regrets: Jonathan_Avila Eric_Eggert Bailey_Bruce Wayne_Dick
Agenda: https://lists.w3.org/Archives/Public/w3c-wai-gl/2015OctDec/0011.html
Found Date: 13 Oct 2015
Guessing minutes URL: http://www.w3.org/2015/10/13-wai-wcag-minutes.html
People with action items: 

[End of scribe.perl diagnostic output]