Chair: Len Kasday
Date: Tuesday 5 September 2000
Time: 2:30pm - 4:00pm Boston time (1830Z - 2000Z)
Phone number: Tobin Bridge, +1 (617) 252 7000
The Latest Draft is the Recommendation dated 3 February, available at http://www.w3.org/TR/2000/REC-ATAG10-20000203. The latest techniques draft is dated 4 May March, available at http://www.w3.org/WAI/AU/WD-ATAG10-TECHS-20000504. The latest draft of the Accessibiltiy Evaluation and Repair Techniques is dated 15 March at http://www.w3.org/WAI/ER/IG/ert-20000315
PJ: AERT techniques are specific and AERT document could use more general examples. E.g.. All tables that contain TH elements might be data tables. Should these heuristics be in AERT?
MC: Looking at adding heuristics like that for Bobby. But problem because if table has TD then must ask user if table requires TH.
PJ: I'm interested in techniques that are useful but not foolproof.
LK: Already have this sort of thing in AERT. E.g. tests for suspicious Alt text.
MC: Yes, we've discussed before if AERT should have techniques that are foolproof or not. To accommodate this Bobby has ability to turn on/off checks, A-Prompt as well.
PJ: What about turning on/off algorithm parts (user customization of algorithm)?
MC: Working towards that in Bobby.
PJ: Algorithms are necessary but not sufficient. Would like to have more.
LK: If faced with fixing large site and need overview then heuristics could be useful. Robots as well.
PJ: More like check one condition only. Does not meet whole WCAG just a piece.
MC: Thinking about this for future Bobby.
PJ: This would allow user to set some design policy. More automatic checking is easier. Fine tuning the program with these heuristics could be useful.
WC: This is like metadata for site. Useful for browser and checker.
MC: Like all tables with TH are data tables?
WC: Right. Metadata useful for tracking that sort of info. If stored correctly could be useful.
CR: Sure, AERT already has that sort of thing. Just let us know about heuristics and we'll add to AERT.
LK: Good idea to label as heuristics. Doc already has heuristics e.g. Suspicious Alt text.
WC: We don't have 'suggested language' section anymore. Your suggestion sounds very descriptive like user interface.
PJ: Not part of user interface. It's metadata - used to decide what tests to run.
LK: Also, allow people to label things in document. E.g. "class = layout". Checker tool would then be smarter.
PJ: I see need for more automatic checks.
LK: User customized heuristics?
PJ: Right.
LK: Don't need to worry about how to implement these heuristics. Just describe in AERT.
CR: Right. E.g. technique for "identify changes in language". E.g. Metadata for document could say "all tables in this doc are layout".
PJ: Example of another heuristic: If more than 300 words in cell then table is layout.
PJ: These things are "what is common safe assumption".
LK: in last ER call we discussed JavaScript. Could be harmless or when turned off page is dead. Heuristics to detect were discussed.
PJ: Need concrete guidelines for how to make JavaScript accessible. Need to be in WCAG. Right Wendy?
WC: Right. Working on it now. Not part of ER mandate.
PJ: When does ER get involved? After WCAG?
WC: Generally yes. Sometimes ER has found holes in WCAG when implementing techniques and goes back to WCAG.
PJ: Nothing formal?
WC: Nope. People on both groups handle this communication too. ER is now more tech orientated; WCAG group is more ideas now.
WL: Worried about HTML becoming like COBOL (ubiquitous but obsolete). Would like to focus on maintaining HTML as viable.
PJ: HTML poorly written still displays in browsers. DOM from bad HTML is poor but display is fine. Inaccessible DOM could cause problems.
LK: Tell browsers to indicate bad HTML?
PJ: How HTML rendered can't be spec'd out.
LK: CSS2 spec describes syntax. Perhaps XHTML has rules for bad HTML?
JR: AU group is working on conformance doc and don't have much to talk about with ER right now.
LK: Sounds like ER stuff.
JR: Our group has created doc that can be used to test conformance of authoring tool.
HB: Built in to authoring tool?
JR: No. Used by reviewer of authoring tool. E.g. Does tool allow user to enter Alt text for image? Our document is organized by functional areas. 50-100 questions per area.
JR: Results of questionnaire will be put into database. Users can query database. Like consumer report.
LK: Do all questions use yes/no answers?
JR: Trying to make it that way.
WC: What are the stickly parts?
JR: Relative guidelines. Step by step questions. Will make things consistent amongst authoring tools.
WC: What about conformance issues?
WL: E.g. Tool gets 500 questions right and only 1 wrong so fails.
JR: We use a different scoring method.
WC: Like site review of WAI guidelines. If document fails even one priority 2 checkpoint then gets only 'A' rating.
JR: Document has a great number of yes/no questions to try and get around this.
WC: Do you have to go through all questions?
JR: Don't have to do all. Questions ask about function of tool. E.g. Are you image editor or markup tool?
LK: What about "possible but hard to do" items?
JR: Questions have 2 parts: Can you do it? How easy is it to do? ('Easy' is qualified in our guideline.) Accessibility must be part of program's look and feel.
LK: Hard to quantify ease of use.
JR: To ER: Number of questions is large. How could we automate tests? E.g. Check menu structure for accessibility checker. Comments?
<discussion>
WC: ER tests. Would be most valuable for WCAG group. Where is doc?
JR: It's posted to AU mailing. Will talk to Charles about where it resides now.
LK: Interesting to see if ER can test authoring tools.
WL: ER doesn't. Contracted out to pros.
WC: Test pages fall somewhere between AU and ER.
HB: Browsers put in bad stuff when saving file. Save garbage with file.
WL: Browser is authoring tool?
HB: Like IE with file save (web page complete). Won't work under XMTHL 1.1. and Accesskey is removed from spec. Will send around pointer to list.
PJ: Can someone investigate?
MC: Accesskey is supported in IE5 but not well.
LK: Making style accessible was discussed in newsgroup.
CR: Are synchronized audio descriptions necessary for all videos?
WC: No, not all. Discussed at length with other group. Will send link to list.
LK: Classes accessible: People use classes with semantic meaning. Headings have boxes etc. Appearance has meaning. Style is decorative. Must be made accessible. E.g. images of text require Alt text. Comments?
PJ: Role of user agents? If style has semantic then standardize with user agents.
LK: If class is semantic then text string must be associated with class.
PJ: All attributes must be available to user. Not up to user agent.
WL: Urge authors to use meaningful names for class.
PJ: Could be a P3.
LK: Lots of classes described.
PJ: Up to user and user agent.
LK: If class uses style then is it a significant class?
PJ: This is like "don't use color alone"; "don't use style alone". Needs to be looked at. Send to GL?
WC: Len has already send something like this to GL. Could also be covered by new guideline. Something like "don't add semantic content alone". Clarification could be added to WCAG errata.
PJ: We need certain styles recognized as semantic.
Next meeting: ER on Monday September 11. Joint meeting on October 3.
Last Modified $Date: 2000/11/08 08:17:26 $