Jenae Andershonis, Chris Ridpath, Wendy Chisholm, Don Evans, Ben Caldwell, Tim Boland, Lisa Seeman, Charles McCathieNevile, Dave MacDonald
Michael Cooper, Tom Croucher
action: chris compare latest html techniques draft with older write-ups to make sure everything included.
Closed. Michael added the link and file to latest HTML techniques.
lisa wants input about the direction to head with this document before heading too far forward. currently, it's more like a brain dump. there are different sections: 1. explaining the benefits of RDF to accessibility (similar to css doc) 2. usage - how you work with existing ontology. how to choose an ontology, 3. media equivalents
(Once a draft is published), Lisa would like people to look at: 1. general structure of the document, 2. how much detail to include in the document (are we going to assume understand gateway techniques before read rdf techniques?) 3. writing clearly and providing clear test section shows potential of rdf. experimental .documenting existing techniques that work with existing engines, but don't know which one the user will use. would like a single way to clarify text so that renderers are conformant to that.
lisa would like to see a standard way to create an ontology to provide alternatives, simplifications, etc. how should we approach this?
wendy doesn't think we should attempt to standardize an ontology in a techniques document. this sounds more like a deliverable of a working group chartered specifically to create this standard.
charles feels that we can write a limited vocabulary to do limited tasks. that it is similar to saying, "here's some html code to do x" and that it is useful to look at this stuff similar to css techniques. you can write a technique that uses css to satisfy a guideline but don't write "here's how to write a document in css."
our audience is not as likely to be familiar with rdf as they are with html and css. what are we doing to give people introductory info about rdf? we agreed that it would be helpful to have a short introduction (in each techniques document) that outlines in a few bullet points the accessibility issues and benefits for each technology and then point to other references for people who want to learn more about a specific technology. CSS Techniques already lists author and user benfits - so something similar that would be followed by links to primers or tutorials for people who want to learn more.
example: coding earl by example
Wendy will publish the RDF Techniques draft (thanks to lisa and charles). People should review and be prepared to discuss next week.
what is the purpose of author benefits section? there are tutorials and answers in the css 2.1 spec. we should reference those. however, would like something specific to accessibility. this section needs some fact- and reality-checking.
action: tim proposal and research for issue 725
Two axes: grouping techniques and ordering the groups. Agreement on grouping by element or property. For HTML, CSS makes sense to order the groups in the same order as the specification. For RDF makes sense to order the groups by task or by wcag 2.0 guidelines.
We discussed 3 possibilities: 1. via wcag 2.0 guidelines 2. via specification 3. via how people are using/how people are learning (tutorial: easiest to more advanced)
action: tim propose reordering of css techs based on css spec.
many 3rd party sites have information, however the support information is about browsers and rarely has info about assistive technologies.
css wg has an implementation report template to gather support information related to their test suite. would like to see if they are willing to gather info about assistive technologies.
action: tim explore with css wg about features of template wrt assistive technologies
discussed how we can gather information from people who want to submit techniques. if someone wants to submit a technique, we have two options: 1. xml source files are available (to use as models to create more xml) 2. a form that will generate the xml (under development)
action: jenae and wendy think more about the user agent support sections - link to others? test own? work with other WGs?
allowable values and where they are specified is stated clearly in 2.1 spec (which properties can take which values). However, we are interested in listing which properties should use absolute values (margins, padding) versus relative (font-size) and if these lists can be exhaustive. Currently is open-ended and ambiguous, can we make it specific and exhaustive? For example, can use a combination of absolute and relative in order to create something that reflows well.
action: tim go through css spec and create exhaustive list of which properties can be used with absolute vs relative units.
Refers to section 4.4 "Scripting and style sheets" of css techniques
The editor's note asks about general css/scripting techniques that can be applied across svg, mathml, etc. However, it is rare to use css in svg animation (combo of smil and ecmascript is more common). smil layers are usually created with smil xml. can do as css, but not usually in practice. mathml - some scripting, for educational purposes.
resolution to move this issue to client-side scripting and that we first need to develop specific techniques before generalizing.
action: wendy take action to develop/find a technique for css, scripting, html
action: wendy udpate css xml for references
do css techniques apply to both wcag 1.0 and wcag 2.0? This is related to publishing revised wcag 1.0 - what should we do with the techniques documents for wcag 1.0 (published in 2000). if a techniques document only references wcag 1.0, more likely to publish as a working group note; too early to reference wcag 2.0 right now (and publish as working group note).
how important is publishing revised techniques versus publishing revised wcag 1.0? charles believes that revising techniques, even more important in some cases (providing more detail and clarifications) than publishing revised wcag 1.0.
do we publish two techniques documents or one? (one for 1.0 and one for 2.0)
if we publish one document, what about contradictory techniques between 1.0 and 2.0? e.g., in 1.0 "all tables must have summary" in 2.0 "only data tables may have summary, layout tables should have null summary"
we need to look at 1.0 techniques and determine if we steering people in diff direction from 2.0
action: dave look at 1.0 techs and 2.0 techs and where do they conflict?
Can we bring 1.0 techs closer to 2.0, w/out contradicting 1.0?
Could create a checkpoint reference document, that maps techniques to 1.0 and to 2.0. Michale, Ben, and Dave went through the HTML techniques and mapped to WCAG 2.0 success criteria. could create a second reference: perhaps not render, but field that allow to map a technique to 1.0, once have techniques fleshed out, have better idea of conflicts. w/in xml express if a technique applies to 1.0 or 2.0 or both
action: wendy check with michael about publishing mapping of success criteria to html techs
$Date: 2004/02/05 00:05:12 $ Wendy Chisholm