> EOWG home > EOWG Minutes
<Andrew> I like title suggestion #1 (i think)
<shawn> scribe: Justin
Judy: General Comments
Andrew: Better and Better
Judy: Specific Questions
Shadi: I took a look at scoping the document
and how the title's covered things.
... What are people's reactions to taking out repair and focusing on evaluations? Putting repair into evaluation?...manual evaluations? Once this documents is set we can go back to the list of tools and make it compatible.
... What do people think about taking out repair tools and making it a feature of evaluation tools?
Andrew: I like that approach.
<shawn> I support it strongly
<rcastaldo> I like it too
Shadi: Manual tools, in section 2 the last paragraph this talks about the manual tools I was thinking about when I was writing this document.
Harvey: I think the comment is well stated.
Shadi: The sections are Intro, Types, Features
Roberto: about section two Jim not sure it can be helpful, when we try and make a classification we must agree on one type of criteria
<Helle> My phone is out of order so I can't call you, will try and fix it and join you ASAP
Roberto: At a type of classification a tool should only fit in one, but most tools can fit in more then one section
Judy: The classification is unworkable because
there is so much overlapping. Some are talking about input and some are
talking about output.
... Maybe we can talk about in this section ideas about input and output configurations or maybe take that criteria below in section 3.
Andrew: What we have here is not category
because most overlap. These are major features.
... These types of features are worth drawing out. The questions in section 3 are much more detailed.
Shadi: Roberto's descriptions make perfect
sense. I think people need some handles otherwise it will become too big of a
group. Maybe we can play around with the type or the intro paragraph.
... Maybe there are other ideas like creating more sections or criteria.
Sailesh: I'm not sure if the categorization is really helpful.
Judy: Shadi, You said you expected people would
need some type of categorization.
... Do people need that?
Andrew: If you possibly can.
Chuck: I think that part of the problem is putting distinct headers on each of sections. It would be hard to target them under those exact pigeon holes.
Carol: Maybe bulleted list
Judy: In another document...we had a short list of questions. Maybe takeout the subheads and add a short list of questions.
Andrew: We could highlight some keywords to draw peoples attention to parts.
Chuck: Both ideas sound good.
<rcastaldo> My line went down
Judy: I was picturing something like...general characteristics of the tool your thinking of...does it generate reports...does it have a wizard interface?
<rcastaldo> I'm back again
Wayne: We are just talking about the different user interface elements.
Sailesh: Reports are a part of user interface.
Everything that that is their under type is part of the interface.
... How does categorization help the user?
Shadi: I think there is more here then the user
interface. It's the usage of the tool. There is a difference between the tool
that gives a report and the tool that is manual.
... Maybe it is more the characteristics of web evaluation tools.
<Andrew> Yes - 'characteristics' is good
Shadi: I like the idea of taking out of the subheads
Andrew: I think characteristics is much better.
Chuck: I agree
Wayne: I think that sentence of how they influence your process.
Judy: Calling it type of characteristics would
be sufficiently different. Does that division hold up.
... The questions in section 2 are those if those are general characteristics does that hold up.
Shadi: Wizard interfaces they would check a number of pages at once, shows they have the more specific characteristics in section 3
Judy: Taking out the subheads in section 2, any disagreement?
Shadi: There were comments, is there a too strong focus on experienced developers?
Harvey: A lot of these tools are educational tools, you can learn from them.
<shawn> i think i agree with Sailesh
Sailesh: Education isn't there primary purpose. It shouldn't be used to evaluate.
<Andrew> I agree that education is secondary benefit
Shadi: It may be a reason whether to use it or not.
Sailesh: What is accessibility should not be in the tool.
Shadi: Does it match this audience or does the tone need to be tweaked?
Judy: Do you think a newbie would freak out because it is so complex?
Shadi: Is the word experienced too often? is the developer too often?
Judy: We need to do an audience check now that the document is more mature.
Andrew: We identified the primary audience is developers. We assume they have technical skill.
Judy: Do we need a softer intro?
Andrew: We send them off to the Conformance Evaluation page.
Judy: That page is not a light landing.
... Maybe we want to check back later with this the next time.
Wayne: I have a group that I am concerned about. My professors that are making web sites for students and those people aren't even going to bother with this.
Judy: Sounds like lots of universities
Wayne: People will not now what tool to select and they will come to this document.
Sailesh: There are QA people that do checking also. The people aren't developers but just checkers.
Harvey: The intro doesn't say who the audience is. We are having to infer that.
* Primary audience: Web developers (designers, content authors, etc) who want to comply with Web accessibility standards
* Secondary audiences: procurement officers, professional evaluators, and accessibility researchers
Judy: Lets come back to this later.
<Andrew> audience - I think "professional evaluators" should be part of the primary audience
<shawn> shadi, I think you only need a little more for requirements (in addition to what is in the change log): add purpose, goals and any important notes
Shadi: first and second items we have covered
... number 4 we have talked about that a little bit. Do people feel that this maybe should be better taken out of section 3?
... How helpful are the educational documents of the evaluation tools?
Andrew: I think its important but maybe should be de emphasized.
Carol: Maybe about the usability of the educational material.
Shadi: comment 5, is the focus just on web content or web sites?
Andrew: I prefer page or site, when i talk to people about web content they forget web applications.
Shadi: When we talk about sites we imply crawling.
Carol: I think site is more inclusive. Web content is more just words.
Sailesh: Some tools just evaluate a page.
Andrew: Sometimes you want that
Carol: It's helping you evaluate the site.
Shadi: Comment 6, do we need to say it helps web accessibility? The reporting and repair should improve web accessibility.
Andrew: The tools help the developer improve web accessibility.
Shadi: Tools to a certain extent that certain evaluations don't need to be done. That helps efficiency a lot. Is that covered? or are their spots where people find it a bit needy?
Andrew: How does a tool know whether or not you should have headings on a page or not.
Shadi: Next set of comments are from Chuck.
Shadi: What do people think of his rewording?
Chuck: This wording does not merit such a long amount of thought.
Shadi: I'll put them in the change log
... Next comments are from sylvie
Next comments are from Roberto
Shadi: Its a wording comment.
Next comments are from Andrew
Shadi: in section 3 he suggest that "stress than no tools (for WCAG 1.0)
can test all Checkpoints and that the organization and/or evaluator will
probably require a combination of tools to undertake a comprehensive
Shadi: What do people think about how people
will want to use more then one evaluation tool?
... Often people think it is more then one expensive tool.
Shawn: Lets mention it but de emphasize it.
Shadi: Andrew is suggesting in the integration
part about how plug-in integrate into the development process of the
... as well as browsers
Andrew: Many developers will use many browsers.
Sailesh: How about a section about who it benefits?
Shadi: Does the subsection of the intro not hit that enough?
Carol: Does features work better?
Sailesh: That's what in section 3.
Shadi: A new section how a tool might help a certain audience.
<rcastaldo> What about a new subsection in the intro??
Shawn: I think in general we don't need to sell evaluation tools and what they can do for you. The simpler the document is the better.
<rcastaldo> I have to leave the meeting for two minutes... be back soon
Judy: Many people do have that question in their heads. A lot of the time they think evaluation tools will do everything for them. Maybe a bullet on a philosophy for using them. We can bound them a little.
<rcastaldo> I'm back
Shadi: does the benefits of tools belong in this document?
Judy: I think there is a benefit in this
document. Is there concern we are doing too much or too little?
... Sailesh, you were feeling that what we have in the intro is not enough.
Sailesh: If there is a section or heading we will be able to highlight that better. It could better help the types of evaluation tools.
Judy: I want to check if there is anything else
that people have spotted?
... How many of the visual feedback tools are accessible?
... is there are more generic way of describing that's not exclusive to some disabilities.
... Is it just a feedback tool.
Justin: Page-integrated feedback?
Carol: Display feedback?
Judy: It sounds like we are putting forward a single modality.
Shadi: I will be taking back and changing this section so considerably.
Judy: With each version the feature list grows...are there things about the features and what's listed that isn't hitting well with people.
Harvey: We need a list of references.
Judy: We need a jargon patrol, to take out the unnecessary jargon. We then can link to those documents.
Judy: Anyone who is participant in good standing needs to log under this.
Sylvie: Can we use our tech plenary password?
Shawn: Use the same one
Sylvie: Do I have to resubscribe to the mailing list?
Judy: With regarding to your organization we would to see if they want to become a w3c member
Chuck: I have already done all of the automated procedures. Will i get two copies of the mailing list?
Judy: We are going to purge the participants in good standing list in the next 4 weeks.
Shawn: Components Document has a scary title
... Can we revisit it? We want to have something that encourages people to read it.
<shawn> Here are some brainstorms on other approaches for titles:
<shawn> 1. Dependencies in Web Accessibility (or Web Accessibility Dependencies)
<shawn> 2. Requirements of Web Accessibility (or Web Accessibility Requirements)
<shawn> 3. The Web Accessibility System
<shawn> 4. The Parts of Web Accessibility
<shawn> 5. Understanding the Components of Web Accessibility
<shawn> 6. Web Accessibility Depends on:
Judy: Why we need three WAI guidelines
<Wayne> The big Picture of Web Accessibility
Charmane: Component Interactions
Harvey: How To get Web Accessibility for All
Andrew: I liked dependencies.
Charmane: Dependencies doesn't make sense to people
Judy: I have a similar opinion.
Shawn: If people can comment or brainstorm on the list that would be much appreciated.
Wayne: Its a subtle topic that may not lend it self to a simple title.
Shawn: The primary motivation for this is for
people looking for how to make something (forms, images) accessible.
... This would be quick and temporary.
... Is the goals and mission right? What would it contain? Peoples reactions?
<shawn> Early concept draft: http://www.w3.org/WAI/intro/html-techs.html
<rcastaldo> I've got to leave the call. Bye everybody
<shawn> ACTION: Shawn add to http://www.w3.org/WAI/intro/html-techs.html pointer to header
<Andrew> "headings" needed to be included in the list of examples