WAI Technical Meeting Minutes
Agenda still available.
The following individuals were present at the meeting:
Daniel DARDAILLER W3C (France) danield@w3.org - Chair
Mike PACIELLO YRIF (USA) paciello@yuri.org - Scribe
Terry CLOKE BT (UK) terry.cloke@bt-sys.bt.
Michael PIEPER GMD (Germany) michael.pieper@gmd.de
Markku HAKKINEN PW (USA) hakkinen@dev.prodworks.com
Peter BOSHER RNIB (UK) peter@soundlinks.com
Hakon LIE W3C (France) howcome@w3.org
Gianni PELLIS (Italy) g.pellis@agora.stm.it
Geert BORMANS KUL (Belgique) Geert.Bormans@esat.kuleuven.ac.be
Jaap VAN LELIEVELD EBU (Netherlands) Jaap.van.Lelieveld@inter.NL.net
Michael SFYRAKIS ICS-FORTH (Grece) sfyrakis@ics.forth.gr
Steve ZILLES Adobe Systems (USA) szilles@adobe.com
Charles OPPERMANN Microsoft (USA) chuckop@microsoft
George KERSCHER RFB&D (USA) kerscher@montana.com
Ken WILLIAMS IBM (UK) Ken_Williams@uk.ibm.com
Phill JENKINS IBM (USA) phill@austin.ibm.com
Lauren WOOD Softquad Canada) lauren@sqwest.bc.ca
Dave RAGGET W3C/HP (UK) dsr@w3.org
Arnaud LE HORS W3C (France) lehors@w3.org
Bert Bos W3C (France) bert@w3.org
Murray Maloney YRIF (USA) murray@yuri.org
Dominique BURGER INSERM (France) Dominique.Burger@snv.jussieu.fr
Chris LILLEY W3C (France) Chris.Lilley@sophia.inria.fr
Max MAYER VP Gore's National ajmayer@fggm.osis.gov
Performance Review, (USA)
Jim FRUCTERMAN Arterstone (USA) jim@arkenstone.org - via Phone
Will WALKER SUN (USA) william.walker@Sun.COM - via Phone
Introductions and WAI Background (Daniel Dardailler)
Explained some of the history of the W3C's involvement in accessibility and
the WAI. He discussed the IPO, hiring of the director, responsibilities related
to the IPO and the funding process status. This WAI technical meeting is only
for what the W3C is already working on, not what the IPO will do in the future.
The next WAI meeting will focus on Guidelines and Education. It will be held
in Boston at MIT on August 5th. More information about this meeting will be
forthcoming as the date approaches.
Question (by Phill Jenkins): Should this meeting be run in
conjunction with other W3C technical group meetings?
Response (Daniel): Likely, since this will ensure that we have some
of the W3C technical leaders available to us. Send all comments to the WAI-IG
mailing list. This will help facilitate ideas. Today we'll focus on reports from
other working groups and potential next steps.
HTML Status (Dave Raggett)
Dave Raggett provided a summary of the current accessibility issues and
considerations for the next release of HTML codenamed, "couger":
- Forms accessibility including the following enhancements:
- labelled fields
- related fields with captions (field_set element)
- access key support
- Object element (<object data=foo.gif></object>). Alt attribute
goes away with "couger" for object element only. Object contains rich
set of attributes to describe. Intended to capture the non-textual pieces of a
document. Could also be used to capture textual HTML.
- "D" tag (ICADD proposal discussed by Murray Maloney) - (<A
href=foo.html>D</a>) Element to provide description for captioning. D
tag becomes a container.
POINT: Need for both a short and long version of the description. For
example: Sighted users may want a short description of a graph. But the blind
user will want much more information about the content and meaning of the graph.
ISSUE: Content for both "D" tag and Object element requires that
authors put in the content. What's the motivation for doing this? Will they do
it.
POINT (Daniel): "D" tag is ultimately an "and/or"
option. Meets accessibility needs right now and can be implemented right away.
REQUIREMENT: Need for one name for CSS class name.
POINT (Steve Z.): Need to discuss the requirements before we decide on a
solution (D tag versus Object element)
POINT: (Dave R.) Requirements around bindings.
- To attach multiple levels of description to elements (table, image, sound).
- long and short
- use and content
- language
- Urgency
- Curb cut (What benefits people with disabilities will likely benefit
others, similar to sidewalk curb cuts)
- ACTION ITEM: ICADD (represented by Mike P. and George K.) will take
responsibility for posting these requirements to WG list
- Not intrusive
- Title attribute added (functionally works as captioning). Title is not
intended to replace "D" text.
ICADD Status (George Kerscher)
The ICADD22 DTD was designed to provide a structured document solution so
publishers could create accessible documents for students based on requirements
originally specified in the Texas (USA) Braille Bill
HTML is richer and far superior. ICADD's goal is to move towards a single
DTD (HTML) for accessible publishing.
POINT (Dave R.) : "Couger Clean" - ISO move to make this happen
and will include accessibility requirements.
IPP/P elements in ICADD22 to HTML:
- IPP = ink print page. Element in ICADD22. Needed for Braille and
navigation.
- PROPOSAL: To include it as an anchor in HTML. (<a href=#ipp-23>
ipp-23 rel=ipp-23) or <a name=ipp-23>
- Use meta element to notify browser that you're using this convention
- RECOMMENDATION: Reserve prefix name space
XML (Lauren Wood)
Simplified version of SGML. XML does not define elements.
- Reserved name space (things starting with XML_ system type things)
- The WAI technical working group should reserve name space by requesting it
to XML WG.
- ACTION ITEM: Mike Paciello will work on naming convention and submit the
request to Jon Bozak and Tim Bray (XML chairs)
Discussion of Phonetic Support in HTML (Dave Raggett)
- HTML attribute to allow people to specify phonems for speech synthesizers
(hopefully this will happen in XML too)
- Synthesizers support ASCII renderings for letters, within cultural context
- IPA (International Phonetic Alphabet) is geared for linguists. Not sure
whether this is the right way to go.
- Speech synthsizers already support <lang> in "couger" (<p
lang=english>
- Acronym element was accepted by HTML group so that proper pronounciation
can be done
- We need to do more research on this to determine. We agree that phonetic
and Pronounciation support in HTML.
- ACTION ITEM: Seek support for WAI (and possibly W3C) from speech synthsizer
groups
ACSS (Chris Lilley)
Chris Lilley discussed general history of the ACSS style sheet and some of
the functionality of how it works. Stylistic control for audio. W3C student will
be working for Chris to test out the specification with Java.
ACTION ITEM: WAI WG needs to review the ACSS technical specification and
determine accessibility issues. We will act as an advisor/reviewing board to
ensure access.
Chris: Emphasized that CSS has a wide range of non-disability uses, lots of
application.
Hakon: Empahsized the need to review access values and whether they are
adequate. Give this feedback to the CSS WG.
Chris: ACSS is now a working draft. Chris requests that everyone review the
draft and send comments to him via e-mail at:w3c-css-wg@w3.org
Chuck O: Note that ACSS augments screen readers, not replace them.
Daniel: Cascading rules, needs discussion. Possible to ignore all parts of
CSS and only view the audio...or visual. Cascading means to allow for multiple
CSS.
ISSUE: Who controls output: Author or user. Definition of what is actually
accessible to control. WAI would come up with a profile that the user should
control and user agents (browsers, search engines, robots, authoring tools,
screen readers) through preferences dialogue will support. These are
accessibility related and in every case user wins.
ACTION ITEM: WAI WG needs to define what these requirements are for that
profile and point to example implementations
ACTION ITEM: Create example (reference) style sheets (for both WAI/CSS
wg's).
ACTION ITEM: Mark Hakkinnen will send the pwWebspeak pre-css specification
to Chris Lilley
ISSUE (Chuck O.): Raised concern about support authoring tools for CSS.
(Hakon indicated that HotDog and several commercially available authoring tools
do)
- Aural extensions
- Font support (based on new CSS Font Draft)
- List of fonts can be given, but requires that fonts be available on the
client side system.
- Specification allows you to specify the properties of the font
- Font synthesis
- Download a font at client request time because author made it available
- Why do this?
- Internationalization
- BLISS symbolics
- Positioning
- Hakon Lie described positioning. Screen readers will see the text version
in an ordered form.
- ISSUE: Need to agree on definition of screen readers verses self-voicing,
speech interfaces
- COMMENT (Steve Z.): Replace the table with semantic markup
- Float can only be positioned left or right, not Top or Bottom.
- Working draft proposal: Positioning HTML elements with CSS - absolute
positioning. Two kinds of positioning:
- Absolute positioning
- Relative position: Position element relative to position in the flow
- Concerns around positioning of images that are changing verses dynamic
markup (visual styles).
- ACTION ITEM: WAI guidelines need to reflect good design criteria.
Note: During the morning session Jaap argued the following:
"This meeting is busy in finding solutions while the problems
are not clear yet. I propose to spend time in finding out the
problems first".
During the afternoon session Jaap highlighted that:
"We - the visually impaired - should have access to INTERNET
in the future and not only to blind-friendly sites'.
Other Technical Work
HTTP content/feature negotiation (Daniel Dardailler)
Explained HTTP request protocol. Is it a good idea to have some information
regarding the level of accessibility of the document that a person requests.
ISSUES DISCUSSED:
- Person with disability does not want the server to know that he/she has a
disability.
- Chuck: Rephrase the problem. Instead of being "deaf", use "eyes-free",
"hands-free", "roaming"
- Jim F. - Agrees with Chuck.
- Hakon - Privacy issues concern him.
- Murray - Not the case that the server "has to know"
- ISSUE: Browsers today don't allow you to set the http: "accept"
call
- Mike: Issues may be around requirments; what are they
- Daniel: Can we come up with an HTTP requirement(s) statement or document?
- Chuck: Does HTTP accept screen resolution requests? Think of things as
machine capabilities, not just people capabilities
- Hakon: CSS print extensions - possible to add braille as an extension.
Point is that these are client side capabilities
- Murray: We need to articulate requirments to Jim Gettys and HTTP WG.
- ACTION ITEM: Need to gather requirements from WAI WG and send to WG
listserv for comments. Then submit to Jim Gettys and HTTP WG
DOM/API work (Lauren Wood)
- Codify and extend platform-independent scripts. Available as a script in
document or as an api, dll, etc..etc..
- Arnaud and Steve: Dyanmic HTML and DOM scripting may present several
accessibility problems.
- Chuck and Will: DOM allows access to a richer set of information and is
good thing. Making static descriptions accessible.
- Print constraints: Only "snapshot" type opportunities. Could be
positioning requirments that need to be considered.
- ACTION ITEM: Lauren (as DOM chair) requests that WAI WG read DOM
specification and send accessibility requirements to Lauren
- ACTION ITEM: (Proposed by Arnaud) Track trends and usage of DOM and send
comments to Lauren.
Math Support (Dave and Daniel)
- W3C WG has a math specification
- ACTION ITEM: Dave Raggett recommends that WAI WG review and check for
accessibility. Specification is on W3C server. Is also XML specification.
- One goal is to provide easy math; to allow description of math intent.
- Murray: SGML ISO1283 =: Bertrand Melese did a math presentation at the SGML
conference and Murray encouraged Bertran to look at HTML specificiation to
determine whether a comparable solution existed.
- Chuck: University of Purdue and Oregon folks working on Math and should be
notified about this
- Daniel will help "synthesize" the work of Bertran, W3C.
- Arnaud: Work to make Amaya support ACSS/XML support for a speech based
interface that will "view" math.
Certification/Rating (Daniel Dardailler)
- Demo of PICS using prototype rating systems
- Daniel gave description via his PICS slides.
- ACTION ITEM: WAI WG will have to work on certification definitions and
guidelines
- Labeling process (No notes)
Final Questions and Comments (Daniel Dardailler)
- Jaap indicated that he didn't get much out of today; no action items to
report. What is the process for the future?
- Daniel replied by saying that the future process will include mailing lists
and conference calls with weekly meetings. W3C working group process starting.
Once IPO director is hired, then the WAI will be organized and things will work
better.
- Steve Zilles requested that the WAI WG needs to attach people to write
working drafts and assign people to work on them.
- Chuck asked whether the W3C will develop a reference browser? Is this the
purpose of Amaya?
- Daniel replied by saying that the Amaya development group is focusing on
specific working draft specifications to support. Unclear whether they can do
this. But a reference browser cannot by virtue of member opposition to it, but
we can have test bed.
- Chuck asked if any WAI WG members would be interested in serving as beta
testers for Front Page. Murray Maloney, George Kerscher, Peter Bosher, Jaap Van
Lelieveld, and Mike Paciello all volunteered.
- Everyone commended Daniel for chairing a good and productive meeting