WAI Authoring Tool Guidelines Working Group
Chair: Jutta Treviranus, jutta.treviranus@utoronto.ca
Date: Wednesday 14 April 1999
Time: 3.30pm - 5pm Boston time (1930Z - 2100Z)
Phone number: MIT Bridge, +1 (617) 258 7910 - note different bridge
The latest working group draft is http://www.w3.org/WAI/AU/WAI-AUTOOLS-19990413.
From the previous meeting:
Priorities of checkpoints from 2.7.3 to end
Guideline 2.5 - Never remove accessible content
Raised by Lauren Wood: http://lists.w3.org/Archives/Public/w3c-wai-au/1999JanMar/0260
Do checkpoints in section 3.3 and 3.4 need to be implemented "natively", or can they simply be satisfied by providing an interface for assistive technologies?
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 Unresolved issues: Expecting the author to know HTML and know what can be removed - good thing is that gives human judgement, but requires knowledge. We had a proposal that nothing be stripped out, which removes the ability to take out things that we want taken out. We want to say don't remove stuff that we need, don't add junk, don't alter it in a way which affects accessibility. This comes from access structure which may be deprecated, but we want it until aa better thing comes along
GR It is both forward and backward looking
CMN: A couple of things we need: tools shouldn't remove what they don't understand -= a last resort, but should be in there.
BR It may be a lot od work to carry that if the user edits - may become infeasible
GR A tool wilkl have to check against a DTD - if it doesn't recognise the stuff, what does it do?
WL: That's fine if you are doing the authoring, but if the author doesn't know the DTD it won't work
BR: May work with tag-style, but not for PDF upgrades (for example). The problem is not always soluble. An analogy is reading file formats produced by future versions.
CMN: The W3C answer is probably to check namespaces and DTDs, but only works online
JR The problem isn't so bad if it is just elements and attributes. Maybe we should not worry about PDF - it is a non W3C spec.
WL PDF is on the web and pervasive
JT But may not have any accessibility stuff
CMN It certainly does
GR It should be in the techniques
BR So we restrict it to when importing content which follows a w3c spec...
JR "..don't drop unrecognised content"
JT Never remove unrecognised elements or attributes in a W3C specification. Without alerting the author?
JR Alerting the author is a User Interface issue
CMN Alerting the author has to happen, but the author may not be able to give any useful feedback.
JT For an under-the-hood tool it could be frightening to authors
JR Batching the alerting could improve it
JT Do we need to say "without alerting the author" in the checkpoint?
WL: The reason we want to do this is someone might put in marku[p that helps proomote acceessiblility
JT This tool may not recognise a given version, and we want to preserve any accesssible content there is
GR Is this the checkpoint that Daniel has used the example of tables for?
CMN Yes.
GR The crux is the process thing. We want to get across the user control, and the requirement not to remove things. Right now it is a negative checkpoint - maybe if we make it a positive checkpoint we will have an easier time
JR If the user doesn't know what is underneath it will be automatic or it won't happen. We tell the tools not to remove unrecognised markup unless the user says it is ok
WL What if you just have 2.5.1 and make the "known" updateable - make a way to update what is known.
CMN: I have half an idea that this is mostly here in 2.1 and 2.2. Propose we go back to read those sections and discuss it on the list.
BR Agree
JR Tools should be upgradeable to new DTDs
JT I think one of the reasons this seems so sparse is that we wanted to get at all the sins of conversion tools. There were a large list that we couldn't articulate - adding junk which is done by some authoring tools, altering the structure to mask what was good, interfering with authored stuff.
CMN I think some of the stuff has been done now. I think we should take this to the list.
Action CMN: Write a proposal to deal with 2.5
WL/JT: Please respond to suggestions on the list.
Action WL: Write a proposal to deal with 2.5
Action JR: Write a proposal to deal with 2.5
Refer to priority definitions.
Resolved
JT There was some feeling for a 2
JR THere are some important things for people to think about - maybe gives a casse for a p2
IJ What does emphasise mean - how can it be verified?
JR Mention it
GR My reading is that this is broadening the exmples
WL Chagne emphasise to discuss?
IJ In WCAG there was a decision not to emphasise the universal benefits
JR This is under selling
CMN I think this is a different case
Resolved: P3 - change word to discuss
IJ This is also in UAAG - do we need it here?
CMN Yes.
GR I think we should have it here.
*WL leaves
BR This is needed here regardless of UA
Resolved: P1
CMN At the moment we will only refer to W3C recommendation. I suggest we cross that if we come to it.
Resolved: P1
Resolved: P1
BR Issues with that as a checkpoint. Trying to think of what it would mean for a presentation package in drawing elements where there would not be an equivalent
CMN Waht kind of elements?
BR Eg a background image
JR Would be followoing WCAG guidelines about textual equivalents
JT If you are using a clip-art file it is covered by another guideline
BR If they are meaningful content...
JT If they are decorative there needs to be some identification
GR eg Horizontal rules
CMN You might have an image with a long description but no alt text.
GR If I drop in a black background I want to know that it is there
BR What if I put in a blue background
JT Then there needs to be, somewhere, text that says blue background. The author needs to have access to that information.
JR Doesn't need to be displayed
BR How does this differ from 3.4.1
GR If I get a dialogue box for colour choices I get a set of coloured boxes
JR I think it is covered in 3.4.1
JT Here we are talking about the display of the content rather than the interface elements. here we are talking about something which will be seen somehow in the markup. Eg I can't see the blue background or the pretty horizontal line - I need to have enough alternative content to know that it is there.
BR I'm thinking of presentation pages and not sure how to present an equivalent for all elements
CMN I think this and 3.4.1 belong in the same guideline
GR If we put media-dependent content in here? Covering embedded sounds, etc.
BR I don't think that does it?
JT is your difficulty in where do you get textual equivalents from?
BR Yes. How far do you go.
JT If it was done by another author then they should have given equivalents. If it is done by the current author, they can put an equivalent in.
CMN Where it comes from comes out of other parts of this document and from WCAG
JR If we have "a big bitmap" it is not conformant with WCAG
discussion of background image as an example
BR This sounds very burdensome for desktop apps.
JT The challenge here is different to WCAG. Here we are assuming that the author needs to know what the object is beyond its function.
BR I can understand the need for it, but it feels difficult to do.
CMN: Propose - P1, and write techniques
Action BR: Send some sample problems
Action CMN: Write techniques
Resolved: P1
GR Would push for a 1.
JT Would push for a 2
JR How do you do it otherwise?
CMN Slowly
JT Could be done by an add-on tool
GR This is a universal design feature. Goes to the idea that "structure has meaning"
BR Without this it is impossible?
GR Very difficult
CMN So we say P1 - to satisfy this allow element by element navigation, and ask for more for extra credit
BR Should we break it into two checkpoints? So we relax the meaning of the term structure in the techniques?
JT Do we have too many P1s? Does that water them down
GR We should leave it until we have assigned priorities
JR Also we ahve taken out a lot of P3s...
Resolved: P1. Techniques to explain that element by element navigation will (minimally) satisfy this checkpoint.
Resolved: P2
Resolved: P1
JR Technique under a new checkpoint, or expanded 3.3.1 which encompasses multiple documents
BR Could be a technique for multiple checkpoints
Resolved: Technique
JT One thing that seems to have dropped out is user interface elements that are not part of the content, but part of the user interface - this is where this came from
Action JT: Discuss this on list
deferred to list / next call
deferred to list / next call
deferred to list / next call
deferred to list / next call
deferred to list / next call
deferred to list / next call
Last Modified $Date: 2000/11/08 08:11:51 $ by Charles McCathieNevile