MINUTES
Education and Outreach Working Group Teleconference
19 Apr 2013

WCAG Techniques issues

Shawn: Reminder that the issue is the misunderstandings about the Techniques. Some people misunderstand them as being mandatory for conformance. In fact, they are not required but are offered as one way to meet WCAG.
... the WCAG-WG worked on a potential separate document to point policy makers to to address this issue.
The WCAG-EM Task Force also has expressed their need to point to clear guidance on Techniques and Failures. They feel that explanations in the current documents is not sufficient.
Any additional comments or questions?

Denis: During the recent tweet chat of violations vs best practice, we saw this misunderstanding expressed numerous times.
... in the discussion, people would say that Techniques were requirements and they were failing items that did not align with a Technique rather than seeking other ways or even paying attention to the SC itself.
... I can point to the link to the tweetchat if it is useful.

[Shawn & Sharron - too hard to follow that tweet chat!]

Shawn: That is a good example of the misunderstanding. OK that is the background and now if we look in the wiki, there is a section on our proposal to address these issues

<shawn> Proposal for addressing the issues http://www.w3.org/WAI/EO/wiki/WCAG_2_FAQ_Notes#Proposal_for_addressing_the_issues:

Suggested approach

Shawn: One idea is to have the full coverage of all issues in one document and that is the Techniques document. Then the separate policy document may not be needed.

Sharron: The existing Techniques document, are we suggesting to just edit that one?

Shawn: Yes

Denis: Remember a previous discussion we had Shawn about the need for a filter that would point to what is being addressed?
... I am thinking now that an analysis is needed for the SC and the related Sufficient Techniques and develop a bullet list that highlights what they may need to think of when deciding whether any specific technique is actually sufficient.

Shawn: General guidance rather than specific?

Denis: Yes, general guidance for forms, structure, semantics etc

Shawn: That is an interesting long term solution, but not something that we can get done this week, so please add it to the wiki for future consideration.

<Andrew> +1 to Denis' suggestion (for the future)

Shawn: Let's focus today on what we can get done this week, now.
... one idea is to have the issue addressed in the Techniques doc, then put pointers in blogs, wikis, Understanding docs
... comments or questions on that?
... so the issues will be addressed in detail in the Techniques document. Then create a short blurb with pointers from at least four other place. Right now FAQ, QuickRef, and Understanding docs all have different wording.

Andrew: Techniques documents itself would have a very clear explanation of what the Techniques do, how to use them, what they are not, etc?

<Zakim> LiamM, you wanted to ask about wording in Understanding WCAG2.0 about judging alternative techniques and to ask if we can come up with a concrete example to support the abstract

Liam: A couple of things come up for me. In the Intro to Understanding, the section about Sufficient and Advisory Techniques. The final sentence may be what is causing the confusion. Essentially saying you must justify using any other techniques.

<LiamM> "If techniques are used other than those listed by the Working Group, then some other method for establishing the technique's ability to meet the Success Criteria would be needed."

<LiamM> could be problematic...

Liam: On the one hand we are saying that this is just one way but on the other hand we add a burden of proof that may seem onerous.
... My second thought was to provide a concrete example that will aid understanding.

Shawn: A concrete example of a new technique? Maybe related to a new technology?

Liam: Yes and be sure not to add it to the Techniques

<shawn> key points <http://www.w3.org/WAI/EO/w iki/WCAG_2_FAQ_Notes#Key_Points>

Shawn: Let's look at the Key Points document
... read the paragraphs in that section please.

<Andrew> notes that our key points say "if you follow the sufficient techniques, you meet the success criteria" which still seems misleading as it implies this is the right/only way

Shawn: So imagine this blurb distributed as we discussed. Comments?

Liam: Suggest removing "specific" from 2nd paragraph since it makes it sound more required than it is.
... also in third paragrpah, it should be "there will" rather than "there may" be.

<Howard> "will" can be interpreted as something available in the future

Shawn: ..or there are "likely" to be?

