WAI Authoring Tool Guidelines Working Group
Chair: Jutta treviranus, <jutta.treviranus@utoronto.ca>
Date: Wednesday 8 September 1999
Time: 3.30pm - 5:00pm Boston time (1930Z - 2100Z)
Phone number: Tobin Bridge, +1 (617) 252 7000
The Latest Draft is the last call draft, dated 3 Septmeber, available at http://www.w3.org/TR/1999/WAI-AUTOOLS-19990903.
Last Call review comments:
JT There were some editorial points in Edna French's thing
CMN There seems to be an issue that the techniques and guidelines documents look too similar. We should make them more distinct
WC Definitely
JT We are dealing with the substantive things, not the editorial
IJ I am also curious about the proposed text...
CMN Should we work more on identifying the issues and less on solving them, since we are only into the start
IJ Would like issues raised in nitro text to be addressed
1.1 change implement to carry out.
CMN sounds good
2.2 - editorial principle...
3.2 Examples should be moved
4 - intro note on validity should be in 2
The meat ones:
5.1 and 5.2 should not be P1
DB The feedback from developers is that they shouldn't be P2.
JT We discussed this. The rationale was what makes the author likely to create accessible content. If it isn't naturally integrated authors won't make accessible content
IJ I don't think aesthetically integrated is the same as easy to do. SO i think 5.2 is more important than 5.1, but I think they are both P2
JR I would agree with Ian.
GR I could live with 5.1 as a P2. I'd like to see 5.2 remain P1, but might entail rewording.
JA There is something that hinges on word 'among'?
IJ If the functioanlity doesn't exist that is a big barrier. If it exists and is mildly easy to find, is that a P1 thing? If it is easy to do but undocumented, what is that? In the end, unless it is really darn difficult it isn't P1
JT I think the conclusion was based on how important are these to ensuring that the average author will make acecssible content. We assumed an author qho may not know to try and dig
CMN I could live with 5.1 at P2, probably, but I think 5.1 should be P1
JA I would concur
IJ I don't have a problem with the wording. I would concur with doing it like that
DB I have a bit of a proble in making one option more accessible. It bumps into other ways of ordering
JT That is why we chose among? Are you fine with 5.1 to P2?
CMN can we just resolve that this is an issue?
IJ My sense is that naturally integrated is just aesthetics.
DB I think we are really saying "don't hide the features"
JR It is more than "don't hide it". Naturally integrate is making sure that it is there when the user needs it.
CMN Sounds right.
JT Are we working on issues as they come in, or are we holding off until end of last call.
IJ In WCAG we produced an intermediate draft, but didn't ask people to look at them
JT Will we update working drafts as we go?
WC We had an issues list that we kept updated. We didn't so much publish new drafts all the time.
IJ For all email on list, each thread ended with comment, to show that they had been addressed
JT For sanity, do we want to create a working draft?
GR I would find that useful
JR, DB, WL I agree
CMN I would be happy to do it as rough edits, which include pointers to comments, etc.
JT Right.
Resolved: There will be rough annotated drafts.
IJ It could be up to Charles' discretion - if something looks editorial we may not have to worry about noting it. The director looked at the table we produced and said "this is really good". We didn't go through every last editorial change. A change in priority is an issue, a change in wording usually sin't.
Resolved: change 5.1 to p2
7.3 - does this mean ensure that each element's properties are accessible?
JT For an author who requires an equivalent of graphics or whatever, they need acces to the propoerties. WYSIWYG tools need to have textual versions of icons, for example.
CMN I think the answer to the question is "yes"
JT The new statement could also mean that the property has to be accessible - content rather than the existence
GR In 9 July we split this from "display and edit each element and propoerty" because there was a confusion between editing them, and how it displays that a property exists.
JT An example: That something is a title may be simply rendered by a color.
IJ The way it was phrased assumed a lot of knowledge.
GR "Ensure that each element propoerty has an accessible equivalent."
IJ I don't know how the information is being presented in the first place
GR "Ensure that each element property is accessible in a media-independent manner
JT We are talking about accessible to the author
IJ A comment after the checkpoint would help, or a description of the scenario.
JT "Ensure that each elements properties are accessible to the author" (with explanatory note).
resolved: 7.3 to be "Ensure that each elements properties are accessible to the author" (with explanatory note).
/* William leaves
IJ Definition of transformation in glossary. I don't know why the term substitution is used, and why does the definition include equivalent?
CMN I don't suppose it needs to include equivalent.
IJ something something bijective something something.
IJ The bit about substituting text equivalents is in a definition. Is the topic covered?
JT Substitution occurs.
IJ You don't have to highlight converesion as transformations - it is in the definition. As a general principle, glossaries should be minimal.
CMN I agree with that.
GR I think that some of this is germane to your problem with 7.3
Resolved: glossaries should be minimal.
IJ drop last sentence from transformations definition.
Resolved: drop last sentence from transformations definition.
Action GR: Look at it in wording for 7.3
IJ I think that is all that is relevant in my proposal.
CMN Most are editorial. On the i18n question this document is written in US english.
CMN We do need to differentiate the techniques document from teh guidelines document a bot
WC One problem is that when you select a link in WCAG you go to a reference. I think it is good to get into the techniques stuff. But the front matter should be more different
IJ There are gobs of text, not broken by anything. A colour, border, anything would be helpful
JT Another point she made is the use of the word user for author
GR I like the way the techniques document is organised - I find it much easier than the User Agent, because ours is ordered by checkpoint. Maybe we should say "techniques for checkpoint X"
CMN I think we need to do something like that.
GR I would like to hear Wendy's issue about whether 2.3 is a P1.
WC reads from http://lists.w3.org/Archives/Public/w3c-wai-au/1999JulSep/0215.html. There are not many languages that are acessible. If the tool generates an equivalent version in an accessible then it should be
CMN The idea was that so long as the tool can generate an accessible language, it meets the checkpoint - it can use other languages as well
WC We should make it clerer in the techniques
IJ Can we use "markup language"
GR I like wording
IJ "Ensure that the tool produces content in at least one markup language that enables accessibility"
CMN Works for me
WC Yep. Some examples in the techniques document would be good.
CMN Lots of examples would be better
JT Judy had another suggestion.
resolved: 2.3 Ensure that the tool produces content in at least one markup language that enables accessibility
/* Kynn Joins
CMN Remember to register. Hotels fill early.
DB Will the meeting on Friday go until 5.30?
CMN I would think so
Last Modified $Date: 2000/11/08 08:11:51 $ by Charles McCathieNevile