WAI Authoring Tool Guidelines Working Group
Chair: Jutta Treviranus
Date: Wednesday 8 December 1999
Time: 3.30pm - 5:00pm Boston time (1830Z - 2100Z)
Phone number: Tobin Bridge, +1 (617) 252 7000
The Latest Draft is the working draft dated 8 december, available at http://www.w3.org/WAI/AU/PR-WAI-AUTOOLS-19991208.
JT has everyone read the open issues and document?
JB I read parts of it, noted some things to Charles.
JT I found grammar and spelling.
CMN post it to the list.
JB yes, post everything to the list.
JT The 3 types of checking defns are very clear, better than what was going on the list.
CMN see the message "new draft with details."
JT we have a defn for "check for." we were going to come up with non-grey examples.
CMN I put in one for each.
PJ don't think we have enough examples. I had a work item from yesterday to do that. CMN new proposal has the wording but needs examples.
JT do we want to come up with examples now?
PJ I know the type of examples I want to see there.
CMN yes, some hints.
JB How much has Bruce followed things, we only have him on the call for a few minutes.
JT have you read minutes from yesterday?
JT PJ want to summarize?
PJ agreed to add words to checkpoints that have relative priorities or point to WCAG - they don't necessary apply to all checkpoints. an algorithm to determine which are applicable or not. those that are machine checkable are required to be supported by the tool. a second area, where tool looks at semantic information, e.g. if turn of table will look o.k. when linearized? 3rd class are prompting - "did you consider this or that?" so, author responsiblity. where we're at now are examples for each type.
JT that's 3.1 and 3.2 algorithms.
PJ and we reworded 1.3. want to discuss skill level of user with Bruce on the line.
JT PJ has posted 4 messages. some are editorial. go right to skill?
PJ "the web page resolves level of user skill and priority" we don't seem to have consensus.
JT which message was that?
PJ one with the longer subject.
CMN can you summarzie?
PJ we took action item about what level we assume skill to be. if author more motivated or knowledgeable about accessibiliy and markup language. if skill level is higher, then priority might be lower. i don't know if we want to reopen this issue or we need to state that it wasn't really closed with total consensus. shall we document level we assume?
BR do we define the level of knowledge of the user, if we assume they are motivated , would any priorities change?
CMN are we interested in changing that assumption? the resolution of the group is no. If we change that assumption, then the priorities can be changed.
PJ I just want to document that in the resolutions, not in the guidelines.
JT would you agree that the average user is not aware of accessibility?
/* yes */
BR when you add an image to a word processing document, and convert to HTML, there is no alt-text. However, possible to add a name for purposes of scripting. I suggested to use the name for alt-text.
JT many questions about acceptable alt-text.
CMN if you relying on the tool to make content accessible, then you won't reach end goal.
BR for motivated user, you would.
CMN for motivated user you don't need to do any of this.
BR no, this tool blocked motivated user to add alt-text.
CMN I used word with lots of hackery.
PJ but in your example, you had to change tools.
CMN no, i found a way to do it in word. most people are not sufficiently knowledgeable to do so.
PJ BR's example is that some tools need fixes. if you can use a tool, have content in that format, and way to add a feature to the tool to make better. however, priority levels are so high, that even with fixes the tool hasn't reached a conformance level.
BR capability in product to enter a name for an image. i was suggesting they use it to generate alt-text. it is an inexpensive way to do it.
WL way to say "alt-text" rather than "title."
BR a cost to translate that to a whole lot of languages.
PJ doesn't make it meet a conformance level unless we change the priority level.
JT no, if they are prompted for text at all, whether called "alt text" or not doesn't mean they won't conform.
WL question is, does the title that the author gives qualify as good alt-text.
BR if a tool does not produce accessible content, and found inexpensive way to do it, could we add to documentation. "here is what you need to do...you will produce accessible content." does that take to level A or not.
CMN good steps towards,
PJ we'd have to go through P1 in WCAG to cover them all.
BR that's not for an average user.
JT it doesn't prompt for a title. if search for it in documentation, they can find info. not conform. it's not the most obvious.
BR then, we should document as minority opinion.
JT BR has a minority opinion that we should change the assumptions of the author to assume they are highly motivated.
PJ I agree we need to document the assumption, and try to lower the priorities.
JT do you agree that we should assume that the author is motivated?
PJ yes. if we raise the skill level of the priority we coudl lower the priority and have more tool comply.
JB let's take several steps back. PJ as an active working group member if you are dropping the priority, then we need to consider this.
PJ I went through archives. This resolution was not properly addressed. I did not participate in it. I do not agree.
JB then the group is not in consensus on the document.
PJ What BR and I were going to propose: if we document the fact that if we raise skill level we could lower the priorities. however, the doc should go forward.
JT you 2 agree that average user does not know about accessibility.
PJ right, ave user does not know about accessibility. however, if higher than average, then we could lower priorities.
JT but then that means we're writing the document for a minority.
BR another way to state it: A used by highlymotivated user, AA ave user does not know about accessibility, AAA used by below average user.
CMN introducing a massive change with this proposal. if we adopt this it changes the document a lot.
JT A makes an accessible document, AA makes a more accessible, AAA makes a very accessible document for the average user.
CMN priority levels also ensure users with disabilities can use the tool. we can record, but I oppose it.
JT we want to target the average user.
DB which tools will be used by diff skill levels?
PJ word processors.
DB don't those have to do more?
PJ yes, the tool do more because the user is not motivated.
DB then person who uses X product is more motivated because they use word? not sure i agree with skill level and openness to accessibility.
PJ separate awareness of the tool from awareness of accessibility. author has to know some accessibiilty to produce content.
JT tool will educate user.
PJ then raises the bar on the tool.
BR if someone asks me a tool to produce accessible HTML, I want to point them to a level A tool. it's not easy to do, but read section on accessibility and you should do it. or, i have a team but don't want them to take time to educate themselves, then I want a AA tool.
CMN if someone comes to me and says i want to do it and i'm motivated, then
IJ split in reasoning. you should not assume skill or motivated user. may separate issue for user interface. the goal is to get all tools to produce accessible content with average awareness of markup.
CMN some tools require users to know about content. HomeSite says, here is how to mark up words. But if you use Word and say "convert to HTML" that is a different expectation. We aren't saying what type of product to develop, but what the tool should do: "generate content that is accessible."
WL are we getting back to priority 0 discussion? if the base is "can the tool produce accessible content" then a lot of tools will conform.
JT yes, there are a lot of tools. we're trying to improve the tools and make it possible for average user to make accessible content.
PJ log that, but then log that some people think another level of conformance is useful.
JT therefore, don't change the guidelines but note in issues document that you want a different assumption regarding the author skill level and motivation.
/* PJ and BR agree */
JB this is an interesting process question. the purpose of minority opinions is to advise AC members during a Proposed Recommendation. We thought we were at a stage between PR and Rec where the working group is resolving issues that have come in. In yesterday's discussion we approached consensus on issues. This issue was not flagged as a "send it back to WG issue" in the comments that came in. Flagging minority opinion does not make a lot of sense.
BR another way to treat it. there is a proposal based on review process. we're saying we don't agree with the resolution.
JB then that is sent as "advise" to the Director.
PJ I thought that Bruce's issues were "send it back."
JB this was not mentioned as a specific issue in that message.
IJ process comment: note that consensus means "agreement to go ahead." the document won't say anything about various priority levels.
CMN I don't have difficulty in documenting issues. It's more of a question of what does that gain?
JT i don't think there is disagreement with defn of ave user, but priority levels so that certain tools can approach the bar.
JB I don't understand the point of documenting your "minority opinion?"
BR just documenting the fact that we disagree.
CMN a future working group could deal with it. this issue is flagged for them.
PJ I have the note on the vote, and it says, "issue 2 - lack of clarity ..." as submitted by Mark Day.
JT we've made it more clear.
PJ BR's additional note was not addressed properly in this discussion.
BR I think it has been addressed.
PJ what do we accomplish by putting it in the minutes? The director needs to understand that the bar has been set high. We don't want it that high, we want a tool directed at motivated users. That would be useful to purchasers.
JT What if we list tools that could be used by motivated user.
PJ yes, that would be useful.
JB correcting statement that yes, it was in Mark's e-mail.
CMN then let's record in PR issues resolution that PJ and GR would prefer to do priorities a different way.
IJ I disagree. If there is that much hesitation, then it should be resolved. You either say to the director we are ready to go to Rec or not.
JT PJ and BR since concerned about documenting tools that the motivated user can use.
PJ simpler approach: in techniques there are tools that can be used today. this document is higher.
WL we already did that didn't we?
PJ that's documented in the document?
CMN it makes sense for the WG to advise the director for how best to resolve the issue. we all seem to agree that we can say, "we think that the 8 dec draft w/editorial fixes would be appropriate doc to become a Rec. certain people feel there are other things we can do."
IJ that is always going to be the case. go without caveats to the director.
CMN "where possible" is where that is o.k.
JT can we finish talking about PJ and BR's concerns? then we can decide what to bring to the director.
PJ add a statement to section on priorities. we acknowledge that there are tools that produce accessible content...put this in Techniques and Guidelines. Perhaps add a section abotu the types of tools that do that: text editors, tools that don't remove markup. Therefore, we don't need to list the names of the tools.
JT BR does this satisfy your concerns.
BR not completely. that won't motivate developers to conform. they want to get on that list. it may be so hard that they won't do it.
JB can't use this as only incentive. this is not an incentive but to satisfy another concern. what about business conern.
IJ there are tools that allow motivate users to create content that may not conform to this document. the purpose of the document is to address the largest population so that there is more accessible content on the Web.
PJ make it for motivated developers only.
IJ motivation of author or developer?
JT BR, your concern is that there is not enough motiviation for developers.
BR yes, but I don't want to stop the process for this. it's clear there are 2 camps.
PJ therefore, we resolve that this is the "higher level bar" document.
JT yes, we are addressing the average user.
CMN I would rather have the proposed statement in the INtro than with priorities. and preferably in the issues list.
PJ only in the issue list it is only read by a few people.
CMN objecting strongly to put in priority.
IJ what about in terms and defn?
CMN in intro.
CMN however, if we put too much emphasis on this it takes away from the user interface being accessible.
PJ therefore, we should put this statement immediately following discussion of the goals in the Intro with the following statement, "They don't conform to the guidelines because they may not be accessible."
Resolved: add a modified version of the following paragraph to the Intro: there are tools that allow motivate users to create content that may not conform to this document and they may not be accessible. the purpose of the document is to address the largest population so that there is more accessible content on the Web.
JB everyone needs to agree on drafts and actual changes before we move forwards. Today's changes need to be in a new document and reviewed by people. Make timelines and commitments for people to read and report back.
JT we would like that by Friday.
JB some people are not online the next couple of days. Therefore, I would say Monday.
CMN i propose to put it out by Friday morning U.S. time.
JB so end of day Monday.
PJ what about my editorial comments? 3.3 on applicability.
JT can everyone read them and send comments to the list.
CMN one measure of it being a big deal or not is, if you don't make them will it make a difference.
PJ yes except 1.3 where i added a note.
IJ what does it change?
PJ deleted word "w3c" before guidelines. then said, some guidelines are not applicable to the tools not generating markup. same note that we added to other checkpoints.
JT you want to say, "some web content can not be generated automatically." isnt't that an assumption.
PJ I thought that was the way we worded the checkpoint.
JT right, so we have the word "when" in there.
/* agreement - no change */
PJ in 2 Dec draft there was a sentence on applicability that was deleted. In e-mail I proposed "note. some AU guidelines may not apply to certain classes...." last sentence. I had written a note before seeing CMN's new draft.
JT why was the note dropped?
CMN it seemed that it was confusing the issue and priority defn. shifting applicability to particular checkpoints seemed to make more sense.
PJ but we don't discuss it in each checkpoint.
IJ I thought every checkpoint applied but it was up to the tool. how you do it varies.
PJ applicability is not the same as can all authoring tools do this. it doesn't apply.
IJ when you map to WCAG checkpoint you use discretion. therefore you are paying attn to the ATAG.
PJ I want to improve applicability in conformance section. it has to do all of the checkpoints...
JT IJ and CMN points is that we have put scope statements in checkpoints themselves.
/* CMN leaves */
PJ the statement, "it varies according to the type of tool" needs to be included.
/* IJ leaves */
@@ JT propose rewording of PJ's proposal.
/* JB leaves */
PJ there were 2 paragraphs proposed on defn of priority. one about "all authoring tools..." then "in choosing priorities..." i propose combining into one.
JT your 12:30 e-mail?
PJ Yes. I was trying to combine the two paragraphs.
@@JT will draw from PJ's messages.
Last Modified $Date: 2000/11/08 08:11:51 $