Wayne: yes, that is more correct

Bim: ..there are often

Liam: Rather than being exactly precise, we are trying to give people the sense that they are free to find other solutions

Shawn: ..or there are

Liam: Yes, even better

<Andrew> but is it true for all SC?

Denis: Yes it is simple, straightforward enough

Liam: And the next two sentences simply repeat the first over and over again.

<Andrew> +1 to tersifying

Shawn: And the next addresses Denis'searlier comment - could fail one Technique and still meet the Guideline
... Let's imagine for now we have concatenated those three sentences

Denis: Reads the edited Key Points section

Wayne: Creative developers also come up with insufficient techniques so we have to keep that in mind.

Howard: In the interest of tersification, we should keep this simple and not add words that may add to confusion.

<LiamM> Suggest "The Techniques are brilliant. Follow them and you can be confident that you will meet the WCAG success criteria. But you are free to come up with techniques of your own, *as long as you are confident that they will also meet the success criteria*."

<Andrew> :)

Wayne: Yes, that is good!

+1

<dboudreau> love it

<Vicki> +1

Shawn: I think that is a blog post
... Now, how to capture that idea in this document, for this kind of language?

Annabelle: Saying that these are proven Techniques and your own are still to be proven?

Denis: SCs are testable ways to make sure Guidelines are met
... if you follow the Techniques, you will meet the SC. If you come up with your own, you must still prove they meet.

Liam: And it will be great if you email it to W3 to be included in the Techiques documentation.

Denis: It is a great opportunity to remind people that they can add to the Techniques

Shawn: If we are trying to keep it short, do we omit here or do we think it is important enough to include, even though it adds to length?

Liam: And good to remind people of community effort that is W3.

Wayne: Yes it is worth it

Denis: Yes

Howard: Yes it helped me understand

Techniques document

<shawn> Techniques notes in wiki http://www.w3.org/WAI/EO/wiki/WCAG_2_FAQ_Notes#Techniques_for_WCAG_2.0_document

Howard: As a first time reader, ...I had never really looked at the Techniques document in detail. This was my first time really reading through them. My first impression was that it was extremely confusing.
... the advisory techniques terminology was even more confusing. I think it is meant to be an optional technique or something appropriate in the future. Still not sure what is intended.
... same with the terminology of "Sufficient" the meaning is unclear within the context of the document itself. Those who have worked with them for awhile may have internalized the meaning, but coming to it cold, it was very hard to understand.

Denis: This is quite valuable. We keep going through them with our experience and too often lose sight of what the meaning is to those who come to it for the first time.

Shawn: There is a question about how the Techniques fit into the whole WCAG suite of documents. We would not intend for anyone to read throught he techniques as an entire document.

Liam: There is no clue within a Technique that you may come to from within an Understanding document that they relate to each other in the way that we are now discussing.

Shawn: So if you land here, you need context and should be alerted to the fact that you don't want to only read here.

Liam: Discuss the meaning of "normative" , for example - is advisory more or less important than sufficient? etc

Shawn: One suggestion is to rearrange the introduction quite a bit and include a heading for each Sufficient, Advisory, Failure
... then, when people skim they will have markers to return to for clarification.

Wayne: It does not anywhere say explicitly that these are not meant to be read as a unit, that they are meant to be accessed through QuickRef, Understanding, etc
... I have always found this to be true. People are overcome with the techniques and they were not meant to be used this way. "Oh my gosh," they'll say "there are 700 pages in this!" and run away.

<AnnaBelle> +1 to Wayne

Howard: More input from first time reader. We may need a glossary so readers will understand...for example, are general techniques different from sufficient techniques?
... some techniques themselves are not clear. Some wording for the headings would clarify, maybe technique process or technique description.

Andrew: Must really dig around for information about failures

Shawn: Look at wiki, I have added "Using the Techniques"

Liam: Do people have this same confusion when they come to it through the QuickRef?

<Andrew> http://www.w3.org/WAI/WCAG20/quickref/

