In setting priorities, the group agreed to put first the issue of the Techniques documents vs the WCAG itself as a reference for policy. It was noted that some institutions are pointing to techniques - which are meant to be informative - rather than to the normative WCAG itself. There were two points of view that were included in the final decision. First is the important fact that the Sufficient Techniques are a safe and reliable way to meet WCAG and for that reason are valued by organizations that seek conformance. The second issue however was that Techniques can change. In addition to changing technolgy requiring new techniques, it could also happen that a Technique that had been sufficient may no longer be so if dependent on a technology that becomes obsolete. The group agreed to strengthen the language of intent (to meet WCAG, not to require specific Techniques), to simplify the organization of the documents overall, and to emphasize the "safe and reliable" aspect.
Next, Sharron reported that she, Suzette, AnnaBelle, and Andrew had reviewed the sections assigned, mostly Forms and Keyboard. Keyboard edits on the EO wiki are open for comment. Suzette commented on a lack of continuity in the formatting of the various sections, so members are asked to look at that and leave comments on wiki EZ Check discussion page or write to EO list. Current EZ Checks rough draft is posted and question next week will be whether to publish.
Finally, Shawn reminded the group to update availability and complete action items, including the group action items at the top of the page. The meeting was adjourned.
Shawn: First is communications about WCAG Techniques. Next Thursday is a workshop and so our first priority is to clarify the fact that the techniques are not meant to be normative, are not meant to be the exclusive methodology for meeting the WCAG, were not developed with the idea of making them the bisis of policy.
<shawn> Workshop Referencing and Applying WCAG 2.0 in Different Contexts <http://www.w3.org/WAI/ACT/workshop>
Shawn: second priority is getting EZ Checks in place as well as a good reference at the workshop.
... would be nice but would especially be good to have EZ Checks ready for W3C Advisory Committee meeting in mid-June.
... Third thing is the Tutorials. Bim has plenty of work. Need to take a step back and look at format, title, and other big picture questions.
... we have a few other things close behind but for now we will focus on those. For example, we have the EZ Design/Dev and the curriculum work suggested by Howard
... any questions or changes?
... OK then, let's discuss WCAG Techniques Communications
<shawn> WCAG Techniques Communications - Draft Proposal http://www.w3.org/WAI/EO/Drafts/WCAGtechniques
<shawn> previous notes: http://www.w3.org/WAI/EO/wiki/WCAG_2_FAQ_Notes#Techniques
Shawn: As discussed, we have found a tendency for some institutions to focus on techniques even to the point of requiring specific techniques within their internal guidelines or policies. Our task is to figure out how to address that.
Shawn: we may reorganize what is there and in the Understanding docusments.
... Overall approach that we are taking from previous discussion was to put all of the main content in a subpage of Understanding and point the Techniques documents there. A few weeks ago we discussed the possibility of having separate sections for policy makers. Instead we have chosen the approach to have clear language in the main document and have FAQs targeting policy makers, but not to make separate docs.
... Looking at the document now, take a few minutes to look at how the information is presented for discussion.
<shawn> Informative Techniques for WCAG Success CriteriaShawn: Overall comments?
<Vicki> this is much clearer
Andrew: Well done, Shawn
<Bim> +1 to to well done Shawn
Shawn: Now let's put on your policy hat. Pretend you are working for an organziation that has or is going to make Techniques a requirement.
Wayne: There is a specific difference between saying that we only accept Sufficient Techniques and making them a stand alone requirement. Between saying that our policy is to meet WCAG 2 at LEvel AA using Sufficient Techniques and referencing only the Techniques.
Wayne: an institution should be able to say We will meet WCAG2 and the only method we will accept as a standard for meeting it is the Sufficient Techniques.
... I don't think it is good advice for purchasing agents.
... to say they are free to find other ways to meet.
Shawn: What if I have a new technology, come up with a new technique, submit it to the WCAG-WG. During the year of review, what is the institution to do?
Wayne: They will have to wait for the review. I would not waste institutional money and liability on an unproven technique. Purchasing agents for example will not be able to determine if a technique actually is sufficient.
... I think a policy for purchasing agents and less technical people, it is a good idea.
<Andrew> I have been telling people they can use other techniques, but must be able to clearly demonstrate how they satisfy the SC
<Andrew> must have evidence
Andrew: I think telling people here that they can use other techniques is fine as long as we make it clear that the conformance claim is fully documented.
Shawn: Is your persepctive then, Wayne that in some circumstances it would be good for Techniques to be required.
Wayne: yes mostly purchaisng.
Shawn: But in Australia for example there is a movement for the Techniques to be the only way to demonstrate conformance government wide.
Wayne: There is a difference between policy and the way you verify that policy is being met.
... for large institutions like governments we want guidelines that are clear and easy to understand.
... in such case, it is OK to say, use the vetted techniques, but should be separated from policy.
Shawn: But what do you say about the year-long wait for new technologies to be proven and vetted.
... or even worse, where the techniques change and browser support or AT no longer supports it?
<Andrew> new technologies are HTML5 - no specific documented techniques (just the old HTML techniques)
Howard: I can imagine in a university where a researcher wants to use a new technology and is told to wait until techniques are proven, it does not seem realistic.
Wayne: I am worried that vendors will try to use it as an excuse not to meet proven techniques.
Shawn: I am not personally stating a position but am bringing in arguments I have heard.
Bim: The idea that only published Sufficient Techniques can be used is a real disincentive to leading edge developers. I know people, one in particular, who have used techniques other than those published and make great, accessible widgets that would not have been possible using only those that are published.
... because they are informative, because they change, they cannot really be used as a standard.
Andrew: You have new HTML5 techniques, people trying to create, discover new techniques using HTML5. Particularly for mobile, it would be useful to use ARIA, HTML5 for new ways to make things accessible. People are held back by the lack of flexibility.
AnnaBelle: I don't have a strong opinion.
Howard: Maybe we can emphasize in the FAQ. A stronger language discussion of the importance of documenting the way you beleive that you have indeed met the SC.
Sharron:I agree with Andrew and Bim - we will continue to have new techniques, it is important to let people create, discover, and use them. I understand that there are questions about how people are going to verify them, but that's a separate issue and we do not want to be in the position in which accessibility is seen to hold back innovation simply because people in purchasing may not be technical and/or know enough to verify accessibility and make sound decisions)
Andrew:But I also understand wayne's position, the Sufficient Techniques have been proven to work - but it can be a roadblock to innovation
<Vicki> +1 Sharon and Andrew
Sharron:What about if the language strengthens the documentation requirement - if a web author is not using published techniques, there is a burden of proof etc...
Wayne: This is not a yes or no question. In fact in the policy it would be perfectly fine to say that the current techniques (which are always changing) are the ones that are acceptable.
... it is clear that we need a caveat for new technology. But the question was whether we should have clear success criteria at the time it was in development, remember that? The idea was that clear SCs would "stifle innovation>" We may be too soft.
Sharron:problem is that technology is changing quickly PLUS the volunteer nature of the WCAG-WG results in too long a wait to review and accept new techniques.
Wayne: It is not policy, it is practice when an organization adopts it.
Andrew:We might emphasize that STs are a safe way to conform with the SC
Wayne: It might be useful in here to distinguish between policy and internal imlementation rules.
Andrew: To emphasize that the Techniques are a safe and reliable way to meet, but are not the only way.
Shawn: Is that something that comes through clearly enough in this draft...
... time check. Keep going on this or review contributions to EZ Checks?
Wayne: I think we have had a full discussion and maybe we could submit comments to the list.
Shawn: Next week's meeting will focus on the Techniques and in June the EZ Checks will be one of several things they will consider and review.
<Andrew> +1 for continuing techniques discussion
Shawn: giving that timeliness should we continue
+1 for continuing this discussion
Shawn: OK let's go back up to the green box. Andrew's "safe and reliable" comment. So maybe what we have here is too wimpy.
... do we want to add that?...add the idea of confidence that content meets the SC?
Sharron: is the process as long to remove a Technique? in the case of a technique that no longer serves to meet the SC?
... do we have an example?
Shawn: Well, remember that the WCAG-WG is not entirely volunteer. So some of that can happen more quickly. If a Technique became obsolete, it would probably not take a year, but would take a few months.
Sharron: So again, it seems we shouldn't base a requirement on something that can change
Wayne: You can always base a requirement on the most current version of a standard.
... but that is all you can require an organization to do. That is how the law is written.
Shawn: Let's shift to the bigger picture of how do we communicate the overall issue?
... many people have missed the big picture of WCAG itself, how the techniques are related to the Success Criteria.
... so how do we correct misunderstandings and introduce the topic correctly to those who are new to it?
<Vicki> +1 looks clear
Wayne: To say the WCAG does not intend them to be required is important.
Shawn: Andrew, now that you understand what the point is of this document, how does that impact your first wiki comment?
Andrew: Yes, related to the observation of intent.
<Wayne> … you meet the success criteria. They are safe and reliable.
Wayne: It could be freeing in some ways for developers to understand our intent was not for them to be required.
Andrew: And what is not quite clear here is the differentiation between W3C Sufficient Techniques and any others that may exisit.
Shawn: yes and I have gotten that input from other WAI chairs
Wayne: In fact, in the techniques the 'must' and 'should' parts are what actually make the technique work.
... if we are trying to distinguish between that it must and should to make the technique work and that it is NOT a must and should to conform to WCAG
Howard: Reference to FAQ shouldn't there be a link to the SCs
... also there is talk about informative and it is a bit confusing in trying to understand the difference
Shawn: Put on your newbie hat, policy hat, whatever you need to make the document less confusing, more clear
AnnaBelle: I found it quite clear
Vicki: I got confused in the discussion about Advisory Techniques. It seems contradictory. I had little confidence for using them as I went through the bullets but was then "encouraged to use them"
Shawn: The point is meant to be that they are good, you are encouraged to read them, but here are the reasons why they are not Sufficient. Bulleting them may bring too much focus
Vicki: Reading it as it is now, there is so much negative that I get discouraged about using them, especially if I had no idea about what the difference is and why they would even be useful.
Shawn: Shall we put the "here's why we think they are good" up front and remove the bullets?
AnnaBelle: I like them as they are
<Andrew> tersify the reason they are not sufficient :)
<Howard> + 1 for AnnaBelle's point
Vicki: They are good for readability but it also draws focus to the fact that there are many reasons why they are not Sufficient so perhaps I should not use them.
<Howard> +1 for AnnaBelle's point
Shawn: Should we make the opening, positive comment stronger.
Vicki: Yes we should try it.
Wayne: I agree with Vicki. if we put a strong positive emphasis up front and bracket the part about why they are not sufficient.
Andrew: We need to tersify the reasons they are not sufficient and add a closing affirmative reason to use them.
Shawn: This is very useful to me, other thought about how this lands?
... and remember you can put comments in wiki review page
Howard: Anywhere we have reference to Sufficient Techniques, Advisory Techniques, we link to a glossary or another way to understand what they are and how they work.
Shawn: We want this to be the defintion.
Howard: I might still not know what it looks like, so it would be good to have an example to fully understand. Otherwise, I do not think this document explains as well as it might.
... an example is always helpful
<Andrew> good AT example is "Avoiding centrally aligned text" under GL 3.1
Vicki: Within testing, I am not comfortable with the term "discrete"
Shawn: The point is that it is not to be viewed in isolation
Wayne: The paragraph starting "Conversely..." I am having trouble with it.
Shawn: Will work on clarification
... I need to explain as well the accessibility support. Adding technology considerations, etc
Wayne: And the hierarchy is a bit confusing etc
<Andrew> +1 to strengthening the 'accessibility support' requirement in the tests section
Shawn: There are many subheadings. I wonder if it would be good to kind of map it out with bullets in the intro?
Wayne: It could be
Shawn: The current proposal is to take nearly everything out of the techniques. The green box will be for the doc Understanding WCAG2.0, the red box is for the Techniques. Are we comfortable with that?
Howard: I find the link back to informative confusing
Wayne: I tripped on that too
Howard: Should the link be back to Understanding?
Shawn: Basically I think in the Techniques then we will take out the link that adds confusion.
Andrew: The Understanding is a series of pages linked from within the Techniques and the 'informative techniques' page is one explanatory page within Understanding.
Shawn: Are you comfortable with the techniques document having these few key points and pointing elsewhere for main discussion?
<paulschantz> not sure
<Vicki> Have to leave. Bye
Paul: I think the Techniques may not be special enough to be broken into its own separate section like this
Wayne: It is kind of a laundry list of all techniques you might be able to use in no particular order.
Paul: I find myself bouncing between the separate sections and wondering why they are separate?
... does it really need to be separate?
Shawn: Good point, it is an artifact of how things are currently in place
<paulschantz> in that case, +1
Andrew: We are trying to clarify the information currently in those documents and make them more useful.
Wayne: We don't want new people to think they must read the techniques document that may be overwhleming and not useful.
Paul: OK that makes sense
Shawn: And there are FAQs and we are proposing to add the note to each technique that these are informative.
... they had added text and we are suggestion that it be a bit shorter.
Howard: Are these different boxes meant to be separate pages, different documents?
Shawn: Bits of text meant to be plugged into different, already existing documents
... OK, anything else for now?
Wayne: In the FAQs are there only these few things to add?
Shawn: Not sure if we want to keep two different questions, may want to polish these.
<Andrew> +1 to two separate FAQ questions
Shawn: We have had a few comments from WCAG-WG. I will be making changes after the call and through out the day
... thanks this is important, relevant and timely to the workshop next week.
Andrew: Where does the KeyPoints document fit?
Shawn: Not sure might be in a blog post when we post for review
... don't know what will happen in the next week and how the work on this will be incorporated into the workshop. You may or may not know that we have a change to the chairs of WCAG. Lorretta and Gregg have stepped down though they will continue as members. New chairs are Andrew Kirkpatrick and Joshua O'Connor of Ireland.
Shawn:Sharron, can you review what progress was made this week?
Sharron: AnnaBelle, Andrew, Suzette and I reviewed the sections assigned, mostly Forms and Keyboard. Keyboard work on the EO wiki is open for comment. We are feeling like most of the sections are now ready to post in draft format. Suzette commented on a lack of continuity in the formatting of the various sections, so members are asked to look at that and leave comments on wiki EZ Check discussion page. http://www.w3.org/WAI/EO/wiki/Easy_Checks or write to EO list. The current EZ Checks rough draft is posted here http://www.w3.org/WAI/EO/Drafts/eval/checks and the question next week will be whether to publish.
Shawn:Thanks everyone, remember there is much ongoing work. Check the top of the EO Home page, report on your availability for upcoming phone conferences, remeber to update your actions items, and have agood week-end.
<Bim> Cheerio all.