<Joshue108> FPWD of COGA Gap Analysis, Road Map and Issue Papers https://www.w3.org/2002/09/wbs/35422/COGA_FPWD_2016/

<Joshue108> Mobile TF survey: https://www.w3.org/2002/09/wbs/66524/2016-0509/

<Joshue108> zakm, clear agenda

<Joshue108> zakm, clear agenda

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

<scribe> scribe: jeanne

Mobile TF survey: 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 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 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: 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? 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> 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: http://w3c.github.io/coga/gap-analysis/#new-success-criteria

<Lisa_seeman> http://w3c.github.io/coga/gap-analysis/#cognitive-and-learning-disabilities-and-wcag

<Joshue108> 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> https://www.w3.org/WAI/GL/wiki/WCAG_2.1_Requirements_Draft

<Joshue108> 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> 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> 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.

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/It doesn't seem necessary/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/
Found Scribe: jeanne
Inferring ScribeNick: jeanne
Present: Joshue108 marcjohlic Makoto steverep Lauriat MichaelC AlastairC Laura Lisa jeanne davidmacdonald JamesNurthen kirkwood Mike Elledge
Regrets: Kathy JF moe_kraft
Found Date: 14 Jun 2016
Guessing minutes URL: http://www.w3.org/2016/06/14-wai-wcag-minutes.html
People with action items: