- From: Charles McCathieNevile <charles@w3.org>
- Date: Wed, 2 Jun 1999 18:58:28 -0400 (EDT)
- To: WAI AU Guidelines <w3c-wai-au@w3.org>
Meeting minutes are linked from the group page, at
htp://www.w3.org/WAI/AU/telecon-2jun99
Note that for the next meeting Jutta will be in Sweden, so I will be chairing
and Jim Allan will be taking minutes (thanks Jim).
Topiccs for next meeting are Bruce's proposal regarding the goals in teh
definitions of priority, and the definitions section.
There will be a new draft of the document in the morning. Please read the
Techniques document, which includes all the guidelines text and techniques -
it has a different status, abstract and introduction, and no conformance
section. Otherwise it has everything in the Guideines document itself.
Highlights from the meeting:
* Resolved: 2.3 to be "Support accessible Authoring Practices".
2.3.1 to be the present title of the Guideline.
* Resolved: 2.3.4 and 2.3.5 to become 2.3.4 Preserve accessible
content during conversions and transformations
* Resolved: 2.1.1 Use all applicable operating system and
accessibility standards and conventions.
* Resolved: 2.4.1 moved to after current 2.4.3 and add "structural
information" to wording of it.
* Action Gregory: Propose definition of transformations.
* Action GR: Propose new wording for 2.1.3, 2.1.4, 2.1.5
Complete minutes:
[1]W3C [2]Web Accessibility Initiative
[3]WAI Authoring Tool Guidelines Working Group
WAI AU Teleconference - 2 June 1999
Details
Chair: Jutta Treviranus, [4]jutta.treviranus@utoronto.ca
Date: Wednesday 2 June 1999
Time: 3.30pm - 5:00pm Boston time (1930Z - 2100Z)
Phone number: Tobin Bridge, +1 (617) 252 7000
_________________________________________________________________
Agenda
Review of Latest Draft
The latest working group draft is
[5]http://www.w3.org/WAI/AU/WAI-AUTOOLS-19990527.
* Guideline 2.1
Raised by Charles McCathieNevile:
[6]http://lists.w3.org/Archives/Public/w3c-wai-au/1999AprJun/0272
See also
[7]http://lists.w3.org/Archives/Public/w3c-wai-au/1999AprJun/0298
* Guideline 2.3 and checkpoint 2.3.1 names and restriction to W3C
recommendations
Raised by Charles McCathieNevile:
[8]http://lists.w3.org/Archives/Public/w3c-wai-au/1999AprJun/0292
* Merge checkpoints 2.3.4 and 2.3.5 and place in guideline 2.4
Raised by Charles McCathieNevile:
[9]http://lists.w3.org/Archives/Public/w3c-wai-au/1999AprJun/0291
_________________________________________________________________
Attendance
* Jan Richards
* Jutta Treviranus
* Charles McCathieNevile
* Gregory Rosmaita
* William Loughborough
* Kynn Bartlett
* Wendy Chisholm
* Jim Allan
Regrets
* Ian Jacobs
* Eric Hansen
_________________________________________________________________
Action Items and Resolutions
* Resolved: 2.3 to be "Support accessible Authoring Practices".
2.3.1 to be the present title of the Guideline.
* Resolved: 2.3.4 and 2.3.5 to become 2.3.4 Preserve accessible
content during conversions and transformations
* Resolved: 2.1.1 Use all applicable operating system and
accessibility standards and conventions.
* Resolved: 2.4.1 moved to after current 2.4.3 and add "structural
information" to wording of it.
* Action Gregory: Propose definition of transformations.
* Action GR: Propose new wording for 2.1.3, 2.1.4, 2.1.5
_________________________________________________________________
Minutes
Guideline 2.3
CMN We now have no checkpoint sayig support accessible authoring
practices for non-W3C stuff
GR Having a general statement as a guideline is good. I would vote
against changing it.
JT Proposal is to make Guideline "support all accessible authoring
practices"
GR: That's ok So 2.3.1 would say "support all accessible authoring
practices in languages supported by the tool" That's fine by me
JR I have a problem saying "all" in the guideline title
CMN The guideline title isn't that critical - it is a general
principle. The checkpoints are what has to be done.
GR OK
JT There won't be a checkpoint referring to W3C recs?
CMN No. There will be references in teh techniques to specifc
definitions..
Resolved: 2.3 to be "Support accessible Authoring Practices". 2.3.1 to
be the present title of the Guideline.
Checkpoints 2.3.4, 2.3.5 merged and placed into 2.4
GR I think that we are talking about two distinct but related things.
We are saying the tool has to recognise the accessiblity markup for
imported/converted languages, and that accessibility features need to
be preserved. I like the separation.
WL Why isn't that an import?
JA If you open something in Frontpage it trashes your markup. That
doesn't mean import to me.
WL An import is opening a file.
CMN I really like Wendy's proposal.
WC Yes. I think that covers the problem Gregory and Jim are talking
about.
JR I think that is good, but I think it should stay in 2.3
GR If anything was going into 2.4 I would move 2.3.5
JR I think 2.4 is mainly about descriptive content
JT And structural stuff
WC I prefer it in 2.3
JT Do we say content, or content and structure?
CMN I proposed "preserve accessibility features of content during
conversion and transformations" (in the broad sense of content)
JA I think we should leave it as content and leave the issue of the
meaning to later
Resolved: 2.3.4 and 2.3.5 to become 2.3.4 Preserve accessible content
during conversions and transformations
GR I have a problem - we dont have a definition of transformation
anywhere.
JT Should we add a definition?
CMN Yes, I think it is a good idea
Action Gregory: Propose definition of transformations.
CMN We should probably go through definitions section very carefully
for next week.
/*Process: JT Will be talking to the King of Sweden for next week's
meeting. CMN to chair meeting. JA will take minutes
Guideline 2.1
WL We are facing the first example of a chance to do something about
the accessibility of software. WAI has done nothing about software in
general. Any chipping away at this should be resisted.
CMN The techniques stuff there comes from my draft of a Note,
following my action item to look at doing that with Ian. They are
based on a large number of guidelines (references have been sent to
email list)
/* KB leaves temporarily
CMN I would make a slight change to my proposal for 2.1.1 to include
application guidelines.
GR I can see that - 2.1.2 is a technique for 2.1.1 And User Agent
Guidelines are GUI oriented.
CMN And they are not a recommendation yet. Hopefully we will be there
when they are.
JT The rationale for this was that User Agent Guidelines would be a
stablereference document.
CMN It seems that this document is not stable, so we could refer to it
in techniques.
JR I think it shoud remain a checkpoint - it is the only W3C software
guideline we have to look at. I also don't like the proposed 2.1.1...
WL Does 2.1.1 get covered in the user agent guidelines?
CMN The dependency is ill-defined. If we let go of them, we are freed
from waiting for them
JT We can trust in the W3C process to do ensure the document is OK
JR You may have an authoring tool that has no browser functionality.
JT 2.1.1 is not covered by 2.1.2. Is 2.1.2 covered by 2.1.1?
CMN I think 2.1.1 can be covered by 2.1.1
GR I lean to making 2.1.2 a technique for 2.1.1 My understanding is to
go here from General to specific. We start with the General things,
then address authoring tools. 2.1.2 says "if the tool has an extra
functionality (as a user agent)" - that is less general than other
authoring tool specific requirements we have. So moving it down the
list will go towards solving the problem
JR So what if we take 2.1.2 and move it further down the list. We
could move the actual reference to the techniques.
CMN If we remove the reference then the checkpoint disappears
JT No, it is a functionality
GR I agree - this is a key part of functionality.
CMN OK, so move it down list of 2.1 and leave as is. So also drop
proposed 2.1.1
JT dropping that means there is no reference to accessibility
standards, and no reference to platform the tool runs on.
CMN I dropped "the platform the tool runs on" because it seemed so
obvious, and had accessibility standards in proposed 2.1.1
Proposal: Use operating system and accessibility standards and
conventions
GR should still have "all appropriate". I don't know that we should
change it or we'll lose something
WC In the case of Java does that break that?
GR OK, so we should have Use all applicable operating system and
accessibility standards and conventions
JT Who defines applicable
CMN Applicable means "those which can be applied".
Resolved: 2.1.1 Use all applicable operating system and accessibility
standards and conventions.
CMN Proposal for moving 2.1.3 comes from talking to Phill. It is
redundant with 2.1.5
JT You could use a tool and get at the property of a particular
element. What we are addressing here is to have a completely different
view so I can see everything. That is convenient. That has to be
separate from how it is published.
JR This is important to keep.
CMN I agree I think it is P2 or P3
GR No
JT This gets to the heart of the problem - it allows the author to
create things
CMN No. Being able to access the propoerties and edit them is
necessary. Having a convenient view is important.
GR If I ahve a contract to design a site and have to use a horrible
background image and colour scheme, I should be able to change the
rendering so I can see these things while I am editing them
WL Hence 2.1.5
GR No. 2.1.3 is rendering of the document being edited.
CMN I can see this
JR It is different from deciding the colour - it is being able to
edit.
JT It is being able to see the document, not just edit the document.
JA I need 24 point on the screen. In current WYSIWYG editors if I put
24 pt font, everything gets changed
CMN Yes, I agree with that.
CMN 2.1.4 seems a technique for 2.1.3
JT, JA, WL agree
GR I don't think we can lose it. We lose the bit about tags
JR isn't that already in 2.1.3 - the alternate rendering can be
textual
JT You may want the image and the graphic
JR The properties are available under 2.1.5. The rendering is covered
2.1.3
GR I don't think so. I think it is too broad. There is a discontinuity
between that and 2.1.5. 2.1.4 should say ...
CMN it needs to be clear that the rendering of the properties is
accessible - is that what you are saying?
GR Not quite.
JT Are we counting a text equivalent as a property? There are
instances where you want both
CMN Yes. I agree with Jan - the rendered version is available from
2.1.3, the text equivalent is there from 2.1.5.
GR I think it needs to be there "allow the author to display a textual
equivalent of each element while editing.
JR A developer might wonder what 2.1.3 was there for
WL There are a number of intertwined "definitions" here.
JR If you pull text equivalence out and make it a checkpoint? It is a
technique for 2.1.3
Action GR: Propose new wording for 2.1.3, 2.1.4, 2.1.5
CMN I assume that 2.1.5 means edit propoerties
JT This is for pre-packaged alternative content. in terms of 2.1 it is
about reading.
JR I see CMN's point. We should be asking here for all properties
JT In 2.1 we are looking at equivalent practise.
JR Because we ask for access..
CMN I think we should say accessible including editable in this
section.
JR I think we should say that pre-written alternative content should
be editable in 2.4
JT In 2.1 we are saying make sure that everybody has equivalent access
to the authoring process. Outside that we are specifying the practices
you should include
WL This came up because there are tools that don't let you edit
alternative content.
GR I would say 2.4.1 is misplaced - it should be after 2.4.3 and
should include "structural information".
CMN I would buy that
Resolved: 2.4.1 moved to after current 2.4.3 and add "structural
information" to wording of it.
Action everyone: Review Definitions, and techniques for next week.
_________________________________________________________________
[10]Copyright © 1999 [11]W3C ([12]MIT, [13]INRIA, [14]Keio ), All
Rights Reserved. W3C [15]liability, [16]trademark, [17]document use
and [18]software licensing rules apply. Your interactions with this
site are in accordance with our [19]public and [20]Member privacy
statements.
_________________________________________________________________
Last Modified $Date: 1999/06/02 21:03:43 $ by [21]Charles
McCathieNevile
References
1. http://www.w3.org/WAI/
2. http://www.w3.org/WAI/
3. http://www.w3.org/WAI/AU
4. mailto:jutta.treviranus@utoronto.ca
5. http://www.w3.org/WAI/AU/WAI-AUTOOLS-19990527
6. http://lists.w3.org/Archives/Public/w3c-wai-au/1999AprJun/0272.html
7. http://lists.w3.org/Archives/Public/w3c-wai-au/1999AprJun/0298.html
8. http://lists.w3.org/Archives/Public/w3c-wai-au/1999AprJun/0292.html
9. http://lists.w3.org/Archives/Public/w3c-wai-au/1999AprJun/0291.html
10. http://www.w3.org/Consortium/Legal/ipr-notice.html#Copyright
11. http://www.w3.org/
12. http://www.lcs.mit.edu/
13. http://www.inria.fr/
14. http://www.keio.ac.jp/
15. http://www.w3.org/Consortium/Legal/ipr-notice.html#Legal Disclaimer
16. http://www.w3.org/Consortium/Legal/ipr-notice.html#W3C Trademarks
17. http://www.w3.org/Consortium/Legal/copyright-documents.html
18. http://www.w3.org/Consortium/Legal/copyright-software.html
19. http://www.w3.org/Consortium/Legal/privacy-statement.html#Public
20. http://www.w3.org/Consortium/Legal/privacy-statement.html#Members
21. mailto:charles@w3.org
--Charles McCathieNevile mailto:charles@w3.org
phone: +1 617 258 0992 http://www.w3.org/People/Charles
W3C Web Accessibility Initiative http://www.w3.org/WAI
MIT/LCS - 545 Technology sq., Cambridge MA, 02139, USA
Received on Wednesday, 2 June 1999 18:58:31 UTC