See also: IRC log
<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> +AWK
\Sure
<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
<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
Are we on agendum 2 or 3???
Joshue: Would like all extensions to have A or AA status
sorry about that
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/
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
<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
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]