Toronto, 15 May 1999
Present:/* Presentation by Brian Kelly - slides at http://www.ukoln.ac.uk/web-focus/accessibility/metadata/www8/ */
PJ: Why would I use this?
AG: Brian wants to go to registry and be able to say "This is accessible, despite shortcomings of a particular browser or tools in combination."
JB: Preferences and prioritizing. Filtering doesn't mean exclusion.
CMN: Tell content providers that they will be shut out if they don't provide metadata and will have more users if they do.
BS: This is a choice, an extra tool.
JB: Clarification: develop this functionality so that from the user's perspective, filtering does not happen automatically. The search tool must be configurable and may be activated on demand (but not against user will).
DD: Metadata is neutral. It's how you use it. PICS was marketed poorly. Now there is not wide usage of a tool for filtering "harmful" content. Need to avoid this message for accessibility metadata.
KB: Need also to market the message to site designers that the number of hits to their site will go up.
MK: We also need a "WAI schema" for adding text equivalents.
PJ: How is all of this used as input to Bobby?
BK: Currently, applications have config files. If we can have input data schemas available at a URI, the config data can be reused.
IJ: Relationship to CC/PP?
BK: Yes, perhaps it can be reused.
CMN: For 10,000 search results, these preferences helpful.
JB (to BK): Caution about language used in presentation: avoid patronizing language. Clearly state that user preferences are key.
GR: I had the opposite reaction to Judy and Jaap. If I'm in a hurry, I would like ranking. My concern is that we're not providing mechanisms to make inaccessible content more accessible. Not sufficient to just go to accessible pages. Need to provide rich hooks to available tools, etc. Make it possible to a) find proxies b) allow email to Webmasters.
JL: You may not need metadata in this case, you can just ask the browser to take the action (e.g., through a plug-in).
GR: Need to keep looking backwards: people don't have plug-ins, cycles, or memory to do this. Metadata is key to this. You can do this through a search engine.
/* Lunch 12:30 */
/* Afternoon 1:15 */
/* EO Review continued */
/* A-prompt presentation by Chris Ridpath */
A-prompt does about 33 prompt/repair things.
KB: Does A-prompt take into account priorities and conformance levels?
CR: Right now, checks for everything. We can turn things on and off, but can't decide how to organize. One approach is by priority. Another is by subject.
JL: Can you set defaults? (e.g., your base language is English).
IJ: I think an "auto" mode without prompting would be useful as well. I don't want to be prompted always for English.
CMN: Template.
CMN: Linux version?
WC: I would like to select by guideline or checkpoint.
/* Discussion of building requirements into charters */
/* Discussion of automation of checkpoints of WCAG */
E.g., Checkpoint 1.1.
LK: There is bogus alt text (e.g., number of bytes, file name, blank alt text). We can check for this.
WC: But you can't check whether the alt text is "appropriate" (meaning of words).
EH: Is there conventional wisdom about null/blank alt text?
AG: I claim it's in the Techniques Document.
WC: This discussion should be in Techniques Document.
DD: I don't want to look at level of techniques (e.g., many techniques apply to checkpoint 1.1). Let's brainstorm now, take details to the list.
RN: My concern is that lay readers will not understand the concepts of the checklist. I'd like to see the checklist simplified.
PJ: Is "non-text element" defined in HTML 4.0?
WC: No, but it is defined in the glossary.
EH: One issue is dealing with long text equivalents. For some elements, there are two mechanisms (e.g., "alt"/"longdesc") but for some there are not. Any checking on text equivalents needs to look at both "initial" and "supplementary" locations. Ideally, in a long description, you link back to the source document's image, etc. Note also that the extended equivalent may be part of the document body.
EH: Also, for A-prompt, put clear links from A-prompt to the guidelines and using established vocabulary of the guidelines.
DD: The more I look at the checklist, the more I think we will have to depart from the organization as is. This, due to the level of detail required in looking at techniques.
Action Ian: Next update of Techniques document in HTML element appendix to include text/non-text flag.
2.1: Color without change in logical markup is suspicious. However content can compensate. Also, what about background colors that convey information.
RN: Do we need to ensure that a page is usable when printed? [This is a guidelines issue]
LK: This is important, but not necessarily for this group.
BS: Can we create tools that detect black text on black background. I think so.
KB: One possible technique for a tool would be to give an example of what the results will look like (e.g., for rendered colors, alt text, etc.) The user could "see" the results.
4.1: DD: Can you identify a change without knowing the language?
PJ: You can guess, but you can't be sure. E.g., using statistics, dictionaries, etc.
LK: If an error is spread throughout the page, the user should be prompted once only.
KB: Can't be sure.
WL: Ensure that it's user-configurable.
EH: Can you suppose that if someone uses "lang" they will use it consistently.
/* Topic change */
EH: If you use headings, you might look for consistency among use of heading text (e.g., they all start with a verb).
11.4:
KB: You can test for failure by looking at file change dates. But you may get false negatives (e.g., if file name is changed, but not content).
/* Next Steps */
Action DD: Get information from Bobby about their checking mechanisms.
Proposed: In email, indicate in subject checkpoint numbers to enable tracking.