W3C Web Accessibility Initiative

WAI Authoring Tool Guidelines Working Group

WAI AU Teleconference - 8 March 1999

Details

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


Agenda

Review of Latest Draft

The latest working group draft is http://www.w3.org/WAI/AU/WD-WAI-AUTOOLS-19990304.

Navigation guidelines in section 3

Priorities for checkpoints


Attendance


Action Items and Resolutions


Minutes

Section 3 - making the tool accessible

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

Priorites: Definition

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


Copyright  ©  1999 W3C (MIT, INRIA, Keio ), All Rights Reserved. W3C liability, trademark, document use and software licensing rules apply. Your interactions with this site are in accordance with our public and Member privacy statements.


Last Modified 6 March 1999 by Charles McCathieNevile