Michael Cooper, Ben Caldwell, Wendy Chisholm, Richard Ishida, Chris Ridpath, Lee Roberts
John Slatin
i18n currently only writing techniques, might get to guidelines later. i18n more interested in giving hints and tips, don't have the strong emp on testability (that wcag does). i18n tech dtd is an extension of the char mod dtd which is an extension of the xmlspec dtd. For example, add xml:lang, dir, translate flag, notes to translator, have img and image element. takes alt text out of attributes. in i18n word, might need to stick bidi markers and lang tags on alt text (and other translatable text), thus don't want them in attributes.
diffs from wcag techs dtd:
to do's:
architectural ideas:
we've thought about, but not determined, how to link between html and css.
although, would like to be able to generate a checklist that contains all info you need (e.g., html+css)
i18n interested in a document that brings together info from i18n and wai.
if you look for i18n pointers in html, there are pointers only for people developing a user agent, some only for content developers, others for both. need some filtering for audience. how to achieve? reduction (by putting everything in database and pulling out necessary pieces), but richard leaning towards aggregation - rather than include everything in the database, create overlays or templates. advantages: if you want to significantly reorder (easier to do ala template), additional info and repetition of info. Refer to the template that Richard posted to the wai-gl list.
action wendy try using richard's dtd with html techniques to play with see how it works, give feedback to richard.
agree want to submit extensions back to spec-prod since other people might want to use (particularly translatable text)
support for this proposal (to add it to requirements document)
action ben: create interactive mock-up
action michael: add ben's proposal to draft of techniques requirements.
refer to jason's definition of testability
we discussed "untestable" and compared it to art. "don't produce anything offensive" but everyone has different thresholds for "offensive." we'd like to keep in the untestable things since there is an art to accessibility. We agreed to include both testable and untestable items in techniques. (i.e., techniques for"additional items").
There was an issue raised last week with labeling a technique as "human testable" only because a machine doesn't exist today. the proposed solution is jason's defn of "non-probabilistic algo"
In response, we discussed human vs machine testing. alt-text was discussed as a concrete example. e.g., if we say that alt-text needs to be short, in english we can defin short as "less than 100 words." A tool could check that. However, 100 is arbitrary and it is up to the human to determine if the alt-text is appropriate. Thus, the tool can run heuristics and give an indication, but it is up to the human to decide.
Another piece of this discussion is that "short" might be defined as 100 words in english, but a different number in german. would we want that level of detail in the techniques?
summary: machine-testable: the machine can make the decision. human-testable: the human makes the decision (but might use the tool to run heuristics)
concrete example: test="alt-text is short" (english:short=100 words) machine can test if it is short but not if it is appropriate. the human decides if it is appropriate.
in techniques document, can we define "short" and "meaningful?"
there are things that are testable and those that we aren't sure about, need to add this concept to the requirements.
action michael: draft something describing how we're categorizing testable.
since title is "checklist and techniques" perhaps move common stuff up (e.g., audience).
action michael: take a stab at reorg document so that common stuff (e.g., audience) is more obviously applicable to both checklists and techniques
issue: multiple versions of output formats vs audiences.
action michael: draft something that will attempt to clarify different versions.
public draft by next week, but need approval by wcag wg and judy. proposed discussing at tomorrow's mtg.
by end of today, need revision based on today's call. then be base for discussion for tomorrow's mt.g
then hope to publish to TR next week.
then work on the schema
in the next couple calls, focus on schema.
month of february: working on techniques (core, html)
get enough work done so that by march have something for solid discussion
if have tools together, then during svg discussion (between dean, john, etc.) they could be editing directly into xml.
version control? who has edit access? sort out and discuss at 29 jan mtg.
support for this timeline.
next week: hopefully have approval to publish reqs to TR.
discuss schema next week.
perhaps some issues on requirements.
$Date: 2003/01/15 20:53:33 $ Wendy Chisholm