WAI Authoring Tool Guidelines Working Group
Chair: Jutta Treviranus
Scribe: Charles McCathieNevile
Scribe's note: I thought I recalled an action item being assigned to Wendy Chisholm and I to look through TRACE guidelines as well, but find noi record.
JT This is a charged issue in the group. We would like to go around the table and get a brief position statement from each person. The issue is that there are 2 esctions of guidelines. The goal of one section is to ensure the authoring tool is accessible to all authors, and the goal of the other is to ensure that the tool produces accessible content (which can be split further into helping/persuading the author and the 'under the hood' code generation. The existing arguments for merger are:
against:
JA Didn't it start together then go apart?
JT It was in three sections, and came back to two
PJ At one point it was not there at all - two separate documents.
Question: Should the guidelines be all together, or in two sections?
DD: Happy with two sections - accessible content then accessible tool - don't want them mixed together. I can claim I do accessible content but not have an accessible tool. To me the second set are higly dependent on other guidelines.
GR: I can understand both sides. I am undecided.
JR: I am in favour of two sections. I think there is an important conceptual difference. I am in favour of flattening structure, but should be a seperator between accessiblity of output and interface.
JA: Agree with JR. Don't want to see two sets of conformance from one document.
WL: There's 10 guidelines. Content output is dependent on external documents too. The concern I have is that if we don't militantly address that we are not doing our job. It denigrates the User Interface section to put it into a position where developers make a tool that does accessible content but is inaccessible. Danger of that became clear when somebody said "we have to concentrate on the 90% helped by accessible content rather than the 10% who are helped by making the tool accessible". Definitely want a single set of guidelines.
BR: Would like to see them distinguished, not necessarily in seperate sections. From a developer it will be more convenient to have them laid out. I have a fear that if they see UI accessibility mixed with content accessibility they may throw out baby with bathwater, since they already have IBM guidelines...
SL: So long as people can create content I don't mind.
EH: I'd like to see two separate sections as they are distinct enterprises. Should be made clear that conformance requires both sections.
RN: I see an argument for both ways. I would like to see a unified message. I don't know how to structure best for that.
MRK: There has been a lot of discussion in User Agent group about features we want in mainstream browsers and what we want in assistive technologies. I would like to see two separate sections, then maybe a document that hs everything that is needed for the editor.
PJ I agree we should address both issues. I think they should be two separate documents. I feel User Interface is redundant with other guidelines. The priority should be content that is produced - we should get that out first.
AG: If I had a proposal it would be to throw the guidelines in a heap. As I read the doc I felt the guidelines aren't well categorised in their writing - the ones about generate content overlap with Web Content Accessiblity Guidelines, and it is unclear where overlap with User Agent Guidelines is.
LH Support Jan's model. Addresses both sides of issue
JB I think User Intterface should be in same document, same conformance, as long as there is not a difference in priority. Marketing reason is when accessible content only is done and not much support is forthcoming. Implementation reason - I can't use Amaya, our own editor. Team said "tell us exactly what to do". The assumption that we do not need to talk about accessibility of tools is amazing - if you look back at TBL's vision it was about intercreativity. It is critical to have user interface in the same document. There have not been a lot of browser-editors. On a practical level we have to address the concerns of developers. If we are addressing all tools, there is an overlap. I don't want to lose the goal of looking at browsing and editing as an interactive process that disabled people have a right to be involved in.
LK: I agree that browsing and editing is all the same. There should be one document. People need to understand the guidelines - I think developers conceptualise in terms of functionality modules. Separate sections, but equal priorities. There is a guideline which doesn't fall into the "all the UI belongs in UA guidelines" model - separation of presentation and publishing rendering.
CR: The goal is the same, the issues are different. I think they are separate. Probably separate documents.
WC: Hmmm. I find it hard to separate the User Interface from the functionality - as you think about creating one you should be thinking zbout the other. I can understand that there is a crossover that I hadn't recognised before. If there were some piece that UA and AU could point to perhaps. I'm glad we get to think about it overnight.
JVL: Are you writing for one group, or two groups? That should give you an idea about whether it should be one or two sections. If writing in HTML is different from writing in word, then you should refer to other guidelines where possible.
MN: I'm inclined to agree with PJ. If we do two separate documents they should come out together. So it is probably OK in the current style. Don't make it confusing. Otherwise it doesn't matter what we have.
HB: I think we should have two sections, use what we have learned about XML in separating the structure and content from the document presentation. Should be separate.
KB: Concerned about compartmentalisation makes it easier for someone to do some and not the other. There is the risk that somebody will say "do the easy sections". Some of the guidelines don't fit squarely in either box - there are some in current content section which relate to user interface. The goal is to give guidelines for creating software that can be used by anyone to create pages for anyone. It has to go both ways for people to participate in the web. Merge sections.
CMN Merge. Separation is arbitrary. There are some clear separations, and some clear blurrings. For example, the first guideline in each section is to refer to whatever standard documents are out there. I want to mix the guidelines as much as possible so conformance can't be claimed for one part.
JT Feel very strongly they are important. Both need the same emphasis, compliance. Concern is that putting them in a heap there is confusion about whether a given checkpoint is about UI or content. We need to help the author make a shift from one part of the task to the other. Want to provide as many signposts as possible.
Adjourn. Meet again where we were yesterday, 8.30 am.
GR: Vote on this and go on
JT: we should go through the proposals from yesterdays discussion
DD: The accessibility of the tool belongs under User Agent
JB: Yes, but developers are either doing authoring or browsing, not the two in one. So we should have the necessary references for authoring tool developers
JT: Proposals:
PJ Some of section 3 isn't about tool, it is about content. e.g. 3.2.3
JT This is for authoring
AG It is universal - applies to tool and to content
JT This is an overlap with browser - they need to have all the information about a document they are editing
AG It is a requirement also for generating accessible documents too.
CMN This is one of many checkpoints that belong in both
DD How does this relate to tool
PJ If the tool is written in Java an object can be represented accessibly
WL We can have all together
KB This guideline could be in section 2 without any change. Either we rewrite this one to exclude section 2 functionality. It is stating something useful in terms of section 2. There is a lot of confusion here - the goal is to have a tool that can be used by everyone to make content which can be used by everyone
JR It doesn't say you can't use graphics. It requires that there is the necessary information available to the author.
PJ I want the accessibility of the tool out of here.
JR I don't see section 3 takes away from other systems - it says accessibility of the tool is important, but platform-specific guidelines are there, and there are some things you should take special note of as an editing tool
JVL We shouldn't spend too much time on what tools can do - if you need to do something you should simply choose what works. We should say whatthe difference is between an authoring tool and a general application. Maybe we can forward the question to people who are aware of GUI
AG Drawing: triangle, apex at top. User is on upper left, author on upper right. AU guidelines deal with someone who has ability to inspect and change the content. Platform is Web Content - WCAG are bottom face of triangle. We've been trying to wrestle with business of generating an accessible record through WCAG versus User Interface. We can see the differences, but I don't thinkk the answers are found at one point - they are how we connect the two interfaces. The Guidelines document is a forest - checkpoints applying to single guidelines
LK I think it's true you can just say "here's information for the author" and in a separate set say "this has to be done for a user with a disability". I think there is at least in techniques some special things for this situation which are not captured by the division. e.g. a blind author needs to know what a web page looks like if sighted people are going to see it. That isn't captured by splitting content from tool accessibility. e.g. 3.2.1 starts to address that. As long as these things are not separated it will not be addressed.
JB Disagree with Jaap I think. In some offices you don't have a choice what tool you use. There isn't necessarily a comparable tool when you can't use a particular tool. That is a reason why we need to consider user interface even if it is just pointers. These guidelines are not mandatory for every authoring tool. They're the best guidance the group can give to a developer who wants to make their tool accessible. This is not just blind people. The things that need to be done should be a check-off which we give to developers as a reference. We are not dealing with the real issues - some authoring tool developers do not want to have the UI issues in here because they are afraid they will be thrown out. We should not lie about what we need, but we need to state the requirements and deal with the acceptance issues in companies. If the document is not accepted, or it does not include everything we need to have, then it fails.
GR It's not just the blind. From a developer point of view, how can you justify this? Situational disability is a market. It is about functionality.
JVL I want to clarify that you select your access tool, not working tools.
GR I worked in an environment where you could use your own access tool, but got no support.
EH Seemed there are two issues. Availability of the properties - any property available must be accessible to all users. There need to be adjjustments to the wording - was the motivation to ensure that every authoring tool exposes every property of everything it looks at?
JT The guidelines for output do not cover what is needed for an author to be able to do everything
EH We have lots of checkpoints about making things accessible - why not say make all the properties available
DD I am still not convinced. We are facing a subjective decision. Do we think that making the guidelines as close as possible it is going to help? I don't know. Have we checked that all these guidelines are not already covering the things we say. We moght look ridiculous if we have too much redundancy
KB Is this guideline saying those propoerties only have to be available to people who can't get into them via a visual interface? If this is a general guidelines that they should be accessible to everyone then they fall under general guidelines
JT That has been echoed by a number of people - we should revisit what is in other guidelines and in this.
KB We say we are doing the thigs which are specific to this application. Some of the guidelines do not fall under this.
PJ Pretend for a moment I agree that we should cover the accessibility of theauthoring tool: The current document leaves out many important software accessibility guidelines, even though it points to "platform guidelines" and "User Agent guidelines". The important guidelines that it leaves out are applicable to creating/editing content that is accessible per the WCAG. Five examples:
So why do we have some of the software guidelines in here and not others. If some of these are repeated, we might as well repeat all of them. I would prefer to not repeat any of them and *not* cover the software accessibility of the tool in these authoring tool guidelines.
JT Do we all agree that we should take out the term disability - we are talking about all authors.
KB I disagree. It blurs the lines even more to do that. If we are going to have two sections (which I disagree with) it will make it even harder to work out what is where without using the word to clarify it.
JT Clarify. Just to restate that section 2 is not only for disabled people
EH The charter of this group deals with disability access, priorities are based on impact on disabled people. Departing from that goes beyond the charter.
JB I was interested in what Phill was saying. I was thinking that with WCAG we ran into a problem at the end of the process - bringing a document to advisory committee means the document needs to stand alone. Potentially the way to do this and capture our requirements is to have general principles that are here and have pointers in techniques. I don't care what words are there as long as the issues are being addressed.
GR Judy expressed most of the point. We're not saying we invented these guidelines, just that these are the crucial points for an authring tool. Phill had said it is an all or nothing proposition. Does any product IBM sells has everything.
PJ We have software that fulfils all the guidelines we have. The product prvides its half of the bargain.
GR You said you want everything in there
PJ Yes, there are things that are not covered in here
GR A lot of these things were covered, and should be addressed in techniques document.
WC Couple points. If we find ties to other groups we should make them - those things gave WCAG support. We should be looking at what we can throw into a techniques document.
JT This does have to refer to other documents.
JB It can point to other w3c recommendations, but pointing to external non-stable documents is a problem.
CMN Clarification of document structure
The guidelines and checkpoints are normative, the techniques will not be part of the normative document. There will be two versions: guidelines and checkpoints with techniques inline and the normative document.
Need to make general statements of what is required. Keep them general. Cannot refer to arbitrary document.
LK If I were to just take guidelines for any author, and general software guidelines, they may not cover all the specific requirements here. Where things can be factored out it is good, but where do we point?
PJ I agree, we should add "checking the rendering"
AG Charles said we need a stable reference. If as a group we tell vendors to track current guidance we can do that. If we discover the best thing we can contribute is an application profile, explain examples and cases, we can publish a note. We're charged with determining what are the best things to tell people. A W3C Recommmendation must be innovative and free-standing, a Note doesn't have to be.
EH I think we can make corrections, but I wonder if we can go on to something else.
JT I think the issue is that we haven't used the filter we said we were. If we change the filter there are other things we need. And do we merge the guidelines.
WC by 96 there were 40 sets of guidelines, and 5 sets of software guidelines. Now we have boiled down to 14 guidelines and 60-odd checkpoints. It is our interpretation of what is out there, directed to a particular audience. I propose that UA and AU need to look at software guidelines and what is common to them. Based on experience with WCAG I think this discussion is important. There are 3 documents that could develop. One which covers user agents and authoring tools, and one which covers each of those. If there is redundancy that would be OK.
JB I think WC makes an interesting point - it is easier to do this when we realise this is part of a larger question that is not completely settled yet. There are problems with unchartered groups. In regard to AG about Note, there is a problem that a Note has no weight - whatever is there falls out of recommendation status. Re mobile access etc my feeling is that group can point to crossover benefits, but is chartered for disability access and should not be claiming to be working in those areas.
/* adjourn */
JB We were trying to get requirements for a proposal. To the extent that software accessibility guidelines are in there it should be clear how they got into our document and how they relate to existing documents. We (PJ, JB, BR) think User Interface should be there, in guidelines or checkpoints, with copious techniques to help developers. We should point out that other platform-specific guidelines might supersede these, but at least have stuff there for when it isn't in available for current platforms. Then do 2 things: revisit section 3 and make sure nothing is there that belongs in section 2. Then look for things that are not in software accessibility guidelines and cover them in these guidelines, at checkpoints/techniques level (to be decided later).
JT Are you suggesting one guideline "make the user interface accessible" and filter out things which are in software guidelines or User Agent guidelines?
PJ No. We need to create copious set of techniques which cover things that are elsewhere. If there is anything there not covered otherwise it should be a checkpoint.
DD What is the criteria for selection - not in any or not in all of the other guidelines?
PJ We need to decide the criteria after generating the list.
WC It is a generalised, comprehensive set.
JB e.g. keyboard access, etc so if Linux guidelines appear and don't say keyboard access it will still be named.
WC I thought this was going to hold up the document, but if they are techniques things it won't stop development of the guidelines.
JB Might slow document some - techniques document should be more stable than WCAG techniques were.
GR I think we need to set a timeline. The current proposal seems to be 'a section of the document derives from this action'. We need to set some action items and do it.
WC We (TRACE) are working on collecting guidelines and principles. We do not have to recreate all that work - we should take these boiled-down lists and paste them in there and then elaborate a bit.
Proposal: have one guideline which says make the tool accessible. Checkpoints are only the things that apply to the authoring tool which are not covered in any existing guidelines. Techniques describe in greater detail what needs to be done.
JB Perhaps authoring tool requirements should be in techniques.
AG I understood proposal was to collect techniques and analyse them, then decide what makes a checkpoint
DD This guideline would be in the same section as the content guidelines. So we are talking about one section only.
JB It would be one of the guidelines in the whole document.
JR I would agree with that, as long as it is just one guideline.
CMN So the proposal is to merge all of section 3 into a single guideline?
PJ After shifting relevant bits to section 2
JB First step would be to look at stuff in section 3 and see if it doesn't belong in section 2. Then merge the rest into a single guideline, and merge that into section 2.
GR So we should set a timeline, set action items, and do it. So I want to ensure it is part of the proposal that there are no section distinctions
DD I want to see this guideline at one end of the document, not in the middle.
BR Re moving stuff, Phill had a good point about rephrasing stuff.
Proposal: Section 3 becomes guideline 2.x - "make the User Interface accessible", after checking whether there are things there that belong elsewhere in section 2
So Resolved
Resolved: The guideline may be moved to beginning, but will not be in the middle of the guidelines
JB We should check what kinds of things are already covered in other accessibility guidelines and whether there are gaps in those for requirements of authoring tools.
Proposed by JB
WC I suggest starting with TRACE tool which has tried to boil this down.
AG We should identify all the things that the author needs. WC proposed we start from the TRACE tool.
JT That is Judy's proposal
AG The bottom-up nature of this is important - if we find something new it gets promoted...
Proposal: Begin with TRACE tool, search for things in other guidelines, and work out what is not there which authoring tools need to create comprehensive list of requirements for an accessible Authoring Tool (user interface)
WL: Timeline?
CMN Two weeks?
GR Housekeeping. We have recently done a lot in little time - can we expand teleconferences to 90 minutes?
JB Can we postpone that to the end of the day
Action PJ, BR: Suggest checkpoints in current section 3 which belong in content production
Action PJ, BR: Look through IBM guidelines, compare with updated TRACE guidelines, note differences to group
Action WC: Review TRACE guidelines, send latest to PJ and BR
WL Section 3 does what we are now proposing. (but not well)
CMN We are creating a comprehensive list of requirements. Previously we were not including things which were in other documents.
JB Clarification - the comprehensive list will be in techniques document.
CMN Sure.
JT Agenda:
Topic: Definition of content, structure, presentation
JT We have used the term content sometimes for the information, sometimes for information and markup and presentation, etc. We need good terms for each of these. Proposed to use document, or page, or output, to mean the marked-up presentation and information which is marked up.
WL We should clarify content to only mean the information
AG There will be two uses of the term, because it is used liberally.
PJ Source could include everything.
GR the content of a title is a container and what is in it. We could use contents to mean what is in the container, but that is a bad distinghuishing feature.
DD How about we call it textual content.
JT That assume we are talking at a technical level. Sometimes we are talking in broader functional terms
KB Guideline 2 says ensure content is accessible. That is the output, including markup
DD That is content because we use that in the name Web Content to include everything.
PJ It is inferred as all from the title, but in the definitions it is specified.
JT It isn't a problem because it is defined so
KB Output is a useful term because we are talking about the output of a tool.
CMN Is this such a big problem?
JR I kind of agree. There is a problem with the word output, because there is also screen output, printed output
KB The tool produces something. We could call it a product, but that is a problem word too.
LK Output isn't necessarily a file - it could be a PERL script
WL which is still just a file
GR We had this at great length in Boston and we decided to use content and not output.
AG We have a couple of different senses of the word, and sometimes people are tripping. One approach might be to find the problem points and work it out from those
WL I agree. withdraw my suggestion
JA Talking about alternative content for multimedia, you really mean alternative media. We should work it out case by case
AG We need a definition of each meaning. If there isn't a word that has the meaning required you use a paragraph.
GR The danger is to have definitions that seem to contradict each other
DD Example: definition of content in WCAG
CMN That example seems fine to me. I don't think we will agree to every fragment of meaning. I think if we are going to discuss this we should do it at the end of the process, not now.
AG One way we use content is "what is understood by the end user". Another is in the sense of containers and their contents. A process we could use is to go throuh the document and look for points where confusion is caused.
GR I propose that we put a placeholder where we use the word.
Proposal: Not define alternative words - flag it as specific or broad sense, and at the end of the process review.
So Resolved.
/* LUNCH
/* Jaap left during lunch
JT Agenda remaining
Topic: Conformance statement
DD Definition of priority is complex but I guess we need that. I don't understand 1.3 - how do the guidelines require conformance to other guidelines?
CMN 2.2.1
JT Where we need to conform to (eg WCAG) it would be a P1 to conform to WCAG A-level (P1), it is a P3 to conform to triple-A level.
DD I understand the relative bit, but why do I have to conform to Web Content for an authoring tool?
PJ An authoring tool could be level-A compliant to this by prompting for information that is P1 in WCAG, for example.
WC There are two claims to be made. That the tool conforms to authoring tool priorities. But there is also the author's choice about what level to conform to in WCAG.
JT If you want a double-A you have to prompt for WCAG double-A (have templates which are double-A)
KB I remember the graded priority was in guideline section and not in checkpoint priority section. I think it belongs in the relevant checkpoints.
DD So we need a priority X for reference to other documents.
KB Don't like X because we used it for question mark before.
PJ We should detail it in each guideline
DD No, because it will be repeated too often.
WC it sounds like P1 to produce level-A content. The point is to produce content that can comply with any level. So everything in WCAG can be done, is a P1, and the author can choose what level they want.
AG That is P3.
KB It is P3 to have abbreviation. You can produce a level-A conformant tool which will not put in abbreviations automatically.
PJ 2.2.3 I have a template. We could have templates which are level-A, double-A or triple-A
JT Example is 2.6.1 - check for accessibility problems. If you are checking for WCAG P1 requirements you are level-A. To be double-A conformant you must check WCAG P2 as well
JB I am not sure that the section makes sense to me. What is the goal of the priority and conformance section with regard to developers as an audience. To deal with priority levels and relative priority levels we may need a brutal level of complexity. Maybe we should have a two-level priority definition. To me this sounds like a mess. When I look at priority statements they don't work nice and clean - these are referenced through another document. You don't have to use the same scheme.
LK Let's say there is a WCAG P2 checkpoint. You were saying the ability to do that at all is only P2, or the requirement to prompt for that is P2.
JT To get double-A you have to check, prompt, etc for WCAG-P2 and P1.
LK I would like to see that even if you don't require alerting and helping, it is P1 to allow them to do it at all.
KB Looking at 2.6.1 Relative priorities won't work. I want an on or off in a checkpoint. That would expand to three checkpoints - one for P1, one for P2, one for P3. Don't have them relative, spell them out explicitly.
DD I disagree. I think we should find a way to factorise this generic statement. When we discuss promoting, supporting, etc the priority depends on relative reference. You have priority R, and a pointer to what that means
KB That would still require 3 checkboxes
DD That's a checklist issue.
CMN I agree with Daniel
PJ 2.6.1. Kynn, you said 'check for, and alert for, P1 items. JB has suggested that we don't have to map to their checklist. We could say that it is P1 to conform to WCAG double-A. I don't think there are enough checkpoints that have to be split up, so we could do that reasonably.
JB Priority of these guidelines should map to context of these guidelines. To me there are some differences between allowing everything, which is a bottom line requirement. That's not a definition of priority. Would it be possible to have P1 'allow everything to happen and not produce bad markup', P2 promote and explain everything.
WC I think that's an interesting way to look at it. If we look at current priority distribution we have 21 P1, 6 P2, 4 P3. We are very heavily P1 - maybe that supports having two levels of priority. We do need to revisit priority
JR I don't think allow, promote explain maps very well. We talked about going from 3 to 2 priority levels and decided on 3 because it was pretty standard across groups. I agree with Kynn's idea, because you can be clear what priorities in the other document are being referred to.
JB The fact that they don't map is the point. That would be how to use priorities as a sort feature. Also, yes there have been requests to keep the guidelines standardised, but I don't think the working group should take on a schema if it doesn't work.
CMN These guidelines require understanding of accessibility markup as P1 - 2.5.1, and valid documents, inherited from WCAG. I think the current mapping we have makes sense. I like Daniel's suggestion for Priority R, which I think is a more efficient but effectively trhe same proposal as KB and PJ proposal to split those checkpoints
KB If we had a Priority R, 2.2.1 would remain a P1, and 2.2.2 would be Priority R or split checkpoints. I like the ability to map different priorities here - trying to map directly we have less flexibility. There are cases where it should be P1 for the authoring tool to do things at WCAG P1 and P2.
AG I think the allow/promote/explain triage is a good theme but not a rigid rule. We should use it as a guide in reviewing checkpoints. The relative priorities is a default, and we have to justify changes from the default.
WL One things that may be troublesome is that the priorities of WCAG checkpoints have one function, whereas what I hope we're proposing is to divorce the notion of priorities in ATAG from WCAG, since there are differences - we need to have higher priority for tools than for content. Conformance levels is what we have to deal with. I think we are too connected to the other guideline. Just allowing is a lower conformance level.
JT This relative conformance doesn't apply to all checkpoints - ther are only certain ones.
WL I don't think priorities apply to checkpoints here.
PJ I think we have given examples where prompt the user to do something, you could change the priority depending on the WCAG priority. I think priority definition should be must,should,may, it should be 'be able to create', 'be difficult', 'be less difficult'.
Proposal: Definition of P1 to be: This checkpoint must be implemented or the tool will not be able to create accessible content.
EH These priorities will have to apply to being able to use the tool
WC Tool or author?
KB ...author will not be able to use the tool to create...
Proposal: Definition of P1 to be: This checkpoint must be implemented or the author will not be able to use the tool to create accessible content.
GR It sounds as if a tool could get a P1 if the tool could create content that is accessible, even if I can't use it
PJ There is a checkpoint that the tool must be accessible, which is a P1.
DD This is a grammatical trick to have the definition simple. When applied to "make the tool accessible" there will not be an ambiguity about it. And, I think the allow, enable as P1 etc will not fly. We want prompting, which is not about allowing - we want promotion to be P1 as well. And, I think there are more than four or five relative checkpoints.
LK Some of these can be addressed if we keep the definition but say it has to be all authors, including authors with disabilities and authors who are 'beginners'. Allowing an author to export to a different tool, then mark it up by hand and re-import it, would not satisfy that.
CMN I think the proposal allows us to keep enough about enabling authors to use the tool. I also think that we can create our own priorities for things if we want.
WC I think we should retain the final sentence of the current definition - Satisfying this checkpoint is a basic requirement for some individuals to be able to use the authoring tool or its output
JA I like the proposal as is, and we could say the last sentence in intro to priorities
KB I think we would like a short, concise definition. If we need to clarify that do it underneath. The 'one or mor groups of authors with disabilities' is redundant, because the proposal says 'the author' which is whoever is using the tool, disabled or not. We want everyone to be able to create output that can be used by everyone.
EH It might be helpful to draft the other two priority levels.
Proposal: Definition of P1 to be: "Authoring tool developers must satisfy this checkpoint or the author will not be able to use the tool to create accessible content."
Definition of P2 to be "Authoring tool developers should satisfy this checkpoint. Otherwise authors using the tool will find it difficult to create accessible content"
Definition of P3 to be "Authoring tool developers may satisfy this checkpoint or authors using the tool will find it somewhat difficult to create accessible content."
JB (from screen) Agree with CMN - For P1 if we don't explicitly talk about User Interface we lose a promotion point, but it can be adequately covered elsewhere. Precision of wording not length of wording. Adding second sentence (as per WC) would be obfuscating. Being completely self-referential and having a clean priority scheme will be helpful. I do share reservations that "able to" may not be strong enough to capture what we want in priority 1. I'm not sure if the proposal captures my concern. If the implementation expectation were to take P1 and P2 together then it might work out OK, but at P1 it wouldn't have captured it. We want to make it easier to, not just allow.
JT At one point we talked about 'the average author will not'...
WL If I sell an authoring tool with the HTML and CSS2 specs and WCAG guidelines and a text editor, that means the author is able to do things required, which is a problem with the current proposal
GR I would like that to say "all authors, especially those with limited technical expertise..." - otherwise it places an undue burden on someone with limited or no technical expertise. I want it a positive - "... so that all authors especially those with limited expertise can use the tool to create ..."
JT I think there are two objections. "Be able to create" is not strong enough wording, and it is not clear to the reader that we are saying that the User Interface needs to be accessible, and people with little expertise need to be helped.
JA To me this is overkill. If you put that in there it says that every person with no expertise has to be able to use every authoring tool, which places undue burden on the tool.
JT Intended outcome is that the author will generate rather than will be able to generate accessible content.
JA We have specific checkpoints and guidelines to address the helping, persuading, etc that must be met. So that doesn't need to be covered in the definition of priority.
cmn
Proposal: Definition of P1 to be: "Authoring tools must satisfy this checkpoint so that authors will be able to use the tool to create accessible content."
Definition of P2 to be "Authoring tools should satisfy this checkpoint so that authors using the tool will find it easier to create accessible content"
Definition of P3 to be "Authoring tools may satisfy this checkpoint so that authors using the tool will be assisted to create accessible content."
Add an explanatory note about authors - Authors refers to all authors regardless of disability. (This sentence to be reworked :(
JB If you lose the P3?
CMN You lose some helpful things, that are good to have even when not implemented
GR For the P1 to stand alone it must have "authors with disabilities"
PJ could we say that in the purpose of the document?
GR We could say it in addition to, but I think it must be in the definition
PJ If it is in both the purpose of the document, in the definition, in a checkpoint, it is overkill
GR You can't overkill this issue.
PJ With my developer hat - if we have to support all levels of authors it won't fly.
KB Not all tools are designed for non-technical users - we've got past that now. There are some things that aren't concerned with the accessibility of the tool or content that we are looking at. If someone makes a really unpleasant tool that passes the guidelines we don't care whether it is an unpleasant tool, so long as it is accessible (passes our guidelines)
JB I'm torn on Gregory's clause. I would oppose "all" because it is not realistic. I would not be opposed to the phrase "including those with disabilities", unless I misunderstood Phill.
PJ Yes, there was a misunderstanding - it isn't "with disabilities" that I meant, it is all skill levels.
AG The residual fuzz level: There is a distinction between how you describe the overall goals and how you describe the priorities for individual checkpoints. The goal is how to succeed, the checkpoints are how to fail. Facility of producing content is a feature. There is also a question of making it hard to do bad things. It is more important to be easy to do the good things than to be hard to do bad things.
PJ Does hard to do bad things include impossible to do horrid things?
AG Yes, but there is no single answer here.
EH There are two parts to these. The imperative (must, should, may) and the other half is a rationale - the impact. We could just define the priorities as must/should/may and go back to wendy's idea of explaining more. In some cases it is to make it impossible to do horrible things, in some cases it is how to do nice things, etc. The bare minimum is must, should, may.
LK You can't require all tools to be useable by everybody regardless of technical ability. how about saying "a novice user of that tool"
PJ In developer world we say "easy to learn".
JT The priorities are for several purposes. To justify the checkpoints - if we take PJ definition then many current P1 will no longer be P1 - people will be able to do things if they try hard enough. The things that are most important are the things that will result in the author creating an accessible document. The goal of this document is that most authors will create accessible content. I think we need to look at this again...
JB If you were to use the proposed definition on a tool it is interesting. I can create an accessible document (by going through the source and knowing how to Mark-up by myself). We need something about facilitating, although I like the brevity.
/* adjourn. Bruce leaves (I think)
Proposal
2 Goals
The authoring tool is accessible
Authors will create accessible content
Priority 1 is critical to meeting these goals
Priority 2 is important to meeting these goals
Priority 3 is beneficial to meeting these goals
KB Like it, but there's only one goal.
CMN Me too.
Argue number of goals later
KB section 1.4 needs to be rewritten - people might want to put a graphic icon in print, and can't link it
CMN Sure you can - that's what fine print is for.
To be discussed later
EH There are two sets of criteria. You need to indicate in the content how much it impacts people with disabilites. We could combine P1 and 2. In general I like it
PJ I agree with the priorities should meet these goals. We could expand critical, important and benficial to explain what our criteria are. Significantly facilitates is another way to say it. I want to say "it is critical and significantly facilitates ..."
CMN Significantly facilitates seems to equate to important (with basic requirement for meeting to match critical and helps matches beneficial, IMHO)
EH Reference to other documents is a broad brush, and can't be done with a simple priority.
WL
The authoring tool is accessible
Authors will create accessible content
according to these goals:
Priority 1 is critical
Priority 2 is important
Priority 3 is beneficial
Using real examples: there will be more tools of the "save to web" type. Are we too strung up in thinking about Whizz-bang HTML editors and not thinking hard enough about the other types of editor? In addition to goals we have audiences. us, wai-ig list, TimBL, consortium (which is central to it becoming a recommendation). After all of that we get to audiences we are talking about. Developers, conformance testing in a court, ... Be sure we keep the multiple audiences in mind.
AG I think we may have got as close to a consensus as we will get today...
JB WL is right in the different levels of tests. These would not pass the Judy test. These are undefined and not self-evident. And there is no idea of what those things are supposed to mean evident from the working group discussion.
CMN They seem like definitions to me - I am surprised to hear that they are not self-evident
GR me too.
LK me too.
MN Seems to me a definition. Agree with Phill that we need to be clear what critical is. I am thinking about how to do a translation, so it has to be clarified, but keeping it simple is important.
JT Change critical to essential.
JB that helps
GR yes, or indispensible. If we keep critical we have to define critical. Propose we use a word to mark priority.
2 Goals
The authoring tool is accessible
Authors will create accessible content
Priority 1 is essential to meeting these goals
Priority 2 is important to meeting these goals
Priority 3 is beneficial to meeting these goals
These terms to be further defined
So resolved
Proposal: Use 'essential' instead of 'Priority 1' to mark checkpoints.
DD No, better to be consistent with other guidelines
GR But makes it easier to present to people
Proposed: Increase teleconferences to 90 minutes
JB Must be well-prepared agendas for meetings.
JT, CMN there are.
JB It is a hard sell to developers if there is a lot of time committed.
EH It might have been more productive here if someone was familiar with the changes I had suggested.
JT It was a part of the agenda, we have run out of time.
GR We appreciate the time and effort but there was a formatting issue of how to get things to the agenda - if you seperate the issues it makes it easier.
Resolved: Increase teleconferences to 90 minutes
JB me, JT, CMN should continue to pursue developers. If we do bring them in there will be difficulty with process because new members will not find a common understanding of material in the document.
AG We have some action items of a bottom-up nature due for teleconference in two weeks. Was there anything out of the debate that should be turned into an action item.
JB I do not think this group is near last call. The charter went out with specific dates, and the group has worked hard to keep to those but I think the group will not meet those, so we should reconsider and adjust charter.
DD ATRC people were doing a review of existing tools
JT That's on the ATRC page - http://www.utoronto.ca/atrc
Next meeting: 1-617-252-7000 at 3.30pm US EDT
Last Modified $Date: 2000/11/08 08:11:50 $ by Charles McCathieNevile