Training Pages

Shawn: Andrew finished and sent those this week. I did not send the survey because we were focused on reviewing WCAG-EM.

Andrew: I am also updating the notes for the change log.

Shawn: Ready for review but we have a higher priority with the evaluation materials. Will put the survey out next week, most likely.

WCAG-EM

Shawn: Let's talk about that also in context of the Preliminary Evaluation materials that Denis is working on.

<shawn> eval suite: http://www.w3.org/WAI/eval/Overview.html

Shawn: WAI has a suite of evaluation materials
... most was done several years ago and need updating. Most in need of revision are the preliminary review (on our plate) and the conformance review (will probably be replaced by WCAG-EM)
... Preliminary review is less formal, the WCAG-EM will be more formal, may be a Note but could be a Recommendation.

Andrew: When you say that WCAG-EM may replace the Conformance Review, how will that work?

Shawn: Probably have an Overview with introductory information that links to the materials.
... if we are saying WCAG-EM is primarily for reviewing an existing web site, we know there is a need for review through out the process. In order to put them in context, do we want a separate document about how to evaluate through out the design process.

Wayne: The integrated evaluation guidance is the missing piece. But we could do a concise 10 step piece that would be very helpful. It's important.

Andrew: Agree

Shawn: Denis were you thinking for the PreLim Eval to address this?

Denis: I was thinking of existing pages for that document as well rather than during the design process. You saw the outline I sent to Sharron and Ian.

<AndrewA> we still need a page for non-techies as per Denis' proposal

Shawn: We would want to keep the one pager separate from integration suggestions.

Wayne: Is this WCAG-EM document going to be normative?

Shawn: Not sure, that is part of the discussion. What are your thoughts?

Wayne: If it will be normative, I have a very strong objection to the mention of vendor preference formats

Shawn: The current plan was for it to be a Working Group Note, but there is discussion of whether it might be a Recommendation.
... sounds like we want to explore the creation of a new page - Integrating Accessibility Testing into the Design Process. Should look at how it
... relates to other documents.

Denis: Should be created together so they complement each other.

Shawn: That would be great.

Sharron: Would it make sense for Denis, Ian and I to work on that together with the PreLim Eval?

<dboudreau> i agree

<shawn> also have specific contexts, involving users, & others...

Wayne: When we were working with all of the developers at the CSU System, we had a 7 point quick review plan.

Wayne: We found particular tests that would reveal a flaw in several areas. We carefully looked at failures and how to flag errors very efficiently.
... we can give developers quick and valuable tests that will show results.