Timing of significant edits to Intro

Paul: I wanted to validate what Howard said about the introduction, it is a pretty daunting document.

Shawn: So yes, we need to make sure we clarify how the Techniques are meant to be used. This would be a significant edit. How important is it in this version, which they are about ready to announce as a draft? It would cause delay so do we think it is significant enough to do so?

Andrew: Are there new techniques that will be impacted by this?

Shawn: There is some new material in the Understanding...not new techniques but many edits to existing ones.

Wayne: I think we should probably not hold up their draft and forward a more careful edit when the draft is released.

<Andrew> +1

<Vicki> +1

<dboudreau> +1

Shawn: If we do that they will have to put out a second draft which will take another cycle of review, so it will lengthen the review process.
... if they wait two weeks, make the changes we suggest now, they may save one review cycle.

Sharron: Given that we know there must be significant changes, should we ask WCAG-WG whether they prefer those changes now or later?

<Howard> I like Sharron's suggestion.

<Bim> +1 to suggest that edits will be significant and ask what they prefer.

Liam: If we know these changes must be made, it may be up to them how they want to approach it.

Shawn: And if the draft remains so confusing, I am concerned that it will only add to people's confusion.

Denis: If we have any concern that not delaying will lengthen the time for the next version to come up in months rather than week, than I withdraw my +1

<Andrew> we edit the "About the Techniques" section in quickref to clarify

Liam: There is a serious point in there, I agree with Andrew that it is important to begin with the QuickRef. And so, if you do that, you will never see the Intro.

Shawn: That is part of the problem, people do not get the information. If they don't read the intro, how will they get the information that "hey these exact techniques are not specifically required?"

Liam: Could be done with glossary or link

<Howard> It seems like there are sufficient concerns to ask WCAG-EM to delay.

Wayne: It is like putting an introduction to an index. It should have no introduction, but a warning that it is not meant to be used as a document.

Shawn: Do we put it in Understanding?

Wayne: maybe since Techniques doc is really just a big glossary

Liam: Yes it is just a collection of short page, quite strange to see it as a document

<Wayne> +1

<LiamM> +1 if terms 'advisory' and 'sufficient' are also glossaried on each individual technique page.

<Bim> +1 link from Techniques doc, linktext "how to use Techniques"?

Proposal: intent of Intro to Techniques documents

Shawn: So as a proposal, the Intro to Techniques would simply state, how to use them, don't read as a whole, use QuickRef or Understanding. Then all the details about the intent of the techniques and the explanation of varied techniques and how to use them will be positioned within Understanding docs.

<Andrew> +1

<paulschantz> +1

<AnnaBelle> +1

<Sharron> +1

<Howard> +1

<Andrew> +1 to Liam's 'link' suggestion

scribe: and do we want to put something in the footer of each Technique to indicate Sufficient or Advisory and a reminder of non-required status

Wayne: It is when you are meeting SCs that the Techniques become Sufficient. We in one sense are using logically inconsistent terms. We have them and I am not suggesting change, but note that it may add to current confusion.

<shawn> Techniques and Failures for Success Criterion 2.1.3 - Keyboard (No Exception)

<shawn> Each numbered item in this section represents a technique or combination of techniques that the WCAG Working Group deems sufficient for meeting this Success Criterion. [begin change]However, it is not necessary to use these particular techniques. Any techniques, whether published by the WCAG group or not, can be sufficient if a) they satisfy the Success Criterion and b) all of the WCAG 2.0 conformance

<shawn> requirements have been met.[end change]

Wayne: this change is now in the Understanding document change draft.
... do we still need to explain to those who go from QuickRef to Techniques?
... it would be wrong to go in Techniques cause few of them are sufficient in themselves.

<Andrew> [begin add]Sufficient techniques are provided in a numbered list where each list item provides the technique or combination of techniques that can be used to meet the Success Criterion. When there are multiple techniques on a numbered list item connected by "AND" then all of the techniques must be used. For example, Situation B in Understanding Success Criterion 2.2.1 lists as the third...

