We did not minute much; most of the discussions were captured by edits directly in the documents.
The agenda morphed from planned; it roughly was as in the F2F meeting page.
Discussion of the document and point by point changes suggested.
<scribe> ACTION: Andrew to Investigate pros and cons of keeping URI of Prelim Eval -OR- create a redirect. [recorded in http://www.w3.org/2013/02/25-eo-irc]
<trackbot> Created ACTION-279 - Investigate pros and cons of keeping URI of Prelim Eval -OR- create a redirect. [on Andrew Arch - due 2013-03-04].
Wayne: Must be clear that this is meant as an audit document. Not meant as a development tool.
... should need to remove "can be used for other purposes" especially the part about developers during development.
Shawn: developers is not an audience included in the documentation of targets for this document
<Zakim> Andrew, you wanted to ask about the 'working draft' link
Andrew: Unless you must demonstrate formal conformance you may not need to go through the WCAG-EM process.
Wayne: But there are many educational aspects inlcluded here
Helle: And they will also use it in the EU for benchmarking
Wayne: Proposes that we eliminate developers from Who Will Use
Andrew: Or say instead "web devs who waht to understand how it will be evaluated"
Wayne: This is too broad - this document is an audit process document. it is NOT for all these other groups.
Sharron: Yes and it is a distraction to inlcude groups who may be peripherally interested but not actual users.
Helle: it will be auditors of government regulators, corporate, educational, or third party consultants.
... not necessary to list all of them.
Jennifer: Internal or external auditors.
Wayne: both are necessary
Sharron: It is for the direct use of auditors and benchmarking. Also referenced by procurment and management.
Wayne: WCAG-EM is for people who want to spend an exciting life in Web auditing.
Jennifer: Disability advocates are listed on the Editor's Draft but truly, that group will not use it.
... and teachers, if they are training someone to use it, of course will use it but do not need to be called out as an audience. If youa re teaching any topic, you refer to the topic.
Andrew: In the needed skills, is it strong enough to say "knowledge of WCAG?" Is that strong enough?
Wayne: Can we less specific, say dark text on light background for example and bright text on dark background.
Wayne: There are pros and cons of each type of testing tool for color-contrast:
First is the code based testing tools: Pros are easy to run, fast; cons are that it is can show up false failures.
Wayne: ...Second is the
eyedropper is quick, you focus on the ones that could be a
problem and you get accurate result. Con is that it is tedious,
one by one, requires sight and mouse use.
... Finally is the brightness tool, it is quick, experiential. con is that it requires sight, inaccurate will only raise a flag
Shawn: Rather than say what the
basis - code, eye dropper, brightness - say what kind of result
the tester will get. A table of values, with yellow highlight
of questionable outcomes, a visual output
... of forground, background and contrast value. Third would be a greyscale representation of the page.
Wayne: drop off the opening parentetical statement
Conclusion is we will not inlcude the check for font size largest becasue it requires a specific old browser that most people don't have.
Shawn: When page is zoomed,
either the whole page or just the text, make sure they don't
overlap of get cutoff?
... is it important to distinguish between text only zoom vs entire page zoom.
<shadi> WCAG-EM focuses primarily on conformance evaluation of existing websites. Other aspects of evaluation are addressed in related pages of the Evaluating Web Accessibility resource suite. For example, guidance to help you better understand real-world accessibility issues and evaluate effective accessibility solutions is in Involving Users in Evaluating Web Accessibility.
<shadi> Note: Accessibility should not be left until the evaluation stage; it should be integrated from the beginning and throughout the project lifecycle â€” in planning, design, and development.
WCAG-EM is primarily for evaluating conformance of existing websites. However, accessibility should not be left until the evaluation stage; it should be integrated from the beginning and throughout the project lifecycle — in planning, design, and development.
Other aspects of evaluation are addressed in related pages of the Evaluating Web Accessibility resource suite. For example, guidance to help you better understand real-world accessibility issues and evaluate effective accessibility solutions is in Involving Users in Evaluating Web Accessibility.
Wayne: When we implemented web accessiiblity the people who decided what web developers should know (at UC long beach) were disability service coordinators and administrators. They would read pages like the WCAG EM overview or other overview docusments everywhere.
It didn't work very well becasue this assignment was far too big for the scope of most devs. They checked out and thought accessiiblity was too big, too hard and the things they needed were not provided.
scribe: so since this is not in the day-to-day tasks of the coders and developers.
... it is seen to be irrelelvant.
Shadi: I agree with the past targeting being inaccurate. However, we do that in WCAG-EM. The Overview does not target developers and the WCAG-EM itself includes them only in a general way.
Wayne: We really need to take on that list that is in the main document. It is too big, they are not all inlcuded in who the docuemnt really IS for.
... if Tom and I had that at the time, we could have used it.
Shadi: Maybe keep the long list as possible scenarios
Wayne: Yes good idea
Shawn: Anything else for Shadi to bring to WCAG-EM TF?
Split up into subgroups and worked on specific sections: