WAI Authoring Tool Guidelines Working Group
Chair: Jutta Treviranus, jutta.treviranus@utoronto.ca
Date: Wednesday 24 March 1999
Time: 3.30pm - 5pm Boston time (2030Z - 2200Z)
Phone number: Tobin Bridge, +1 (617) 252 7000
Proposed by Charles Oppermann:
The group table section 3 - Accessibility of Tools until section 2 is completed.
The latest working group draft is http://www.w3.org/WAI/AU/WD-WAI-AUTOOLS-19990304.
Proposed by Charles McCathieNevile (pro forma):
That section 3 contain no guidelines or checkpoints, and simply refer to other documents.
Proposed by William Loughborough:
That a guideline or checkpoint be added to section 3 requiring mouse-free use of the tool to be possible.
Carried over from previous meeting:
Proposed by Charles McCathieNevile
Technique for 2.2
Proposed by Charles McCathieNevile
Conformance be adopted from Web Content Accessibility Guidelines
Resolved Not to adopt the proposal
Resolved Not adopted
WL: Should have no references outide w3c in guidelines
CMN: There are none in UA guidelines, only techniques
JR: I could live with that
JT: So where do we make references?
//Bruce Roberts joins
JT We are discussing software accessibility standards. All tools need to be considered, but do we need to include everything in here?
CMN We should include reference but not to specific docs outside w3c docs. We should include basic minimal requirements
BR I wasn't saying we should refer explicitly to desktop suite, just that we should keep them in mind when we are writing these things.
WL: For example your (BRs)discussion of text-only tags.
JT The current set came from problem statements generated by users - coming from the process suggested by Chuck Oppermann, but they are too specific. Example - I have been working with math groupswho are generating graphics for everything - they start ASCII and in conversion to HTML could add it to ALT. Is this covered?
BR Maybe in 3.3. Oh, maybe not.
WL Is text beter word than ASCII
JT ASCII doesn't have to be used - it is that it can be done accessibly. The range of tools is constantly growing
WL In math classes, the professor always said 'lambda'
JT It doesn't get addressed here
CMN It does in terms of output produced
JT Point is that there are a lot of content tools, and we need to ensure our statements are inclusive, or qualified
BR That's fine
JT: Getting back to what should be in section 3 - proposed not to refer to outside documents
CMN Tighten - we don't refer in GL/Checkpoints to documents other than w3c recommendations
Resolved
JT At the moment we refer to UA guidelines - we should still do that. What about software accessibility guidelines
CMN put them in techniques - make general reference in guidelines/checkpoints
JT What about direct accessibility (working out of the box) vs assistive technology
JT Current convention is that there are some basic features within tool. eg support for stylesheets allows magnification. But often you need additional technology -tool talks to it.
CMN Look at platform - for a graphic machine, implement directly what can be done on graphic machines, and implement APIs
WL Is this discussed in WAI?
CMN in UAAG - we are going about paralell to them
BR are there common ATs?
JT They are widely varied - and lots of resources are dedicated to keeping them up with software advances. One problem is that much software is not sufficiently communicative
WL: That's why we're here - eg hooks into windows were never provided publicly
JT That's why the standards are so important - need predictability
BR Which needs to be built into operating system
JT right
BR Does that cover this issue?
JT Largely
BR If we push it back onto applications it seems like a lot of unnecessary work
WL Shouldn't have been necessary
JT Requires a response by application developer - eg if I generate a cursor by some non-standard means it is inaccessible to ATs because they don't know where it is built
CMN In a system which doesn't provide accessibility APIs we need to specify the necessary basics
WL Can we say what they are
CMN In some cases we can
JT But there are all kinds of problems. eg Screen readers - some use MSAA, some use Java API - it becomes massive. There are some general principles - always ahve a keyboard equivalent.
JR That argues towards what we are doing
JT so is that what you are saying charles
CMN we should have some basic principles.
JT Should this be introduction or guidelines/checkpoints?
CMN not sure.
WL This needs to be in introduction. It may allow us to maintain that checkpoints are all specific to Authoring tools
JT there were some things we identified that were specific to authoring tools, but perhaps not to the expanded scope - we were looking then at HTML editors
WL eg the thing about teh text tags is HTML specific, but is about everything
CMN Bruce's point about HTML-specificness of HTML tags is well-taken. We should generalise the statement of need.
BR So we could say, "for all elements of a document, the properties need to be accessible - especially those which will be inherited in markup"
CMN I like the properties thing
WL It's covered in content production
JT It has a different function here.There are properties, and there are labels for the structure. eg I have bold underlined text, and can call it my style1, and can get it out of my outline view or index. I may keep its structural form but change style properties.
CMN We should define property to be structure and format information - if you can say it about the element it is a property
BR It is good not to make the distinction between style properties and naming properties. In an HTML editor it may include the tags.
JT As an author I want to know the structure information - I can do global changes based on a named structure, rather than on being bold.
BR There are aspects f styles, whether they are named groups or specific style
JT From a functional view they are seperate
CMN whether a property is applied directly or via classing, author needs to know
BR Yes, author needs to know what is in the document
JT We should do this as a checkpoint
CMN the one that does HTML tags
JT Yes. That guidline also covers graphic representations eg site maps. We need to talk about those. We shouldtake out the propeerties into a new guideline
CMN Propose checkpoint not be tied to a given guideline for the moment
WL Why is this specific to authoring tool
JT It is necessary for an author, whether or not it is available to anyone else
[discussion of scope - see section from charter]
Resolved Change tags checkpoint 3.3.1 to "for all elements of a document, the properties of that element must be accessible to the author"
JT Do we need to link to a definition of properties?
CMN We should expand existing definition
WL We should explain element def'n
BR, WL, JT give examples - spreadsheet cells, math formulae, words in documents,
Resolved Define property, expand def'n of element, and link def'n to HTML-specific use of terms.
WL The checkpoint requiring author-configurability takes care of how this works
CMN I think that this leads to Ian's suggestion of collapsing the two guideline suggestions which would enable some efficiencies
JT We aren't going to discuss that now
CMN agreed
JT What are we going to do about general software accessibility?
WL Goes in intro
JT We agree that this happens in intro
CMN For the moment
JT So we have guidelines/checkpoints essential for authoring tools and an introduction which talks about software accessibiltiy
CMN I think we should have a verifiable checkpoint about implementing accessibility conventions
JT So we add a checkpoint "follow accessibility principles" in a new GL 3.1
BR So we take this out of the introduction?
WL we say it in both
JT The overall guideline would be some statement about User Interface accessibility
WL The independence of mouse/monitor is not tool specific
CMN Nor is this checkpoint, but it is so crucial that it must be done
JR New guideline - follow accessibility principles, Checkpoints "work within operating environment", "follow User Agent Guidelines where you have User agent functionality.
Resolved
[timeline discussion]
JT Next telecon is scheduled for Easter Monday, a Candaian holiday. Proposed to move it to the wednesday - will be sent to the list to check for problems.
JT We don't have a wording - just a placeholder, but we have some strong
CMN "provide ability to navigate structure of the document"
BR You mean as appropriate for document type
CMN We could add some techniques
JT This is really important for authoring - it is important for reading but crucial for authoring
WL like reading through a straw.
JT What do we call the guideline?
CMN I thinkn we might leave it in provide accessible navigation with a note if necessary.
WL Gregory fears that this is reading only
CMN I agree. change to "navigate and edit"
WL The problem is people think that editing is only about changing words
JT The other necessity is to be able to traverse the structure then edit the text at that point. We should make that clear
CMN Should it be 2 checkpoints? navigate via the structure and edit the structure
JT It is important to be able to edit at the point you get to.
CMN It is also important to be able to edit the structure
Resolved 2 checkpoints - navigate and edit via the structure, and allow editing of structure, ie moving structured pieces.
JT We may neeed to talk about guideline name later, but that's OK.
Last Modified $Date: 2000/11/08 08:11:51 $ by Charles McCathieNevile