<Andrew> ...sufficient technique: SCR16: Providing a script that warns the user a time limit is about to expire (Scripting) AND SCR1: Allowing the user to extend the default time limit (Scripting).[end add]

Wayne: not a functional relationship between a technique and the SC. Most have more than one technqiue to create a sufficiency set.
... look at 1.3.1

Shawn: Calling a tangent

Perspective and Techniques footer text?

<LiamM> Suggest the explanation should be at the point-of-need i.e. when you are in the technique.

Shawn: Right now, the new clarification is suggested to be in the Understanding document but would be missing for those who go from QR to Techniques and back. If you don't go to Understanding you will miss it entirely.

<Andrew> and some of the required info is in the new (draft) techniques intro

[An agenda item is to discuss the submission of comments to WCAG-EM.
... does nayone else want to discuss them? Denis, your comments in the wiki can be pointed to.]

Denis: Most people go directly to the Technique and read nothing else. Information in the intro is OK but the information therefore really needs to be where people are going.

<Andrew> +1 to Denis - need it at the point of application

<Howard> I agree - need some footer info

Liam: Select the situation that matches our content and here is your SC

Shawn: If we had something in the footer, would it be the key points paragraph? One little note with a link to more?

Sharron: Linking won't work to achieve the goal.

<shawn> or the new wording from the Understanding doc?

Denis: make sure that once you get to the Technique level you have the following note: This technique is an effective way, it is only one way, it is not required and it is advisory or sufficient.

<Zakim> LiamM, you wanted to ask if the terminology e.g. 'advisory techniques' is normative

Denis: we always have to go back to verify if it is sufficient or advisory. Each one, even though redundant, should have the 'not required' disclaimer

Andrew: When people are looking at Techniques, do they look at the tests?

Denis: Would depend on situation, most will look for HTML when available, very few (if any) say they read the whole thing

<Zakim> LiamM, you wanted to ask about "for this type of content"

Denis: not sure if we add another paragraph that it would actually help unless we make it very prominent

Liam: Wayne's argument convinced me especially for things like 1.3.1. Essentially it is a set of techniques that should be applied depending on the content of the page.
... tables for example. If you end up on a Technique how to know when you know that your SC is truly sufficient.
... that is missing and is not an easy thing to add. The question is "am I finished yet?"

Howard: Another suggestion from a first time reader. Look for example at G90, you need to add Technique G90, otherwise easy to forget you are on a Techniques page.

Denis: You guys are looking at this based on a page perspective rather than a component perspective. Instead, if you take the object, you can look at what is relevant to a specific component.

Wayne: I am confused myself about how we address this confusion in a way that is clear and correct.

Denis: Much of this comes into question about making content as accessible as we can. That is not WCAG's perspective it is more of a document of conformance.

<shawn> Each numbered item in this section represents a technique or combination of techniques that the WCAG Working Group deems sufficient for meeting this Success Criterion. [begin change]However, it is not necessary to use these particular techniques. Any techniques, whether published by the WCAG group or not, can be sufficient if a) they satisfy the Success Criterion and b) all of the WCAG 2.0 conformance

<shawn> requirements have been met.[end change]

Liam: It seems a special case for 1.3.1, should we make sure that the Techniques associated with 1.3.1 have special language?

Recommendation on Timing

Shawn: In case it goes out right away, we need to look at the language of this draft.

Sharron: But did we make a final decision about what to recommend? We discussed the possibility that if WAI releases a draft now , it could add to rather than address confusion and cause a muddle.

Howard: I have the sense that there is enough concern that we should ask WCAG-WG for more time.

Shawn: Or just take out the introduction altogether and include a note that says we are working on the intro.

Wayne: I kind of don't care which way it goes for time, but the intro as it is now is really unacceptable. They should not publish that draft with that language in the intro.

Shawn: ... is the consensus that we uncomfortable publishing a draft with the current introduction?