<scribe> ACTION: Wayne to share 7 point review created by himself and Tom for the CSU system. Will place in wiki with attribution. [recorded in http://www.w3.org/2012/09/28-eo-minutes.html#action01]

<trackbot> Created ACTION-210 - Share 7 point review created by himself and Tom for the CSU system. Will place in wiki with attribution. [on Wayne Dick - due 2012-10-05].

Suzette: Looking at where this goes, seems like it bleongs with the designing for inclusion set of documents rather than the evaluation set.

<AndrewA> good point from Suzette

Shawn: We have an implementation plan for accessibility. Maybe the Evaluation throughout design should be housed within the set of design documents.

Denis: Why would it be better placed there?

<shawn> Implementation Plan <http://www.w3.org/WAI/impl/> is very high level

Suzette: It is about helping people find the right materials within the places they might expect to see them.

<shawn> some of this also in <http://www.w3.org/WAI/impl/improving.html> & <http://www.w3.org/WAI/users/involving.html>

Suzette: in implementation we would talk about how you get formative input that allows changes.

Andrew: Sure, that makes sense. If a designer is looking for considerations of what they need to think about during the design process, they are not likely to look in evaluation. So it would make sense to have the integration testing guidance in the design section.

Shawn: While we can point to it from a number of places, the document itself may be better aligned within the design process documents.

Denis: Yeh, I guess it does need to go elsewhere, but definitely needs to exist.

Shadi: Wayne, send Tom my fond regards. He developed all the evaluation pages on the BAD.

Shawn: What do we have for actions on this?

Denis: Then working on this should be in conjunction with the roles rather than the Prelim Eval. So a separate group working on that is probably best.

<scribe> ACTION: Shawn to start page on wiki that maps where we have design process-related materials throughout EO reosurces. Then [recorded in http://www.w3.org/2012/09/28-eo-minutes.html#action02]

<trackbot> Created ACTION-211 - Start page on wiki that maps where we have design process-related materials throughout EO reosurces. Then [on Shawn Henry - due 2012-10-05].

<AndrewA> yes, http://www.w3.org/WAI/users/Overview.html is related to "designing for inclusion" along with others - nice to aggregate for designers/developers

<dboudreau> @shadi - in its broader sense, absolutely ;p

<scribe> ACTION: Suzette to take list of design-related materials to see what needs to be updated and specifically how to inlcude a guide for integrating evaluation into design. [recorded in http://www.w3.org/2012/09/28-eo-minutes.html#action03]

<trackbot> Created ACTION-212 - Take list of design-related materials to see what needs to be updated and specifically how to include a guide for integrating evaluation into design. [on Suzette Keith - due 2012-10-05].

Shawn: Any other questions about how the PreLimEval fits with WGAC EM?
... Shadi, do you envision that when WCAG-EM is done, the conformance document becomes an intro document that points to WCAG-EM?

Shadi: Yes, that makes sense. If the group feels that WCAG-EM is far enough along to meet that need. The Conformance doc could be a good, less formal overview and introduction. It could highlight keypoints, 5 major points and so on. The summary may be enough to get people started.

Shawn: Denis, would it make sense for you to draft that overview document?

<shawn> Old conformance page <http://www.w3.org/WAI/eval/conformance.html>

Denis: Yeh, for sure. That would make sense.

Shawn: So we will rewrite this page as an introduction to WCAG-EM but also provide high level guidance on evaluation.

Denis: For most people who are new to this, there are many things they need to understand before they can make sense of WCAG-EM and know what to do with it.
... even though our intent with WCAG-EM, was to provide a widely applicable resource, in most cases the scenario is going to be that people come here looking for something lighter in tone.

Shawn: Making the point that to get to conformance is an entirely different level of testing than a quick idea of whether or not an interface may or may not be generally accessible.

Denis: Yes, it has been useful to my clients providing them with quick ways to understand barriers.

Shawn: Will you add that as a use case?

<Wayne> I agree with Denis completely!!

<shawn> use cases: I commissioned a website that was suppose to be accessible. I have the protoype - is it OK?

<scribe> ACTION: Denis going to add to wiki the use case of a preliminary evaluation to see if the most common errors are present and easily found. If so, would lead to the need to do full evaluation using WCAG-EM [recorded in http://www.w3.org/2012/09/28-eo-minutes.html#action04]

<trackbot> Created ACTION-213 - Going to add to wiki the use case of a preliminary evaluation to see if the most common errors are present and easily found. If so, would lead to the need to do full evaluation using WCAG-EM [on Denis Boudreau - due 2012-10-05].

<shawn> use case: disability advocacy group...

Andrew: Some use cases could also relate to graphic designs and other development stages

Shawn: Yes and anyone can add use cases to the wiki

<shawn> add goals, audience, use cases, etc to Discussion tab here: http://www.w3.org/WAI/EO/wiki/Talk:Web_Accessibility_Preliminary_Evaluation

<shawn> WCAG-EM light

<Wayne> I entered my issue with vendor preference in the the EM wiki -- especially with a normative document.

<AndrewA> +1 to EM light

Shadi: So the idea of a light version, I would encourage us not to think of just one or the other. There is an entire spectrum of possibility within the evaluation process. May use techniques from both. Lots of cross over.

<shawn> use case for conformance page w/ WCAG-EM light: I'm commissioning someone to do a formal evalaution with WCAG-EM. I want an overview of what they are going to do.

<shawn> ^^^ add to wiki page

Denis: How I ended up with that suggestion is because when we deliver reports to clients, they usually do not understand. Only when it is passed along to the developers does understanding begin to happen. So we end up with elements in a Executive Summary that prioritizes the findings and work with executives to focus on the most improtant ones.

Wayne: Another use case is post-design. Where developers have been handed a project to do, they have the specs and they want some way to know they are on the right track for accessibility while they are developing.

Shawn: Good, seems we are in sync on this. Please add that to the wiki, Wayne and all.

Jennifer: When I read WCAG-EM last night, I kept wondering about whether people will actually read this and is it really what they want? Or do they want some version of the dreaded word - checklist. Something like the Canadian gov widget, etc. Has any thought been given to providing people with resource links that allow them to not have to reinvent the wheel?

Denis: A good way to address this concern would be to come up with a series of documents that accompany the WCAG-EM - like the Techniques that support WCAG itself. We can't get away from the checklist, we all use them.
... I think this is something that could be done.

Jennifer: it has been done on many sites, in many useful ways.

Wayne: I think this WCAG-EM document is significantly different and while it could be made more readable, we must recognize its unique purpose. It is different because of its authoritative stature. How would a person build a defensible case for accessibility? It is not a quick thing, it is an authoritative guide.
... I have not seen it done so well in one place before.

Jennifer: I was not suggesting that a check list replace this, not my point at all. My point is that there are many resources that do something similar. Everyone has remade these evaluation tools and pointing to exisitng ones could save people frustration.

Sharron: Wayne's case good is a good one, but there will be many, many, many, many more that need less rigor.

<shawn> ... tools available to help people

Shadi: Thanks Jennifer for raising the point. It is a discussion that we often have in the WCAG-EM work. But I do want to agree with Wayne that this is a more process oriented document. How do you develop the process within your organization to verify accessiiblity?
... we have resources in the WAI-ACT project to follow on work focusing on evaluation tool developers on how to better support WCAG2
... third item in the plan is to evaluate the interface, perhaps an updated Quick Reference widget.

Denis: Is there any possibility that at some point, the testing methodology could be referenced in the Techniques document itself?

Shawn: It is on the bottom of each Technique.

Shadi: It is but it is at the very bottom and often missed. We have been looking at a number of interfaces that will present the information in a way that is easier to find and use.

Denis: But even the test is not descriptive, does not say actually HOW to test.
... the details may not belong in the Techniques document, but there is a need to show how to do a specific test and to know what is the meaning of the test outcomes.
... what tools to use and how to know if the test is good or not. I am convinced we need more specific methods.

Shadi: But once you reference specific tools, there is the risk of being outdated.

<shawn> [ Shawn notes that we *can* update the Techniques - and WCAG WG welcomes input]

Shadi: but your example of headings is a good one, could be generic and still more specific. I would encourage us not to create yet more documents but to improve the Test section and documentation of failures with the Techniques documents.

<Wayne> Tool set is the key word.

Denis: having a checklist that actually tells you what to test, how to test, and how to interpret test results, would be tremendously valuable. If we want this to create consistent outcomes, we should endorse specific testing methodologies as well.
... maybe we DO new documents or Application Notes that we spoke about earlier.

Wayne: One caution about looking at different tools all over the web. A committee I worked with at CSU took two years looking for tools to test educational interfaces. If you want to go out and sort through all the tools that could be viable solutions, it is a very lengthy process. for the amount of good testing and evaluation recommendations out there, there are 20 things that are not very professional and not very accurate

Shawn:I wonder about a Tools DB? Maybe list on WAI-Engage? Let's keep thinking of the wish list and scope it to what we can actually get done.

<AndrewA> and many people don't know the different between the 1 good and the 20 poor/bad resources

<Wayne> Manual Evaluation Guide

Shadi: We could link to a list of tools that can help you find the right tool or a choice of different tools that people might choose from.

Shadi: encourage people to think about how Techniques might be rewritten and/or presented in a different way that will help people find what they actually need and to learn to test in ways that they can have confidence in.

Wayne: I have been thinking about an outlined heuristic to give a developer the idea that he/she is in the right ballpark. So rather than a widget or a tool, more of a guide that groups tasks into meaningful sections that will allow you to have an understanding of the actual status.

Denis: What working group updates the Techniques documents and what is the process?

<shawn> Techniques for WCAG 2.0 submission form <http://www.w3.org/WAI/GL/WCAG20/TECHS-SUBMIT/>

Shadi: The Techniques are developed by the WCAG WG but we should not think of it as a territorial way. Much has been strongly written from the POV of content authors. But EO has a strong role and should/can provide the guidance for how they can improve. Much shared responsibility

Shawn: WCAG WG would have to approve any changes, but EO is encouraged to submit suggestions.

Andrew: Working with Success Criteria and the Techniques, we need to consider how to make this stuff more usable, understandable for end users. Need to include the idea of context for many of the Techniques.

<shawn> ACTION: Shawn check WCAG-EM wording on SC not techniques for conformance [recorded in http://www.w3.org/2012/09/28-eo-minutes.html#action05]

<trackbot> Created ACTION-214 - Check WCAG-EM wording on SC not techniques for conformance [on Shawn Henry - due 2012-10-05].

Shawn: Good discussion thanks all. I will start and update wiki pages to get some of these things documented. Anything else for now?

Wayne: In reading it last night, the whole issue of front matter in W3C documents really came jumping out at me. It takes so long to get through it.

Shawn: That is not something that we can easily address, although I continue to discuss at the W3C level.
... let's look at making the Conformance page the place we will point people.

Andrew: Particularly as we refer to techniques of evaluation, we can deep link into specific section of WCAG-EM and bypass the front matter, can't we?

Shawn: What issues might people have with deep linking?

Jennifer: I tend to like it, especially in W3C documents.
... One comment about the current WCAG-EM draft is gosh, it is so link-filled. Like linking to "web page" definiton every single time it is referenced... phew!

Shawn: Please submit that comment directly

Wayne: I noticed that as well when listening to the page

Shawn: We had broad questions posted to the wiki. Wayne and Vicki submitted specific comments for discussion. Wayne?

Wayne: In the scoping section, they talk about controlling browser and assistive technologies. Don't know how you can scope the way a person uses his/her own assitive technology. Whatever they mean is unclear and must be clarified.

Shawn: The issue is to make clear that the assistive technology use is known rather than AT choice is defined?

Wayne: Could open the door to job descrimination.

Shawn: Yes, need to clarify that the way this is stated can have serious consequences.

Wayne: Also when they do the sampling, they are not thorough enough in how to find critical samplings on very large sites. I believe they really need focus groups to help them identify a proper set of sampling pages.
... number of hits won't tell them that, especially when you have heterogenous users.
... don't need to change but more to add to. Should add that in addition to analysis, focus groups can be tremendously helpful.

Shawn: Can you write this up Wayne, with a bit more of the explanation you just gave?

Andrew: The section on how to distinguish between sub sites or a set of various separate web sites that are aggregated for example in a university setting.

<AndrewA> see: http://www.w3.org/TR/WCAG-EM/#website

Wayne: Yes, there are organizations that are kind of confederacies and the content really is organized into are separate sites that should have separate samples.

Suzette: I put a comment on the wiki just before the meeting started, having to do with the readability issue. The construction of the information itself is quite difficult to navigate through. I suggest we look at the use cases a bit more to guide how to better organize the materials.

<Wayne> Next time a discussion of readability is good +

Suzette: A better defined set of use cases, from very large organizations to smaller, more easily managed ones.

Shawn: Do we want to give a couple of more specific examples?

Suzette: I suppose I could do so, will look more carefully at where examples are given and see how to suggest others.

Shawn: Yes and considering who is most likely to go through this formal rigorous methodology?

Suzette: If developers are the main audience, this is not written for developers.

<AndrewA> govt, education institutions, banking sector, large retailers, utilities - key audiences?

Shawn: Yes we sometimes struggle with the need to be technology neutral while being helpful to developers and policy makers at the same time
... may be time to emphasize the need for readability.
... and in the Conformance intro doc, try to be quite clear and readable and then point to the idea that if you need formal conformance documentation you will want to read WCAG-EM.

Wayne: Then we should address readability specifically.

Shawn: So maybe we can focus on how to make our wiki page a good vehicle for that over the next couple of weeks.

Shawn: I will do some structuring right after this meeting and we will be sure to add actions for all to contribute.

Wayne: Good and important document.I think this is really an exciting and potentially very useful set of materials.

Reminders

Shawn: Rmember to update avaialbility and check action items.
... also there are actions at the top of the EO home page, please do not forget to check those and try to put in some your time on those items...anything else for now?
..hope everyone has a good weekend, watch for the survey invitation.