WAI Authoring Tool Guidelines Working Group
Chair: Jutta Treviranus, jutta.treviranus@utoronto.ca
Date: Wednesday 21 April 1999
Time: 3.30pm - 4.30pm Boston time (1930Z - 2030Z)
Phone number: Tobin Bridge, +1 (617) 252 7000
The latest working group draft is http://www.w3.org/WAI/AU/WAI-AUTOOLS-19990413.
From the previous meeting:
Raised by Lauren Wood: http://lists.w3.org/Archives/Public/w3c-wai-au/1999JanMar/0260
Raised by Bruce Roberts: http://lists.w3.org/Archives/Public/w3c-wai-au/1999AprJun/0023
Raised by Charles McCathieNevile: http://lists.w3.org/Archives/Public/w3c-wai-au/1999AprJun/0045
(Counter proposal by Jan Richards - http://lists.w3.org/Archives/Public/w3c-wai-au/1999AprJun/0049 - make it a technique for 3.1)
and in http://lists.w3.org/Archives/Public/w3c-wai-au/1999JanMar/0244
Raised by William Loughborough: http://lists.w3.org/Archives/Public/w3c-wai-au/1999AprJun/0008
JT start with people who have made proposals - CMN, JR, BR
BR My concerns (as sent to list today) are that it is difficult to maintain unrecognised markup when editing a document. I agree we should warn when unknown markup is found, but maybe not carrying it through the editing process
JT Other messages have tried to tackle whether unknown markup is to do with accessibility.
JR You don't know anything about unrecognised markup
BR How far can a tool be expected to go?
JR If it is going to drop unrecognised markup tell the user. It may not always be hard to carry along.
CMN You need to be able to keep or drop markup - the tool can drop it but must ask the author
JT If the author is asked every time it could be very cumbersome. Keeping all markup revents cleanup
JR If we look at it that way maybe we decide which is the greater evil - keeping everything or losing it
CMN It doesn't need to be decided hard and fast - it can be configured
GR I thought of 'when removing unrecognised markup, alert the author (according to a configurable schedule)'
BR That can be applied at input time, edit time, etc?
GR Yes.
WL My problem is 2.5.1
CMN I would drop it as it is covered by 2.2
BR Agree
JR Then the guideline wording is a problem
GR No, it's still OK
WL How does the tool know about it?
GR Constant update, which we need.
JR We will produce tools which are access-aware - the tools are expected to know how to do it
WL When new stuff comes up?
JR That's covered by 2.5.2
JT Needs to be said explicitly 'don't remove accessibility markup'
JR Guideline goes with 2.5.1
WL We need the author to take part in this
GR CMN Were you proposing 2.5 into 2.2?.
CMN To the extent that 2.5.1 is possible it is covered already. 2.5.2 belongs here is a guideline
JR The intro text is for 2.5.1 What happens if you import from a language you don't understand?
CMN You need to understand formats you deal with
JR 2.2 only deals with W3C specs
CMN I think we should broaden guideline 2.2 to cover all languages supported by the tool
JT There is a difference between having a method of authoring material and recognising features in input
GR 2.2 talks about stuff being produced, 2.5 talks about stuff being mported
JT If it is not clear to us, then it is not clear that it is covered in 2.2
WL I don't want to get rid of 2.5.1 but it is a problem
BR What if we use language from 2.2 in 2.5.1
Resolved: Adopt Gregory's wording for 2.5.2 - 'when removing unrecognised markup, alert the author (according to a configurable schedule)'
BR Can we Qualify 2.5.1 by saying 'never remove markup supported by the tool that is known to promote accessibility'
CMN The tool must recognise accessiblity markup for any language it claims to import
Resolved: Add both checkpoints in place of 2.5.1: never remove markup supported by the tool that is known to promote accessibility, and the tool must recognise accessiblity markup for any language it claims to import
WC Please define user-defined schedule in glossary
CMN Discussed under Prompts and alerts - we should make it clearer (and use the words)
Resolved: Define "user configurable schedule" explicitly
JT Do these need to be integrated natively, or can they be done by alowing a second tool to provide access?
WL Not doing it natively raises my hackles...
JR If you follow the OS principles you shouldn't have to write a screen magnifier, etc. You shouldn't be doing anything crazy anyway
CMN I think we need to be able to do all the things we ask natively
JT We are not asking for screen-reading functionality - we are only asking for it by hooks. There are things we are asking for which we want natively
WC Navigation needs to be native
WL You don't have to have Bobby or a browser in there
JT There are assistive systems which do the navigation by themselves
/* Kynn Bartlett joins */
JR The things we ask for are bare bones requirements that should be native.
CMN Are there things in here we think don't need to be done natively?
JT There are things which can be done with a module shipped with the tool...
GR Which is effectively native
JT Yeah. So long as the client gets a tool that does it all already it could be a bundle of pieces.
WC I don't think navigation is just an accessibility issue.
BR What does native mean? The installation has to put it on my drive? Can be easily installed? THere are degrees. Am I penalised for putting an upgrade onto the web?
CMN No, you are penalised until you comply - until the upgrade is there you don't comply
KB What if it is an optional upgrade?
CMN If you use a version which does not comply (eg you don't take the upgrade) then you are using a non-compliant tool.
JR Is this general, or specific to these checkpoints? Does a webmaster have to provide speech synthesis, or just make hooks available?
CMN We don't require speech synthesis
JT It is necessary to provide interfaces, but you don't have to provide them within the tool
JR There may be cases where we can say an interface is acceptable
JT We are not requiring a tool to do everything, we are just requiring them to provide interfaces
WL We are saying they can't rely on a screen reader providing navigation
BR We don't talk about this in the document
JT Should we put some clarificatoin in the intro to number 3?
CMN I think we should explain this in a conformance section when we have one
Resolved: Checkpoints in this document must be implemented 'natively' (as discussed here). This will be made clear in the conformance section of this document
JR Clarification: If you put out a module afterwards, are we talking only section 3 only?
CMN We're talking about the whole thing
JR So a tool comes out without understanding ALT. Then they make a module to do it.
CMN There are two versions - the upgraded one, which complies, and the original version, which does not comply
KB We have a technique saying do not hide accessibility in 2.4
JT Do we want to addsomething about native into section 3 intro?
WL Needs to be clear that if the tool depends on some particular thing then it can't qualify unless shipped with that extension
CMN I think for now we don't need it in section 3
postponed
BR 2.7.2 satisfies 2.7.1, which seems bad - make them more disjoint, or merge them
JT I think those are disjoint. The one is to have help text which talks about practices, the other is to integrate it
CMN I think them being seperate allows an easy out for developers who are slack
WC I think 2.7.2 is the P1
JA 2.7.1 could be a technique for 2.7.2
GR 2.7.1 says have help for authoring. 2.7.2 says if you are talking about something with an accessibility issue, address the accessibility issue. So I agree with WC
JA Isn't the place to explain it in help?
JT You can satisfy 2.7.1 by having a chapter on accessible authoring practices, which doesn't satisfy 2.7.2
GR 2.1 and 2.2 exist as guidelines says that 2.7.2 should be P1
CMN I think 2.7.2 is P2
WC If you want the best, then you do 2.7.2 Therefore it is P1
CMN I agree - based on definitions of priority I think these are already right
GR propose: 2.7.2 to be P1 I don't agree with the objection
BR, KB agree with CMN. Maybe there is a problem if we can't give our highest priority to sometyhing which is really important.
JT We do need to look again at priority definitions. Section 2 has different requirements and we may need to revisit priority definitions
Resolved: Revisit definitions of priority for section 2
WL Does anybody besides me use context-senstive help? Isn't it impossible not to use it?
CMN No, not impossible, just really painful
GR Unless we integrate accessible authoring practices we are not providing a blueprint for making acessible authoring practices.
WL Sepereation of content and format is important - we should look carefully at our use of the word
postponed
postponed
Last Modified $Date: 2000/11/08 08:11:51 $ by Charles McCathieNevile