WAI Technical Meeting

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:
1. labelled fields
2. related fields with captions (field_set element)
3. 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.
1. To attach multiple levels of description to elements (table, image, sound).
  - long and short
  - use and content
  - language
2. Urgency
3. 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
4. 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?
  1. Internationalization
  2. 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:
  1. Absolute positioning
  2. 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