<LiamM> +1 remove the jumbly intro

<Andrew> +1 too

<dboudreau> +1

<LiamM> +1

<Howard> +1

<Sharron> +1

<Wayne> +1

<Andrew> +1

<Suzette2> +1

<Bim> +1

Use of WCAG 2.0 Techniques and Failures for policy makers

Shawn: The other point is that last week we tried to look at the proposal for having a separate page that addressed these concerns specifically for policy makers.
next question is to look at the WCAG wiki page and

<shawn> http://www.w3.org/WAI/GL/wiki/Use_of_WCAG_2.0_Techniques_and_Failures

Shawn: Based on the feedback from last week's minutes, the following changes were made. They are proposing this separate document for policy makers and/or to integrate some of this text into main discussion of Techniques in all other documents.
... thoughts?

<paulschantz> very easy to understand

Shawn: Does this help address our concern of how the previous draft undermined the value of the SCs?

Sharron: Yes

Liam: I am not sure how to parse the edits?
... it seems like it needs careful reading, not necessarily a bad thing.

Denis: They talk about if SCs are not required, it is not clear that any techniques are required.

Shawn: They are not clear enough about the fact that any techniques at all are not required.

Denis: What is sufficient? In no way should we conclude that following techniques is a requirement.

<Andrew> suggests "WCAG Working Group's Sufficient Techniques" becomes "W3C's ..."

Shawn: Ignore the edits, let's look at the main part of the document. Imagine if it were ro be published tomorrow on a WAI web page that is "Use of Techniques and Failures"

Denis: I would not even use it.

Liam: There are logical fails

<LiamM> Suggest change "they provide EXAMPLES of solutions that would be sufficient to meet each success criterion." to "they provide EXAMPLES of solutions that would be sufficient to meet a success criterion for a particular type of content."

Denis: My expectation that has paragraphs, sentences, and explanatory text. It looks like it is an emergency document. I want something that says what it is, why it is, and justifies its use.

<Howard> Shouldn't be published - still too much discussion of wording, etc.

<Andrew> suggest first bullet in summary becomes: "WCAG 2.0 Sufficient Techniques" are not the only sufficient techniques and are not only way to meet WCAG 2.0 success criteria.

Denis: ...there is no rationale, I am quite uncomfortable with it.

Liam: Agree

Wayne: Vague, it would be very hard to read this document and know what they meant

Liam: and there are even grammatical errors that could come back to bite us
... and some can be interpreted to be just not true

Andrew: it reads like a document that has captured ideas, but not polished

<Andrew> reads like a brainstorm of ideas to expand on

Shawn: What if we had a nice, clear detailed explanation in Understanding and shorter blurbs in the places we have mentioned, do we still need a separate document for policy makers?

<Andrew> yes

Andrew: Yes

Liam: Yes

<sylvie> Yes

Wayne: Yes

<dboudreau> yes

Howard: Yes

<Bim> Yes

Wayne: What is missing here is a topic sentence, this is meant to solve such and such a problem

<paulschantz> Agree

Application Notes

Shawn: End of our time, please look at the email thread on Application Notes. Bim you can add to the Analysis page from there.

Bim:OK will do since I may not make it to the EO meeting next week.

WCAG-EM comments

Shawn: An agenda item is to discuss the submission of comments to WCAG-EM. ... does anyone else want to discuss them? Denis, your comments in the wiki can be pointed to. We decided to submit, but if members need to make changes, you still can

Wayne: If they get that set of comments from us, we have defined the issues quite well and should be able to use them well.

Shawn: Yes thanks to all.
... may end up having to do Task Force work on specific things with all we have to do at this time.

<Suzette2> Looking forward to getting back to Easychecks - bye all

[Accessibility Question]

Denis: Quick question. Last week I spoke with Shawn Lauriat of Google about what problems we had with the Google doc. Would like detail about last week?

Wayne: I don't use a screen reader and had big problems.Will talk with him at AccessU