- From: Jeanne Spellman <jspellman@spellmanconsulting.com>
- Date: Tue, 14 Jun 2016 12:30:48 -0400
- To: WCAG WG <w3c-wai-gl@w3.org>
HTML minutes:
https://www.w3.org/2016/06/14-wai-wcag-minutes.html
Text of minutes:
[1]W3C
[1] http://www.w3.org/
Web Content Accessibility Guidelines Working Group Teleconference
14 Jun 2016
See also: [2]IRC log
[2] http://www.w3.org/2016/06/14-wai-wcag-irc
Attendees
Present
Joshue108, marcjohlic, Makoto, steverep, Lauriat,
MichaelC, AlastairC, Laura, Lisa, jeanne,
davidmacdonald, JamesNurthen, kirkwood, Mike, Elledge
Regrets
Kathy, JF, moe_kraft
Chair
Joshue108
Scribe
jeanne
Contents
* [3]Topics
1. [4]Mobile TF survey:
https://www.w3.org/2002/09/wbs/66524/2016-0509/
2. [5]FPWD of COGA Gap Analysis, Road Map and Issue
Papers
https://www.w3.org/2002/09/wbs/35422/COGA_FPWD_2016/
3. [6]WCAG 2.1 Requirements.
* [7]Summary of Action Items
* [8]Summary of Resolutions
__________________________________________________________
<Joshue108> FPWD of COGA Gap Analysis, Road Map and Issue
Papers [9]https://www.w3.org/2002/09/wbs/35422/COGA_FPWD_2016/
[9] https://www.w3.org/2002/09/wbs/35422/COGA_FPWD_2016/
<Joshue108> Mobile TF survey:
[10]https://www.w3.org/2002/09/wbs/66524/2016-0509/
[10] https://www.w3.org/2002/09/wbs/66524/2016-0509/
<Joshue108> zakm, clear agenda
<Joshue108> zakm, clear agenda
<Joshue108> [11]https://www.w3.org/WAI/GL/wiki/Scribe_List
[11] https://www.w3.org/WAI/GL/wiki/Scribe_List
<scribe> scribe: jeanne
Mobile TF survey: [12]https://www.w3.org/2002/09/wbs/66524/2016-0509/
[12] https://www.w3.org/2002/09/wbs/66524/2016-0509/
JO: Take a look at the mobile survey and be sure to fill it in.
... a few people have responded already.
... if you haven't replied, please do, it's important.
FPWD of COGA Gap Analysis, Road Map and Issue Papers
[13]https://www.w3.org/2002/09/wbs/35422/COGA_FPWD_2016/
[13] https://www.w3.org/2002/09/wbs/35422/COGA_FPWD_2016/
JN: When are we going to discuss the mobile survey?
JO: Next week.
... FPWD of COGA Gap
... is out as a survey this week
... there are responses for publication as a FPWD.
... the second question was for publication, many positive
responsive
... there is a note for a 404 reference
LS: Kudos for finding the broken link. We are reviewing all the
links to make sure they are all working.
Is there consensus to publish?
all accepted
<davidmacdonald> COGA, consider when writing SC's
[14]http://www.davidmacd.com/blog/what-are-WCAG-success-criteri
a.html
[14] http://www.davidmacd.com/blog/what-are-WCAG-success-criteria.html
RESOLUTION: Publish COGA for FPWD is accepted.
<Sarah_Swierenga> yeah!
MC: Can we talk about appendices?
... there was confusion whether the semantics docuemnt is part
of this package
<davidmacdonald> link?>
MC: it was decided that the Gap Analysis document so the
semantics document and extension are appendices.
<AWK> +AWK
MC: this meant that the extension would not be published as a
separate document, which could be confusing since we are
working toward 2.1
... the WCAG WG did not see that version with the appendices in
the survey.
JO: Do we need a separate survey?
MC: This is a substantive change so normally I would say yes,
but if the group doesn´t see the need to re-review then we
could just go ahead; these are just appendices
LS: It would be useful to get feedback earlier on the
appendices
... we have a Gap ANalysis that needs more success criteria,
and now people can see that there is a SC that could handle it.
... or if people think that "this could be handled with
semantics" and they can see the semantics.
... so it seems as those the task force has done practical work
that could be used by people.
... we like the success criteria, and it would be good to start
getting some feedback on it.
DMD: Great work on this. In terms of the SC, it seems like a
lot of the SCs have "do not"s in them. Did the task force look
at the SC document I wrote?
LS: I looked at it. The COGA document was quite mature when you
sent it to me. There may be feedback that they want the
document to be more positive.
DMD: It is more than being positive, it is having statements of
what passes.
<laura> Davids SC blog post:
[15]http://www.davidmacd.com/blog/what-are-WCAG-success-criteri
a.html
[15] http://www.davidmacd.com/blog/what-are-WCAG-success-criteria.html
LS: It's a lot of work and it is going to be tricky. It's not
necessarily acceptance criteria.
... it needs to be descriptiove. Where we knew these SC
criteria existed, we conformed to them.
... If we try to rewrite them now, -- it's a lot of work -- and
we run the risk of losing what we wanted in the SC to begin
with.
... we need to know what the acceptance criteria are, and what
are the best practices of writing SC. We want to know this
before we do another pass at writing SC.
DMD: Everyone should do all of these things, in my opinion.
LS: What we don't want interations of acceptance criteria.
<Zakim> Joshue, you wanted to say I'm happy to see draft SCs
published asap, as a part of an appendix is fine.
JO: We need a baseline of what is an acceptable SC.
... that is something we are going to talk about in the call
today.
... it would have been helpful to have discussed this
perspective on success criteria within the working group before
the conversation is published publicly.
<Zakim> AWK, you wanted to say that the main reason to not
include the proposed SC is that it may cause confusion when the
SC inevitably change as the WG reviews and as they are
integrated
JO: we need to have this discussion
AWK: I worry that we are putting SC in the document, because
these success criteria can change. I worry about confusion
between what is official and what is not. I am comfortable with
the task force publishing the gap analysis.
<Zakim> MichaelC, you wanted to say the appendix to the gap
analysis is definitely not the form the SC will eventually take
in WCAG 2.1 and to say a document on a private blog should be
AWK: it gets more messy when we say "and these are the success
criteria that we propose."
MC: That is a relevant point (andrew's). It is a Note-track
document, so it should not be expected that the SC proposed
would mature in their current state, or that they should be
expected to be in 2.1. Careful wording should help.
... it needs a caveat that this is not complete work, but are
rather that they are success criteria proposed to address them
but not finalized.
<Zakim> Joshue, you wanted to say I agree with AWKs point also
but doesn''t that mean we do a lot of this behind closed doors
as such?
MC: the comments from David are David's opinion, and the task
force should focus on what is needed.
<MichaelC> (which have useful content but haven´t yet been
vetted through the WG process)
<AWK> AWK: Work isn't behind closed doors - it is on GitHub...
JO: If we keep back the success criteria, it makes it seem like
we are working less publicly until we have perfected the
wording.
<AWK> AWK: May not be as discoverable
AWK: It may not be as discoverable, but it isn't behind closed
doors. We do want comments, but it is more likely that it will
change than not.
MC: We have to be clear about that in the introduction to the
appendix and the introduction to the Gap Analysis
JO: We have to think about, even in opposition to my desire to
get this published. Maybe we need to schedule updates to
success criteria differently.
LS: I agree that this is a first draft, and we expect
substantial changes.
... If we put it in a callout box, hopefully that will do the
trick.
JO: We are generally agreed for publishing these in Appendices,
but we do need to think about it.
... Congratulations on publishing, and thank you for all the
hard work.
<alastairc> Are we talking about these?
[16]https://rawgit.com/w3c/coga/master/gap-analysis/#new-succes
s-criteria
[16]
https://rawgit.com/w3c/coga/master/gap-analysis/#new-success-criteria
JO: Does the WCAG WG want more survey time to approve the
Appendices?
... we are noting AWK's concern.
MC: We need to get things out for review, while still working
with us. Another group that I coordinate with published without
putting them through review, so this seems like a middle route.
... the other task forces may want to do this with their
documents, and we should expect that.
<Lisa_seeman> Please note that this is an early draft. The task
force expects substantial changes.
<Lisa_seeman> (proposed wording)
JO: I am fine with including the SC as appendices, with the
callout "writ large"
MC: We can also do a CfC including the Appendices. We can save
a week by putting out a CfC for including the Appendices and
see if there are objections.
LS: We are ready to go with the Appendices for the Gap
Analysis.
<Lisa_seeman> [17]http://w3c.github.io/coga/gap-analysis/
[17] http://w3c.github.io/coga/gap-analysis/
JS: that is the Gap Analysis with Appendices. One for success
criteria, and one for proposed semantics.
<alastairc> Direct link:
[18]http://w3c.github.io/coga/gap-analysis/#new-success-criteri
a
[18] http://w3c.github.io/coga/gap-analysis/#new-success-criteria
<Lisa_seeman>
[19]http://w3c.github.io/coga/gap-analysis/#cognitive-and-learn
ing-disabilities-and-wcag
[19]
http://w3c.github.io/coga/gap-analysis/#cognitive-and-learning-disabilities-and-wcag
<Joshue108>
[20]http://w3c.github.io/coga/gap-analysis/#cognitive-and-learn
ing-disabilities-and-wcag
[20]
http://w3c.github.io/coga/gap-analysis/#cognitive-and-learning-disabilities-and-wcag
JO: I will put out a CfC after the call. Appendix A is the
semantics and Appendix B are the success criteria.
LS: When I sent an email to the list, I gave a link to the
sub-document that was the semantics. But they were not included
in the survey.
JO: There was some confusion about that, and decided to refer
to the Gap Analysis as the COGO canon.
MC: But there is also the COGA Research that was published a
year ago. The "COGA canon" is quite large.
... There are technology enhancements in Appendix A that are
needed for Appendix B.
JN: I'm looking at Appendix B and I am having trouble seeing
success criteria.
<davidmacdonald> B.3.1.1 Timed event are not used except for
the situations listed below.
<davidmacdonald> B.3.2.1 Do not expose user information in a
way that can be exploited without informed consent
<davidmacdonald> B.3.2.2 Do not add mechanisms that are likely
to confuse the user in a way that may do them harm and use
known techniques to keep the user safe.
<davidmacdonald> B.3.3.1 Provide a clear structure that
includes:
<davidmacdonald> B.3.3.2 Interactive controls are visually
clear or visually clear controls are easily available that
conform to the following:
<davidmacdonald> B.3.3.3 Instructions, labels, navigation and
important information are provided with a clear writing style
that includes:
<davidmacdonald> B.3.3.4 When there is a barrier between the
content and the user that requires additional abilities an
alternative is provided that does not require additional
abilities.
<davidmacdonald> B.3.3.5 Provide mechanisms that help the user
focus and maintain or restore context if the context is lost.
JN: there are techniques, but I don't see sc
<davidmacdonald> B.3.4.1 A predictable design is used within a
set of pages that includes:
<davidmacdonald> B.3.5.1 The success or failure of every action
should be clearly indicated to the user and visual rapid
feedback should be available. Spoken feedback should be a user
selectable option.
<davidmacdonald> B.3.5.3 Support is provided that help users
complete and check their task, that includes§
<davidmacdonald> (may be provided via a standard
personalization mechanism) (COGA Techniques 2.9 )
<davidmacdonald> 1. Use known techniques to minimize errors
that are relevant to the content
<davidmacdonald> ….
<davidmacdonald> B.3.5.4 Provide mechanisms that help the user
focus and maintain or restore context if the context is lost.
LS: Anything that is in dashed boxes are techniques.
... We would say "Use a clear structure that includes" and then
give a list of things that complete the success criteria, or
other examples that use lists.
... we wanted to be able to use vague words that people
understood.
... e.g. "a clear writing style" and then write specifics of
what that includes.
... it makes it long.
... there should be a list from the table of contents, that
pops out as a list of succcess criteria.
JN: The techniques are mix-and-match for example, some of the
success criteria seem like techniques. You are welcome to give
that as feedback.
... maybe wawnt to push them out as techniques.
MC: I haven't felt that the success criteria were mature, but I
want to determine if they are good enough for public review. If
the WG feels that they are not sufficiently mature for public
review, or that the WG needs more time to consider them, then
we should determine that.
JN: In 3.6.2 there are AAA that are mixed between AAA and AA,
and I don't see how that would work.
JO: This should be included in a survey so that the comments
are captured for the record.
... I haven't gone expensively through them myself.
... I see the Techniques in perforated boxes, but they are
mostly headings. IS there semantic language in them?
LS: They aren't Techniques yet, they are placeholders.
... This is not meant to be a WCAG extension or WCAG 2.1. This
is work that is ready to be passed to the Working Group.
... pulling out some things as AA and AAA.
... I think we should delay publishing these Appendices until
we get feedback from the WG.
... in Appendix A, we should not call them success criteria,
they are more releated to semantics that would be addressed by
a technical spec such as ARIA.
... I recommend that we omit the Appendix A because they may be
confusing.
... Why take out Appendix A, because they need to be published.
I can agree with taking out Appendix B, in which case, it would
not be confusing to publish Appendix A, because there are no
success criteira to confuse people.
JO: Perhaps we could do two CfCs, one for success criteria, and
one for semantics.
LS: I am ok with removing the success criteria, because it
seems that there is too much concern and that will delay the
publication.
... But why pull out the semantics?
JO: I'm just concerned about confusion around the semantics.
there are different "hats" required for the semantics and for
the success criteria.
... there are 12 success criteria. I think the semantic
document would be easier, because we are basically just
approving them to be sent to another group.
... I propose that we put the success criteria in a survey.
MC: Can we go ahead and publiish without the success criteria?
<Zakim> jamesn, you wanted to say we should eliminate the words
success criteria
JN: If we are removing them, it addresses my concern. I suggest
that changing the wording not to call them success criteria.
DMD: I agree.
<Zakim> MichaelC, you wanted to say I don´t know that we need
to survey all the SC individually and stuff yet - this isn´t
WCAG 2.1 content, it´s just an appendix - but do agree it
MC: We can always re-publish with the success criteria added
back in. I don't know that we need to review all the success
criteria individually yet, because we aren't working on 2.1
YET. So we could do a broad review of them, and then an
detailed review later when we are working on 2.1
... we could review it as a whole to send it for public review.
As opposed to getting individual discussion and review for each
individual success criteria that would be necessary for
publication in a REC-track working group. that's a higher bar
for publication.
... It's a little strange that this group is approving
publishing a semantics document which really should be the
purvue of another group. WCAG WG is focused on their own
concerns.
JO: If it goes out for public review without an internal review
that could catch any major issues.
MC: That would delay it by weeks, but we would be doing
positive work going forward
... the sooner we start doing review, the better.
LS: publishing the success criteria was a new idea, but let's
wait with the success criteria. Publish the Gap Analysis and
Semantics, but also put the survey out for the WCAG WG on the
success criteria.
... there are a different concern from this group, as to the
structure of the success criteria. It owuld be very helpful to
get this feedback right away.
... and we can start the process of explaining why the success
criteria are there.
MC: I want to propse that we publish without Appendix B success
criteria, and then figure out how to get a review of the
success criteria.
WCAG 2.1 Requirements.
MC: We need to make it clear that there was a decision made in
this meeting to remove the Appendix B Success Criteria.
<AWK>
[21]https://www.w3.org/WAI/GL/wiki/WCAG_2.1_Requirements_Draft
[21] https://www.w3.org/WAI/GL/wiki/WCAG_2.1_Requirements_Draft
<Joshue108>
[22]https://www.w3.org/WAI/GL/wiki/WCAG_2.1_Requirements_Draft
[22] https://www.w3.org/WAI/GL/wiki/WCAG_2.1_Requirements_Draft
JO: WE need to make a survey about this.
... we want to get the group's feedback on this.
... we will discuss this next week. This is a head's up to
prepare for next week.
MC: I'm working on a problem with the script where links were
broken.
AWK: It is worth pointing out that there are two sections to
this document. There is a section that is similar to the work
we did on the Extension Requirements. There is a distinct
section for what determines a success criteria that is focused
appropriately.
... we have to weave them in with the existing success
criteria, and that is hard.
JO: Should I split them into two separate documents?
<AWK> [23]https://www.w3.org/WAI/GL/wiki/WCAG_2.1
[23] https://www.w3.org/WAI/GL/wiki/WCAG_2.1
AWK: I don't think that is necessary. I put split them in the
wiki.
<davidmacdonald> Summary of SC
<davidmacdonald> Make testable statements
<davidmacdonald> It must be possible to evaluate the Success
Criteria independent of the user who is consuming it
JO: I would be happier separating them and then linking them.
<davidmacdonald> Describe the affirmative condition of the
passing content
<Lisa_seeman>
[24]https://rawgit.com/w3c/coga/master/extension/index.html
[24] https://rawgit.com/w3c/coga/master/extension/index.html
<davidmacdonald> Success Criteria are technology neutral
<davidmacdonald> Success Criteria apply to ALL content unless
there are specific exceptions
<davidmacdonald> Define new terms carefully
<davidmacdonald> Use existing Success Criteria for examples of
how to say things
<davidmacdonald> Sometimes it helps to split up a Success
Criterion
<davidmacdonald> Not all proposals can become Success Criteria
<davidmacdonald> No set of Success Criteria can meet the
requirements of ALL users
LS: I wanted to put in the link to the success criteria once we
remove it from the Gap Analysis document.
... it is the same document
AWK: We will have to talk about this, but I wonder if it will
be better to have success criteria in a granular manner that is
easy to separate from other information.
... everyone is going to have to figure out what is a success
criteria and what is additional information.
... The WG should discuss how they want to be presentted with
SC to review.
LS: I'm not sure what to do with AWK's comment
AWK: I don't expect you to do anything now. But be prepared
that we will ask you for a different format, because this is
difficult to determine what is success criteria and what is
not.
<Zakim> steverep, you wanted to say please remove ARIA labels
on heading links - why are they there?
JO: The heading structure is a difficult, but it is a
presentation issue. We will work something out. We don't expect
Lisa to figure it out
SR: The Gap Analysis Report has ARIA labels on them in addition
to heading. It results in every heading being read twice from
screen-reader.
... it is the anchor inside the heading. The heading is read,
and then "permalink", then the ARIA label is read.
JN: The permalink is there to allow people to link directly to
that section
... all W3C documents have them. It allows deep linking.
MC: We have worked on screenreader users on it. We can
certainly address this as a better approach, but that should be
in a separate format that this. It is being done with the
scripts for the document.
JN: It is the expected behavior, but perhaps we want to do it
differently.
SR: Realistically, does it need to repeat the heading since you
get it right after.
JN: But the list of links would be "permalink, permalink,
permalink" which would not be acceptable.
Summary of Action Items
Summary of Resolutions
1. [25]Publish COGA for FPWD is accepted.
[End of minutes]
__________________________________________________________
Received on Tuesday, 14 June 2016 16:31:24 UTC