WAI Authoring Tool Guidelines Working Group
Chair: Jutta Treviranus, jutta.treviranus@utoronto.ca
Date: Tuesday 8 March 1999
Time: 3.30pm - 5pm Boston time (2030Z - 2200Z)
Phone number: Tobin Bridge, +1 (617) 252 7000
The latest working group draft is http://www.w3.org/WAI/AU/WD-WAI-AUTOOLS-19990304.
Navigation guidelines in section 3
Priorities for checkpoints
Judy Brewer
JT Prior discussion: It was determined that we would talk in the introduction about general issues, and discuss problems which are specific to authoring tools here.There is a summary of problems found by authors archived on the list. We discussed the guideline "ensure independence of style for authoring and publishing"
+BR, BK join
CO: Latest draft is 25 february
JT: No, newest draft is 4 March
+ KB, JB, IJ join
CO: I thought this group had decided not to address the issue of accessiblity of tools
WL: There are certain things which are not relevant to other tools and need to be here
CO Can I have an example?
WL Jutta was giving one when people stated joining
JT: 3.1 is to allow the author to control things like font size and colours, independently of how it is to be published
BR: Isn't that the same for a word-processing application? Why isn't it in the User Agent Guidelines
WL: Word processing is WYSIWYG - authoring may not be
JT It is a special situation in an authoring tool
IJ WYSiWYG isn't.
BR If I need large fonts I may not want them printed that way
DD What do you mean by document types?
BR Document editors. I may want to use large system fonts even though I may not wan tthem to print out using large system fonts
CO This seems totally redundadnt with existing guidelines on accessible design. It's not specific to a web-creation tool. I can magnify viewing and publish differently in many aplpications
JB What about provide a structured view?
CO How would it help
JB You are asking whether these things are covered in existing guidelines
CO I don't think structured view is for accessiblity
GR: I don't believe that navigation belongs solely in navigation. There needs to be navigation which allows editing at the same time. Somewhere you need a structure view to keep in mind how these things relate.
JT I think your point is well taken, partially because of the name of the guideline, which should be restricted to navigation. Can you comment on the question of the access advantage?
GR: If it isn't here it won't be done?
JT What are the access advantages of a structure view?
GR I am completely reliant on aural feedback. It is a 'der' recommendation, but I need that recommendation
CO You said well designed sites are done with structure. But I am looking at sites with no structure. Good document creation is important and should be hierarchical, but site creation does not need to be hierarchical. Also, why does providing a strcutred view inportve access?
CMN In regard to sites, we may not be talking about a hierarchy
JT I think we are talking about pages
GR I think we are talking about both
CO But how does it improve a website
GR It doesn't. It improves the tool. That's the problem we are talking about
BR I understand the problem, but why is it specific to Authoring tools
JT It is useful for others, but isn't covered there
BR Why isn't it in User Agent?
JT It is not necessartily relevant to browsing. It is to authoring. One of the problems is that the structure is usually conveyed visually
CO That's the default.
JB Chuck, please let people finish
JT The functions are not in User Agent Guidelines
BR The other documents cover these things though
JT Yes, but they are outside the control of the W3C and we cannot control their content. We can address them, but not use them as defined references
GR I feel that if they are not here, they won't be done
BR: How do they fit into the other guidelines
IJ This is a question of scope. We would like to have one mechanism for all assitive technologies, but the scope of the guidelines means we have to discuss it in particualr relation to the scope of theis group. We don't have a general docuemtn covering all tools
BR: There is no document covering general authoring tools
WL No. the Web consortium covers Web authoring tools
BR If there are documents which do cover our needs, why can't we refer to them?
JT Here we are trying to draw out the things that are not specifically addressed
(process yada yada)
CO 1Why is this so important that we have to do the work of other people? I thought this group was created for the creation of accessible sites. 1% create sites, 99% uses them. We should focus our efforts on teh creation of sites. The accessibiltiy of these tools is not that high a priority. 2. How would I implement this feature in excel
CMN: 1. the group must solve both problems. 2. The relationship between different sheets in Excel is probably already done - there is a simple relationship between simple sheets
CO: I object to spending a lot of time on this.
BR I think other guidelines cover this already
GR If they did, we wouldn't ahve the discussion
CO Oour products already do this. The theory that they are needed is wrong
GR SWitching to an HTML view to get structure is a non-sequitur. If these are available for one segment of the population they should be there for all
CO Who has access to this now?
GR You have just pointed out that Microsoft does that
CO Yeah, in word. But not in everything
JB That's the standard for guidelines development? That someone already has it?
CO My role in the group trying to find the basis for it, and how to implement it, and say the development cost is horrendous and do we really need it as a guideline
JT: It is in SGML tools, and allows quicker access to the structure which makes authoring for disabled people much more accessible
BR Can I take 3.1 - ensure independence. I know that is in the Microsoft Guidlines. That is an example of wehere i see this guideline overlapping
JT Once authoring tools are sufficiently mature that they reach the sophistication of word processors that problem will disappear. but at the moment the WYSIWYG approach is the norm
BR So are guidelines the appropriate way to bring out the needs, or are they best for techniques
CMN W3C guidelines cannot rely on unstable documents, so eg microsoft or sun guidelines can only be referred to in techniques. We can rely on W3C recommednations, which are dated and stable, so we can refer to them in checkpoints (and do in section 2)
CO It's not like we have the time to play around with this, but do we have time to rewrite other peple's work just because it doesn't have the w3c stamp
GR we are not rewriting, we are bringing attention to it at a top level
CO No disagreement there, but the guideline says 'do structured navigation'. You are saying Do this, and all tools will be measured against it
DD We are mixing two differnt things. The first question is about referrring to other guidelines - there are more generic guidelines which cover some issues - do we want to duplicate them to provide emphasis? This shouldn't be an issue - it is already in other guidelines and already has to be done. The other issue is whether we want to require a structure view. Maybe we want to restrict that to different documents. We have two different problems and we are talking about both of them at the same time
JT We have discussed the first problem extensively. The conclusion is that we do not want to replicate other guidelines - we want to give a summary of them. We want to draw out things which are unique to web authoring tools, or things which are not given sufficient emphasis for our needs in other guidelines. The intention is to talk about the things that are important to an accessible authoring tool - where we are authoring marked-up docuemtns. Thus far we have spent almost no time on it - that's why the section is in an relatively unprepared state. We want to talk about the wole idea of beign able to navigate or move around, making it easy for an author who cannot see the visual conventions to navigate for authoring. (not simply for viewing. That was the agenda item. I propose that we go ahead and follow through on the agenda item. If we come up with something that is sufficiently covered by other guidelines we can leave it out. Idon't think we will know unti lwe have gone through the process.
CO It makes sense to implement in certain types of applications. I would submit that it does not make sense in some types of products. Also, I have spent a lot of time on the issue. If need be we can take a look.
(process yada yada)
Should we continue loking at guidelines for section 3 - the first one is a guideline and checkpoints making it easier for users with disabilities to navigate the document
Yes: WL, JR, BR, JB, KB, GR, IJ (can we discuss what is an authoring tool)
No CO
We will continue on this discussion
DD I want to discuss but I really want to get to priority
IJ Chuck said that this made less sense for Excel than for a document tool like an HTML editor. Does save as make a tool an authoring tool
CO For a document an outline is important. For presentation tool, for example, it is not. A tool like Windows 2000 has the ability to publish to the web as an integral feature
CMN I would argue that it is important for almost any form of editor, although for some tools it is trivial to implement
WL So it should be in any kind of tool
JR When we say provide a structure view I think we are concentrating too closely on a preconcieved vied of what that is. The purpose is that people who cannot see visual representations of structure can get to that by non visual means, although it is written here in a bad way which is provoking problems.
CO We write checkpoints before we dfine the problems
JT No. The problem is that the tructure of the docu,ment is usually conveyed through visal conventions. This guidelines document is an example. As an author looking I can use the visual conventions to skip through to where I want to be. For someone using a sppech or braille system the structure is not avilable in the same way, and there is a greater need to e able to navigae through the document. We need a way for an author, as they are authoring a document, to traverse the document.
CO I agree. People who are visually oriented often use visual highlighting - that's why they are available. The information is available to accessibility aids. is this so important that it needs to be added into products where it would not normally exist. is the need outweighing the implementation cost?
JT I think you are arguing against yourself. In case of documents yes, but not in the case of data - web sites are not really documents most of the time
DD I am confused. What is a document and what is data
CO in w3.org is document, outside is data. How would it help me in Microsoft.com In the case of documents it makes sense, but in teh case of lightwieght pages it doesn't mean much if anything
DD If Excel publishes it will use HTML or some richer XML. There is a lot of structure in the table
CO You want this structure iavailable
DD Yes. Isn't it there?
CO Yes. We should be dealing with the question of how the markup should bve created, not how it is viewed.
JT The web content guidelines deal with what excel should be producing here we are talking bout the authorign tool
DD Yes, I think frontpage should support a structure view. If I open a document I want an outline. Isn't that normal?
CO People create HTML in Excel. GR Do you want this in Excel?
GR Yes. The point of the exercise is that there are unsdtructured sites, and we are trying to facilitate structured sites.
CO The issue is the accessibliity of the tool
JT Yes, that is the issue on the table at the moment. We have also spent quite a bit of time on creating correct markup - that is section 2.
DD They are closely related. Te other part of the guidelines says the Tool has to prduce structured content. here we want the structure available. We want Excel to produce a structured document. Here we want that structure available
CO So adding a structure to excel makes authoring easier
DD Yes. It is more important.
CO You know my objections, I don't think this is important, I don't see us changing what we do.
DD I was oje o the poeple who was not in favour of having this in the document. But if we are having them in we should do them right.
JT I don't think we have spent an hour on this, I think we have spent an hour arguing about whether we should be talking about this. Chuck you can see what happens and then decide if you do not think it is useful. What we want to get across here is to enhance the accessibility of authoring the document. We are not implying that this needs to result n content - it does not need to be published. It is a tool for the author which allows creation to be done more easily
IJ Take Excel. There may be many interpretations of 'structure view' If I have a spreadsheet containing 15 sheets, I imagine that there is a way to get at any sheets. That is a structured view of the spreadsheet. A structured view of the data - I can't think of more than the structure already
JR You might have several tables in the spreadsheet. You want to jump around between those in taht sheet.
JT I think that Charles has pointed out that this may be done already
CMN In a single sheet there may be blocks defined. Having access to those blocks is what we want within a single sheet.
JT: What we want: To allow the author to quickly traverse the structure of a document which they are editing. What are the subpoints
WL There are no subpoints - the wordsmith can express this.
DD The current giudeline text is fine - provide accessible navigation. We may want to have editing in teh title
JT THe other thigs we have alluded to are being able to move between the structure view and the full document view. Are they techniques?
JR Yes. If the structure is built in the normal editing view you don't need to be able to move back and forth
WL: 3.1 Don't exlusively WYSIWYG
JT Let's finish 3.2 first. We have provide accessible navigation. We only have the point about traversing the document for editing purposes
CO Keep it as it is, but put in the rationale, and put in the discussion, etc. Right now it doesn't have anything there.
(process yada yada)
DD Here we need to put the emphasis on editing. I would rather have it in the checkpoints to keep the emphasis on editing the tructure.
JT THat will be included in the woprdsmithing of the checkpoint/guideline
JT Do we review priorities or look at 3.1
WL Shouldn't have priorities - it is either in there or it isn't You could number them one to n, and cut off at a certain point.
JT There are things which it would be good to suggest but which are not necessary and tehre are other things which are specifically necessary
IJ The developers have asked for rating
CO I would like to refine that
IJ I believe you wanted a two-level system. That was based on the Windows logo for software design. They ahve scrapped recommended. That would be a mistake for us. I think a two level system is good
JB The two-level system had to do with phasing in, within microsoft
WL I'llchange my vote and vote with chuck
IJ RFC2119 defines MUST, SHould, MAY - that's the basis for the 3 level system. I agree that you should have a category of required and whether you have two or three after that doesn't matter?
JT how many people want 2 levels?
DD I want to suggest that section 2 and section 3 may have different priority schema. I would accept a simplified schema for section 2 with a 3 level schema for section 3, because section 2 is a level removed.
JT I would rather have a consistent mechanism throughout the document
DD There are 2 different kind of things here
CMN I think that the loss of P2 would be to the detriment of the document
CO The job I do for Microsoft is triagin of accessibility issues. Developers say 'give me a list and I will do the top 3 - rather than doing all the things that are required. You need to say 'these are the thigns you have to do or you screw your customers. Everything else is gravy. The other side is when we do bug triage we have P1, P2 and P3 bugs. P1 bugs are handled by the next milestone. P2 happen before shipping. P3 are wish list.
IJ If we provide 15 p1s and they are only going to do 2 it doesn't matter what they are going to do. Also, why W3C produces guidelines rather than referring to existing guidelines - one of the reasons we are doing this so that factors such as cost of development aren't the reasons why things are excluded from the requirements
CMN I think that our 3 level system and the microsoft 3 level system are very close, and are there for good reasons
How many people for 3 levels?
Yes: CMN JR BR JB GR provided discussion is explicitly stated IJ
2 levels: DD for section 2 only, WL KB CO (although I am not fussed about the non-requireds - I am not strongly objecting to 3)
IJ another argument for having 3 divides the checkpoints up further - you can conform to the spec by conforming to P! or P1+2. If there were ony 2 levels then there would be an increasein the number of P1 required
DD Depends whether 1and 2 become 1 or 2 and 3 become 2
WL So only P1 are going to get done by Microsoft
CO Yes, pretty much
IJ You don't think the working group is addressing the main issues. At UA meeting you said teh same thing, and were asked to submit a list of priority problems, and haven't yet. Plesae do so here.
CO I am trying to tell you in these converasations
IJ I would appreciate it as an archived document we can look at.
CO I would rather produce recommendations for product groups - they do them irrespective of the guidelines.
JB there is an invitation to forward comments
IJ This is something different to reacting to other people's proposals. Those that propose get stuff in.
CO That's my experience too.
Next Meetinng same time, same number, in two weeks
+ CO, IJ leave
JT Consensus seems to be stick with 3 levels. Take to list
Last Modified 6 March 1999 by Charles McCathieNevile