WAI Authoring Tool Guidelines Working Group
Chair: Jutta Treviranus, jutta.treviranus@utoronto.ca
Date: Wednesday 7 April 1999
Time: 3.30pm - 5pm Boston time (1930Z - 2100Z)
Phone number: Tobin Bridge, +1 (617) 252 7000
The latest working group draft is http://www.w3.org/WAI/AU/WAI-AUTOOLS-19990331.
Carried over from previous meeting:
Proposed by Kynn Bartlett: http://lists.w3.org/Archives/Public/w3c-wai-au/1999JanMar/0235
Generation of text-only site as a technique
Raised by Lauren Wood: http://lists.w3.org/Archives/Public/w3c-wai-au/1999JanMar/0260
Do checkpoints in section 3.3 and 3.4 need to be implemented "natively", or can they simply be satisfied by providing an interface for assistive technologies?
Proposed by Jan Richards: http://lists.w3.org/Archives/Public/w3c-wai-au/1999JanMar/0260
Add section on compliance resources, featuring A-prompt.
Proposed by Charles McCathieNevile: http://lists.w3.org/Archives/Public/w3c-wai-au/1999AprJun/0005.html
techniques (explanation of in/accessible DTD extensions) for 2.1.1
Meeting begun: 15:40 EDT
JT: We would like to propose priorities for each checkpoint
Reading of priority definitions.
BR: What if you are targetting a specific browser?
CMN: Then you are failing people who cannot use it
GR: I read it - if you target platform X you should give two options - W3C DTD or W3C DTD plus browser extensions.
BR: If my target is an intranet where NS is required
CMN: It is not extension per se which is prohibited, only an extension which reduces acessibility
JT: there are some extensions which only reduce accesssibility, and are really only P2
WL Agree
JR should we split the checkpoints
CMN: propose - make it 1, note the issue
JA change wording to "must not be inaccessible"
WL do not imply that it only affects extensions
JA "must not make document content inaccessible"
Resolved: P1, wording to "must not make content inaccessible
BR What does implement mean?
JT Means the author can use the feaure within the document
KB: Explain implement in definitions
BR That would be fine
Resolved P1, explain implement in definitions
CMN Should be priority according to WCAG priority
GR is implicit in conformance definition
CMN I think we should have a direct statement in the checkpoint that WCAG prioties apply.
WL Put it in technique
GR: Produce content that conforms to WCAG in accordance with the prioritisation in that document.
Resolved: wording to go into checkpoint
CMN, JT agree
JA note in techniques that it can be done
JR There is a problem if the user doesn't know how to fix it
CMN Should be graded same as 2.2.2 - with respect to WCAG
JT It would be strange to make any of these not P1
GR Agreed - otherwise we put too much emphasis on author's knowledge
BR According to priorities in WCAG
JR we could transfer statement to intro?
CMN Should be per checkpoint for consistency
KB agree
JA into 2.2.2 and 2.2.3
JR withdraw proposal
Resolved Priority as per WCAG
CMN I will try to create a WCGL priority whch refers to the WCAG priorities
GR Prefer to have P1 plus pointer in checkpoint
WL CMNs solution makes u depend on other thing
GR and dilutes priority
JR Use wording in checkpoint, and keep P1
So resolved
JA If they create a form is LABEL required or optional
CMN Optional
GR Relate to WCAG as in 2.2.2
WL There is structural info - this might check on heading levels etc
CMN this might be P2, although important
GR Forms are pretty m,uch inaccessible without information
JT This seems to be relative to WCAG priority
GR P1 with reference to WCAG as per 2.2.2
JT Same applies to 2.3.1
WL Prompting author is P1. What gets prompted is configurable according to WCAG
Resolved as per GR suggests
WL 3
BR How does this differ from Templates?
JT If your tools comes shipped with multimedia pieces - gifs, wavs, etc
GR That is a good question - we should address that in techniques
Resolved P2 note WL for P3
Resolvd 3
CMN I think it's a 2, with the exception case not being a problem
BR Make it clearer what it means
JR Refers to second time a user places an object
CMN No I think it refers to the first time
JT Agreed - require human intervention in ALT content
WL P1
Resolved P1 - text to be clarified
*KB feels guilty
Resolved - leave until new text comes
JA What about rearranging? You can't edit stuff in Frontpage since it trashes whatever you are trying to do.
CMN leave as 1 note that changing is still a problem
WL What if you removed teh word unrecognised?
BR Never remove, add or change?
GR You could move things around
WL not without alerting the author
lots of people: yes you can - it doesn't affect the accesibility
JR If the tool knows something is better it can play with it. If it doesn't recognise it then it should leave it alone.
BR need to define author
JT There are cases where we want the tool to alter the markup.
Resolved P1 - needs to be explained further in checkpoints or techniques
when we have HTML 5 with some brilliant improvement we don't want tools to remove it
JR 1 - psychological thing
KB important but does it fit the criteria for P1
CMN I think this is P2 in terms of accessible output but P1 in terms of User Interface Accessibility
BR I don't think we should make it P1
WL P1 degrades the priorities
BR, JA, JR, JT 2
CMN, GR P2
Resolved P2
BR P3
JR I agree with Bruce. If you are only talking about motivation, then it is up to the strict definition. These are marketing requirements
CMN P1, move integrate look and feel into techniques
Resolved P1, move "look and feel into techniques
GR Maybe tack on consistent with look and feel to guideline intro
WL Will be clear in 2.4.2. Guilt trips Kynn some more
CMN I don't like this a lot, think it is a 3
JA covered by 2.6.1 and 2.6.2
GR Technique
WL Kill it
Resolved Move to technique
CMN If you don't document it, people can't use it, game over
JR Not just help files
KB Don't like 'explain'
JA Facilitate by explanations
CMN This says 'provide documentation'
GR sounds like features of a tool, not the content it produces.
JT this is in section 2, refers to practices of author
GR needs some clarification to make this explicit.
Resolved add 'in context' wording *later withdrawn*
CMN This is documentation. It has to include how to use the tool.
BR In context implies 'context sensitive help'.
JR 2.7.1 - we have to document how to use stuff
JT 2.7.2 - accessible authoring practices needs to be integrated into help
JR also means include ALT in discussions of how to add an image, etc
Resolved P1. Further explanationin techniques instead of 'in context' wording.
WL Can this be a technique
CMN No.
JT No - it must be done.
JR Integrate accessibility practices into all applicable help topics
BR Why isn't this a technique for 2.7.1
CMN Because it is necessary and isn't implied.
GR Accessibility must be a natural part of doing things
BR If I write a chapter on accessibility I satisfy 2.7.1, if I integrate it I satisfy 2.7.2?
Yes
resolved P2
CMN Propose we adopt techniques and argue about them afterwards
So Resolved
KB Should we note controversial suggestions?
Resolved Yes
CMN Was suggested we should be freezing documents when released to IG and only IG changes incorporated before TR
JT But there are errors in IG releases which we fix, and we are on a compressed timeline anyway.
Action CMN Discuss this again with JB - reasons are compressed timeline, all workings are public anyway.
JT Proposed move to weekly calls
BR Can they go back to one hour?
Lots: Yes
To be discussed further on list
Meeting adjourned 17:15
Last Modified $Date: 2000/11/08 08:11:51 $ by Charles McCathieNevile