WAI Authoring Tool Guidelines Working Group

WAI AU Teleconference - 7 Apr 1999

Details

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

Agenda (draft)

Review of Latest Draft

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

Carried over from previous meeting:

Priorities of checkpoints
- 2.7.4 - P2? (LW)
Technique for 2.2 - heuristically guessed structure from visual formatting
Conformance be adopted from Web Content Accessibility Guidelines

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

Attendance

Jutta Treviranus - Chair
William Loughborough
Jan Richards
Charles McCathieNevile - scribe
Kynn Bartlett
Jim Allan
Gregory Rosmaita
Bruce Roberts

Regrets

Ian Jacobs
Daniel Dardailler

Action Items and Resolutions

Techniques to be incorporated automatically when proposed
CMN to discuss with JB whether we can include our changes and IG-proposed changes in TR drafts
Proposed Weekly calls for one hour. Discuss further on list
KB to submit revised 2.4 checkpoints
2.6.5, 2.6.6 to be moved to techniques
Create standard wording to define conformance to WCGL priorities, to be added to 2.2.2, 2.2.3, 2.3.2
"consistent with look and feel" clause of 2.6.3 to become technique
wording change for 2.1.2, to "...must not make content inaccessible"
Priority 1 for 2.1.2, all in 2.2, 2.3.1, 2.3.2, 2.3.5, 2.5.1, 2.5.2, 2.6.1, 2.6.3, 2.7.1
Priority 2 for 2.1.1, 2.3.3, 2.6.2, 2.7.2
Priority 3 for 2.3.4, 2.6.4

Minutes

Meeting begun: 15:40 EDT

priorities:

JT: We would like to propose priorities for each checkpoint

Reading of priority definitions.

2.1.1

2.1.2

P1 ?

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

2.2.1

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

2.2.2

KB WCAG has three levels of priority. Should P1 refer to all of those, or paralell their priorities

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

2.2.3

BR P2 - it can be fixed afterwards, although it is more difficult

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

2.3.1

2.3.2

JR Structural information could be classified but not necessarily P1 - should we refer to WCAG conformanceagain?

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

2.3.3

CMN 2

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

2.3.4

BR 3?

Resolvd 3

2.3.5

JR there is a 1 and a 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

2.4

Waiting on new text.

*KB feels guilty

Resolved - leave until new text comes

2.5.1

2.5.2

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

2.6.1

2.6.2

lots of 2

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

2.6.3

WL P1

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

2.6.4

2.6.5

JT reword to refer to WCAG

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

2.6.6

Move to techniques

2.7.1

WL 4

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.

2.7.2

JT to "integrate accessible authoring practice into the help system"

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

Time is running out!!!

CMN Propose we adopt techniques and argue about them afterwards

So Resolved

KB Should we note controversial suggestions?

Resolved Yes

Process

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

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 $Date: 2000/11/08 08:11:51 $ by Charles McCathieNevile