Minutes of WAI face-to-face meetinsgs

24/25 July 1998 - RNIB Peterborough

Participants

Judy Brewer <jbrewer@w3.org> (chair)
Daniel Dardailler <danield@w3.org> (co-chair)
Chuck Letourneau <cpl@starlingweb.com>
Wendy Chisholm <chisholm@trace.wisc.edu>
Steve Tyler <styler@rnib.org.uk>
Tara Bennett <tbennett@rnib.org.uk>
Aaron Leventhal <aaronl@rdcbraille.com>
Greg Rosenberg <greg@itis.com>
Michael Pieper <michael.pieper@gmd.dey>
Mike Townsend <miketownsend@compuserve.com>
Peter Bosher <peter@soundlinks.com>
Iain Millns <i.millns@bradford.ac.uk>
Paul Booth <paul@disinhe.ac.uk>
Tom Whittle <twhittle@rnib.org.uk>
Steve Plumpton <steveplumpton@pop.enterprise.net>
Stephen Phippen <sphippen@rnib.org.uk>
SHEELA SETHURAMAN <ssethuraman@cast.org>
Leonard Kasday <kasday@acm.org>
Brian Kelly <b.kelly@ukoln.ac.uk>
Michael Busboom <MBusboom@csi.com>
Alistair Edwards <alistair@minster.york.ac.uk>
Dominic Labbé <DominicL@visuaide.com>
Dave Pawson <dpawson@rnib.org.uk>
Gerhard Weber <gweber@fh-harz.de>
Masafumi NAKANE <max@w3.org>
Helen Petrie <h.l.petrie@herts.ac.uk>
Tom Wesley <t.a.b.wesley@bradford.ac.uk>
Chetz Colwell <c.g.colwell@herts.ac.uk>
Simon Sarmiento <sarmientos@logica.com>
Kitch Barnicle <kitch@afb.org>
Al Gilman <asgilman@access.digex.net>
Kevin Carey <humanity@atlas.co.uk>
Peter Croasdale <peter.croasdale@bbc.co.uk>
Chuck Oppermann <chuckop@microsoft.com>
Dominique Burger <dominique.burger@snv.jussieu.fr>
Stella O'Brien <smo-brien@lioness.demon.co.uk>
Dominique Archambault <archambault@iut.univ-lehavre.fr>
Hiroshi Kawamuru <hkawa@ibm.net>
Karen Spencer and Neil Morris (from People First)
Dave Raggett <dsr@w3.org> (scribe)

Friday 24 July

9:15 Introductions (unrecorded)
Judy still in transit arriving from Boston.

9:25 Daniel explains W3C mission and how work is organized (for more information see the w3c website at www.w3.org )

Questions:

Is the scalable vector graphics activity going to deal with 3D? Answer: no.

9:39 Al Gilman describing Protcols and Formats (PF) Group

Initially worked with HTML WG on accessibility review of the HTML 4.0 specification. Current work in sub-group chaired by Jason White on style sheet support for Braille. Also reviewing the document object model specification defined by the DOM working group. This provides a programmatic way to access and manipulate the document markup hierarchy and associated style properties. The PF group plans to look at XML and the future work on HTML and hopes to

9:47 Chuck Letourneau on Page Authoring Guidelines (PA) Group

A lot of recent activity, prioritising and scoping the groups work. A preliminary new draft is available now, but there is a lot of work left to do before this is made public. We expect to make major changes taking into account feedback received on the April 14th draft that will make the new draft much more effective and easier to apply.

Daniel explains W3C process. A working group creates one or more working drafts, which can be internal or public. After a series of revisions this may become a Proposed Recommendation which is sent out for review by the entire W3C membership. If accepted, this leads to a W3C Recommendation which is W3C's equivalent of a standard.

Questions on the scope of the review/vote on proposed recommendations, and on the option for making a working draft public.

Chuck explains that the guidelines target old browsers as well as new. (i.e. Legacy accessibility issues are included)

10:03 Kitch Barnicle on User Agent Guidelines (UA) Group

The guidelines present features browsers are expected to support to be accessible, e.g. to be able to set the font size and color, to be able to override the author's style sheet, to avoid the need to use a mouse or pointing device, via keyboard short cuts etc. The group was formed in January and the 1st draft released in June. Revising our procedures to fit better with other WAI groups. Short term goals is to get input from this workshop, and to start looking ahead to understanding emerging technologies coming down the road, e.g. for XML and SMIL.

What is the next deadline? Answer: perhaps October 1st.

Have you given any thoughts as to legal implications for guidelines, e.g. copyright issues? Machine readable information looks like the way to go.

This is something to discuss in the interest groups.

10:14 Daniel Dardailler on Authoring Tools Guidelines

2 aspects - 1st is helping people to write tools that produce accessible documents, 2nd is ensuring that such tools are themselves accessible. We have only tackled the 1st for now. We are reorganizing how we want to present the guidelines to make them really effective and easy to understand. Daniel gave a quick overview of the current draft. We expect to make a public working draft by September.

Question: We would like to have pointers to which authoring tools are accessible.

Al: W3C isn't really able to provide product critiques, you can find this information elsewhere though.

10:30 break

11:04 Len Kasday on the Evaluation and Repair Group (ER)

Deals with tools to help evaluate how accessible a site/page is and to offer support in fixing problems. Our focus is on standalone tools, either run locally or as services invoked over the Web, e.g. Bobby. Tools can't do everthing, human judgement is needed to check that alt text is appropriate to a specific image. However we can make it easier for people to apply such judgements e.g. by showing each image together with the current alt text and a simple means to revise it.

The charter was approved about a month ago, and the call for participation is out. Daniel Dardailler will chair the working group, Len will chair the interest group. Daniel has a student working on compiling information about current tools. We have posted a list of about 20 such tools. For some tools we need to find resources to maintain and update them where such resources are not already available. We want to deliver a toolkit.

Question: Is the list of tools public. Answer: yes. The only private WAI pages are those for the Protocols and Formats Group which needs to review unpublished work of other W3C groups.

11:15 Daniel standing in for Judy on Education and Outreach (EO)

First meeting was at the WWW'7 conference in Brisbane, followed by a number of phone conferences. We seek to reach the content provider to ensure they know why/how to create accessible content. The technical press is the most influential, followed by Web site design consultancies. We have to reach these folks. We are aiming to reach people attending a broader range of Web related conferences. We are trying to maintain a list of events in this regard.

This group started as an interest group, but Judy realized that the list of deliverables was so large that we needed a working group. We hope to provide a business case for why accessibility is worth providing. The group is still working on clarifying its priorities among the huge list of deliverables. We have funding for a European specific part and for a US specific part.

Question: To what extent is this group trying to target government and funding bodies in Europe and the US?

The RNIB is trying to do this in the UK, but needs help from the W3C/WAI, particularly for coordination with similar efforts in the north america.

Chuck Letourneau reported on contacts in Canada. The Canadian goverment has been very supportive.

Ben Holruth (Dundee) - his work.

Steve: 17th November - meeting the national grid for ??? would like to invite any one interested in accessibility lobbying.

Daniel: should this group be lobbying goverments on providing materials in accessible form.

Chuck O: In US there are legal mandates for government bodies to provide accessible materials. Tend to stick with text as lowest common denominator. Yes this is an area this group should work on.

Al: We don't want independent vigilante action outside this group.

Rnib ??: Setting up a series of meetings to ensure that accessibility is in all of their (DTI) publications.

Dick Banks has volunteered to help (what?).

Daniel: explains role of W3C offices around the world for translating of press anouncements etc. W3C marketing and outreach. Judy has organized a series of symposia in the UK at RAL last year, this year at CWI, and at GMD, Stockholm. This should help with education and outreach.

11:40 Daniel on the WAI coordination group.

We have sent out the call for participation. This will coordinate the various WAI working groups and interest groups.

The WAI Interest Group has some 400 people. It is used to start discussions before moving appropriate things to specific working groups. The archive is public, so you can look back at what has been discussed in the past.

Some issues the IG could discuss? e.g. legal/copyright questions.

The Education and Outreach will prepare a policy guidelines report, including the list of applicable laws.

Does it make sense to have a central clearing house for pointers to things?

Daniel mentions Josef Reagle's work in policy issues, IPR has been on W3C back burner for quite a while.

Judy arrives from Gatwick.

Tom (Bradford) - Copyright is a real difficult problem that is particularly critical for accessibility. If documents are not distributed in electronic form their accessibility is severely limited. Most books are not on the Web today. Publishers perceive the Internet as a gigantic copying machine.

E-commerce is a driver. The use of encryption and associated statements of licence terms for the content. Sentinel project setting up pilots including the RNIB. Taking books converting them into electronic form and distributing them encrypted in an accessible form. Interoperability of ECMS systems. European project "Imprimatur" addressing this.

From the back: there is some urgency in this issue. Several companies are working on making electronic books available and we need to ensure that accessibility is addressed.

Steve: The Rocket book and 3 others I know about. Some issues about accessibility.

Ken: If I wanted to make books available on the Web, I would use images rather than text.

Springer are making libraries available over the Web. using PDF or HTML.

(PDF is known to cause accessibility problems)

Mike Busbone: Program by Library of Congress investigating making their entire works available over the Web as Braille.

Judy does anyone know how they handled the IPR issues?

Answer: they have been doing this for some time for other media.

Chuck O. The US has voided copyright issue for blind people.

Judy: Is there any specific action item on the copyright issue?

Judy described the luncheon with the Duke of York on Wednesday in Boston (some 200 folks from Industry). We were able to get some outreach on the accessibility issue.

Dave Pawes: Suggestion that copyright is taken up by the IG. Brian: People in European projects would like to follow open standards but there aren't any appropriate for rights management etc. This is something the Technology and Society domain should pick up.

Judy: We do have some standardization activity. Rudy Ries is tracking work at ISO.

Interoperability of ECMS is relevant to this group since we have specific requirements we need ECMS to address. Judy suggests Tom talk with Josef Reagle on the copyright issue. Tom wants to follow up the copyright issue on the WAI IG list.

Len: should WAI get involved in legal stuff.

Judy: says more than one Federal body has contacted W3C. They think its real easy, just give us the guidelines to point to to fulfill certain expectations.

Greg Rosenberg: Wheres the line between legal and technology issues? We have to avoid create legal problems. We can perhaps talk to some lawyers on a pro bono basis. I know some I could approach.

13:21 Evaluation and Repair - chaired by Len Kasday

Len started by summarising how he was going to go thru the area.

Question: who has been working on getting feedback from users or on tools

Kitch: My doctoral work is on how to include people with disabilities in usability studies, e.g. computer applications with menus, radio buttons, checkboxes, etc. How do you pick which tasks to do? How do provide instructions? I log the studies with video. The approach is applicable to browsers. I have been using Microsoft Word and the Netscape browser as the applications and speech synthesis for users who are completely blind.

Q: Do you presuppose user familiarity with these programs. A: They have to had experience with Windows for at least 6 months.

I chose not to focus on web page design. Users have to follow links within simple text.

Len asked again how many people have things to report: ans: 4 organizations.

Len says we need to evaluate the efficacy of tools for people who are representative users.

Wendy (Trace): Subcontracting out work to develop tools, e.g. WGBH for a multimedia captioning tools. Some money to Bobby for providing a repair capability. Some others.

Some playing, e.g. with JavaScript to navigate tables.

Federal Web consortium (Al Gilman reports) may be generating some data we can use.

Len asks: how are they collecting information. Al: they are still at an early stage.

Q: What is the "Sorcerers Apprentice" here?

A: a dream tool to help get people to use their judgement to make pages more accessible.

Judy: Some work by Trace and some by people in their spare time, e.g. lovely little proxy converters.

Daniel's student has developed an HTML form that asks you for a URL for a page you think is unaccessible, and a email address to send the report to mail the comments to. It logs the submissions for later analysis. There are some questions coming out of this that should be handled by the IG.

Dave Pawson: Is there anything that can be learned about tables that can be forwarded to the next generation of HTML, to fix the problems we see today with tables.

Daniel: we have already put features into HTML 4.0 to help with making tables accessible, but these are not yet being used much.

Chuck L: there aren't yet the tools to create tables with the 4.0 accessibility features

Tom Wesley: I don't think there hasn't been much work on studying how blind people can access complex tables.

Len asks do we know of any such work.

Al: Scott Lubking did some work in this area.

Peter: IBM screen reader reports the row/col info. Perhaps they based this upon studies.

Rich: Have been using Java api for accessing tables. There is so much information, its tough to think about how to present it. We have trying out a way of layering tables.

Len: I am hearing that there is some studies that need to be done to better understand the right way to present tables.

Michael: Please look at Santa Clara web proceedings. I supervised a masters thesis which covers sequentializing tables. The student may have implemented this, and certainly has conceptualized this. ICCHP conference will have the final paper on the Web adaptor developed by the student.

Dave P: we need to find out how to fix the DTD.

Tom: tables are primarily visual. We now need to understand whether the features in 4.0 are effective, but we aren't there yet.

?: Is the 4.0 approach sufficient? Also the IBM Japanese approach allows you to get different levels of info explaining each table cell's role.

It transforms the table into an alternative structure, bringing each cell to a separate page.

Dave R: on problems for authors in using 4.0 table accessibility features, alternative using say spreadsheet and transformation tools suited to visual and aural uses.

?: should work back from user studies on how to make tabular information effective.

Len: summarises we have a work item then. Calls for volunteers to work on tables.

Dave P: Can I suggest a deliverable? A DTD for an accessable table.

Len: So the IG would run some experiments to determine what the transformed, accessable table should look like. The charter for the ER group includes this within its scope.

?: Braille offers some spatial cues unlike say aural rendering. This suggests different approaches will be appropriate.

Len: yes.

Len: any tools we come up with should be paralleled by guidelines for the authoring tools to ensure that the requisite data is entered by the authors.

Sheila/CAST: I am not actively working on Bobby myself. We are bringing more accessibility features into Bobby. 3.0 is coming out in a couple of weeks time. We are trying to keep up with the WAI guidelines. Version 3.0 uses HTML 3.2 as a default. We are looking for additional funding to further improve Bobby. We are getting a phenomenal amount of feedback on Bobby, e.g. the request for a site-wide accessibility report and a ball park estimate of how work will be needed to fix problems as a means to prioritise work. Bobby has been rewritten using Java foundation classes to make it an accessible application.

Brian Kelly: can Bobby be mirrored? If so what about the risks of getting versions out of step. Also will Bobby provide o/p in a machine understandable format rather than HTML. (Yes)

Judy: Do you have a list of issues. It would be very valuable to pull out all of the interesting issues you have come across in developing Bobby. Some of the hard calls you had to make.

Len: do users really want the simple evaluation result (the number of bobbies you get).

Judy: we have to be sensitive. We have to be careful that the rating matches the guidelines and to avoid a backlash "your guidelines are really terrible".

Sheila: we would be happy to share some of the issues with the group.

Helen: its not clear what accessible guidelines are being used by the RNIB validator. My site failed the RNIB, but we were pretty certain our site is accessible. The criteria used should be made public.

Dave P: we disagree with the Bobby rating. Our (RNIB) validator is for average users not, the intelligent experienced user. I will see what we can do to provide detailed explanations where problems are found by our validator.

Judy: The Trace site got a poor Bobby rating which caused a lot of confusion, given the huge amount of work they do on accessibility.

XML filter for Bobby.

Helen: We are working on methodologies for evaluating how people use computer based tools, as a means for evaluating the interface these tools provide. We are currently looking at different ways you might present hypertext links, e.g. speaking the word "link" before the link, the rattling of a chain, a barking dog, a typewriter-like bell. The users liked the latter. Best 130mS duration.

Judy: How much cultural diversity you had in your users?

Ans: Birmingham

Once users had heard the same cue many thousands of times perhaps users will want a change?

Helen: we are interested in changing the text charactistics and providing a background sound that is played for the duration of the caption.

Self-evaluation test for sites already in existence. The reliability across different people is poor. Automatic evaluation can only do half the job, but we have seen that human evaluation also has short comings. We have also compared Bobby with the results of human experts. The results seem to suggest Bobby isn't giving enough insights as to why it is giving particular results. (this may have been fixed in later versions of Bobby)

Finally, we have been evaluating the page authoring guidelines. We will talk about this tomorrow.

Brian Kelly: We have a project to develop robot software to understand how many sites are using java and style sheets, the number of images, links etc. We intend to make the s/w freely available, but we don't want to provide feedback to communities we are not strongly hooked into.

Judy: is interested in the tools to make a stab about how accessible the web is right now. This is a common question from Journalists.

Brian: talk to James Pitkow about the W3C Web characterisation work. Perhaps accessibility measures could be characterised too?

GMD: There are a lot of guidelines not just accessibility guidelines. We need a structured toolbox to help us with this. (ISO 9021 software evaluator)

Len: We need to follow up on tools and methodologies for evaluate sites. We need to understand the pros and cons of different ways to present tables in an accessable way. It would be useful if tools can output their results in a machine understandable manner. How the tools differ. The reliability and verifiability.

issues - should a tool give a pass/fail or other kind of aggregate accessibility rating.


At that point, 2 groups in parallel on PF and EO.

Saturday 25 July

Chuck and Wendy chairing GL working group meeting.
Starting with presentation from Helen.

9:14: Chuck Letourneau on Page Authorng Guidelines WG

Good Morning Folks!!

New guidelines draft uses 3 column table format: Guideline, Rationale, and Techniques.

Helen Petrie and Chetz Colwell

Report on evaluation of the draft page authoring guidelines:

We started on the 10th Feb then moved onto the 14th April. Last week it changed again. I will therefore report on the methodology we used.

Helen has looked at novice authors, Chetz has looked at more experienced authors. Helen has used her HCI students as guinea pigs. I gave them 3 websites per group. I will put the evaluation form we used as a summary on our website next week. During the evaluation, the students used a collection form, then filling the summary form in at the end.

My thanks to the students who all filled in all the forms!

I was trying to find which guideline was used the most. We would like to rank the most important guidelines based upon their applicability in practice.

We hardly evaluated the audio and video sections of the guidelines. For one thing we discovered that the sound cards had been disabled!

For each guideline I looked at what % of students said they had enough information and had no difficulty in applying them. One guideline got 100% - the one about providing a phone number or fax number. The other the one about avoiding blinking text.

I was surprised by the questions from the students about smileys and ascii art. (Just what is and what isn't ascii art.) This shows we need to provide examples to make the concepts clear especially to people

One guideline only got 21% - the one about tables. Only one in five students understood this. Most guidelines scored around 70%, so there is room for improving the text describing the guidelines. Of course this was for the old draft and the situation may have improved in the latest version.

One issue was explaining why its important not to violate nesting of tags. In general we need to be careful not to assume too much knowledge of HTML or to put people off by requiring them to learn HTML before they can apply the guidelines.

We didn't examine how reliable people were.

Q: how well did they do for guidelines that required human (subjective) judgement?

A: Quite well.

Q: Judy asks I would like to do this with professional website designers.

A: Chetz has looked at experienced web authors.

Chetz looked at the 14th April draft for her pilot study. I didn't attempt to cover all of the guidelines. I gave the subjects a rich html file. I asked people to think aloud about what they are doing, what problems they are finding etc. How did they decide how long the alt text should be. How easy they found it to find the appropriate guideline etc.

The results. My subjects have a vague idea about accessibility and learned about this from the guidelines, but wanted more. Specifically, they would like examples, especially across a variety of browsers. They needed more information as to why accessibility is important, e.g. how many people had particular disabilities.

The process of uploading a file proved tricky and needed more explanation. One subject tried hard to implement the guideline for providing access keys, only to find that the browser didn't support them.

In the main study, we will apply the same methodology to professional web page designers, not students. I used students who were experienced with HTML for the pilot.

Tables, long description and access keys presented problems since these aren't fully supported by current browsers.

How do you show people what the web page will look like on different browsers. Peter Bosner suggested the idea of moving a piece of paper with a hole in it down screeen to show people what its like for browsing with a speech synthesizer.

We need good/bad examples to motivate authors.

Michael: did people feel the visual appearance was compromised by complying with the guidelines. Answer: in my sample we asked this, and found this wasn't the case.

We would like to collect information by asking people what authoring tools they use, and how experienced they are. We ideally would collect this via a form and use the results to configure the version of the guide appropriately to they level of experience and the authoring tools they use.

(The notion of a Sorcerer's Apprentice).

Chuck: we will work on providing good/bad examples for the guidelines and for inclusive/exclusive definitions of concepts such as ascii art.

Tom: asks for this work to be continued. Nods all round.

Chuck explains the new guidelines. Wendy takes over ...

We have reduced the number of guidelines substatially. We have separated guidelines from techniques. We need to stablize and ensure the guidelines can be long lasting.

We have ordered both the guidelines and the techniques by priority. We have a problem in dealing with legacy issues - some features are not yet widely supported by the installed browser base.

Some discussion about the wording in the techniques regarding OBJECT. Chuck Opperman suggests the guidelines may cause some confusion by appearing to recommend OBJECT when most authors will feel more comfortable with IMG.

Wendy asks for help in improving the text.

Judy proposes there should be a table of contents at the start to help people approaching the guidelines to set their expectations. Judy and Chuck agreed that easier/more motivating headings for each section would help.

Tom proposes a professional author of introductory books be brought in to help.

Process check - Steve hasn't got access to a Braille copy of the new draft. We decide to read one guideline at a time rather than to wait for copies to be printed (long document).

Chuck explains the technique draft isn't available today. Thats the one with the examples.

Sheila asks if the guidelines will be available in different forms? Judy responds: if we can provide something in really plain English, why should we work on some other form?

Peter(?) do we need different versions appropriate to different kinds of Web pages?

Judy reads aloud the 1st section of the new draft.

Perhaps the term "alternative text" is everyday English and we should use something else, e.g. "short description"

How about "label or short description" says Judy.

Len says we really need examples to clarify what we mean.

Chuck: but we don't need to put the html tags in though.

Helen says she likes the term "alternative" because it links to the rationale for the attribute name alt.

Jon (opera) asks for basing the choices by asking web designers directly.

General consensus is to leave the wording to a professional technical author and focus here on whether we have all of the guidelines.

Max talks about ease of translation to other languages.

Tom: comment about the use of graphics. Most people who will use the guidelines will be sighted and it would be very helpful to include graphics to get the message across. Of course we still need to make the guidelines accessible.

11:11 Chuck says he wants people to focus on whether particular guidelines are in the right grouping. Lets stick with the current structure.

Chetz asks whether the guideline on color fits into the first section?

Peter? asks whether the advice on color will be acceptable to designers, don't designers use subtle color differences to indicate mood?

Chuck talks about the abundance of material advising people on how to use color for Web pages that works across browsers.

Peter: Does the material safeguard you against color blindness problems?

Short discussion about use of CSS for controlling color.

Tom: the guidelines don't say anything about resource issues, whether things are practical or not.

Chuck O: talks about the costs of doing close captioning. Microsoft has as a result decided not to use video on their site.

Judy: Hopes the cost of captioning will come down as more of it is done. Better tools that allow people do it themselves. Captioning of audio is a number one priority.

Stella: the priority will depend on your remit. The cost can be controlled if you provide a text version of the page rather than captioning the audio.

Wendy reminds people of the Word plugin for captioning from WGBH nCam that will be available later this Summer.

Len wonders about the US message relay service. Judy says this wouldn't provide an effective solution.

Brief discussion about the longdesc and frame tag.

Chuck reads section B of the guidelines.

Len is troubled with the wording about when the majority of sight readers have advanced capabilities.

Michael suggests "vast majority" but then retracts it.

Some suggestions about making the section's purpose clearer.

B.4 -- speech synthesisers also need the language.

B.3 -- Chuck says to change the text re BLINK and MARQUEE to explain they are bad because of the time-changing nature of their presentation not because they are proprietary.

Brian says we need to be practical about advising people to use style sheets due to buggy and non-interoperable implementations of style sheets in widely used browsers.

Judy says W3C has done work on core style sheets that work across 4.0 browsers. We could point to this from the guidelines.

Chuck reads section C.

Gerhardt: asks about Lynx, Al responds.

The use of "new technology" is confusing. If you mean new tags and style properties then say so.

"fail gracefully" may not be clear to non-technical folks.

Chuck reads section D.

Dave P: this section is crying out for an example of metadata.

Question about auto-pc. Chuck O. explains this is a Microsoft brand name windows CE.

Tom says the meaningful caption text for links is essential and should be elevated from priority 3. General agreement.

Daniel questions whether structuring table rows is meta-information.

Chuck O: wonders about how browser is supposed to support longdesc on frame tag.

Section E:

Chuck O: wants accessible applets to be raised to priority one not two as it stands. Also challenges priority one status for validating your pages for compliance to W3C DTDs. Its not that critical for accessibility.

Some discussion about E.3 which is not widely understood.

Dave Raggett added in discussion with Chuck after the meeting broke for lunch that there is a missing guideline - use tags not styles to add structural information, in particular don't use styles alone to indicate headings by setting a large font size.

Afternoon

13:09 Kitch Barnicle on User Agent Guidelines WG

UA WG Charter. We have been getting up to speed and in line with W3C procedures.

Kitch read out the charter.

What should the scope of the WG be?

Should the guidelines be general enough to apply to any user agent or should we provide more detailed guidelines for specific classes of user agents.

Len: would like the guidelines to address the case where the user agent is accessed via an API (e.g. DOM).

Kitch: We are going to hear more about SMIL later. Any thoughts about guidelines for browser plugins?

Al: comments about guidelines that covers HTML in SMIL.

Kitch: should we work on guidelines for say cell-phone based browsers.

Judy mentions her plans for W3C technical writer Ian Jacobs to look at the guidelines documents when he returns from vacation. Any work on mobile devices should be coordinated with the W3C Mobile Interest Group.

Chuck Opperman: Microsoft values the guidance but we think the working group needs to finish the current draft before widening to other types of user agents.

Kitch asks people to think about the scope and raise it in teleconference or mailing list.

Steve thinks mobile, and personal communicators etc. are of high interest and we shouldn't lose track of the potential to provide guidelines for this.

Brian Kelly mentions the inclusion of data within image files and the possibility of guidelines for how to get at this from user agents.

Chuck repeats that any device that renders HTML falls within the scope of the group. But lets get the current work done first.

Feedback that the draft is organized in a way that makes it hard to understand. Chuck O. says he much prefers the current linear format as compared with the table format used for the latest page authoring guidelines.

Kitch hopes to get to a Proposed Rec quickly. Judy explains that even when the working group has reached consensus, it will still take one month to get it out. It has to be reviewed by the WAI interest group amongst other things.

Kitch suggests September 15th for next working draft. Daniel proposes we aim to get the Recommendation by the end of the year.

Chuck O: proposes we get tighter involvment from the assistive technology developers to speed up work on the draft.

Kitch changes topic to how user agents should deal with tables. CSS2 is so big we may need to prioritize work.

She reads out the section of the draft dealing with tables and invites comments.

Len talks about tables with hierarchical headings. How does this effect the way browsers create a serialized view. Daniel talks through the ideas described in the HTML 4.0 spec as several levels, should we give these different priorities.

Al says accessible table rendering is still a research topic. We need to be careful to set people's expectations.

One way out is to use DOM to access the table. Brief talk about dependent and non-dependent user agents. Screen readers can only read what is on the screen, assistive technology can look at the markup.

Opera sees value in serializing the table to avoid horizontal scrolling when the document is zoomed.

Len says we need to think about other things that just screen readers, e.g. people who have set the font size real large.

Dave (RNIB) thinks the guidelines should stick to the requirements and avoid specifying solutions.

Kitch asks for people to volunteer to help review the table section of the draft. Peter offers his help, although he won't be able to join the teleconferences.

Chuck L reads email asking for a way in the markup to distinguish data tables from layout tables. Al says we did look into this for the HTML 4.0 spec, but decided that this was not a make or break issue.

Len points out an example of a bus timetable where it would be hard for users to workout for themselves which approach to use to serialize the table.

Demo of Opera

Break

SMIL presentation

15:16 Discussion of Issues on the issue list

Opera uses keys to allow users to drive the browser. This can interfere with the use of the HTML 4.0 access key attribute.

The access key can be combined with modifiers e.g. the alt key on Microsoft Windows platforms. Chuck says it would be good to allow users (not authors) to select the modifiers.

Wendy says the use of accesskey is priority 3 since we felt it didn't make a major contribution to accessibility.

Mark asks what guidance should we give when the access key clashes with a user agent defined key. Consistency with intranet applications. We should advise authors to be consistent.

Should we advise the user agent to underline the first letter in the element's text that matches the access key, for consistency with people's expectations based upon using menus in Windows?

Daniel talks about D-link. The author should use rel="dlink" when defining D-link. The user agent should provide a means to find D-link. Chuck O. asks why should Microsoft do this rather than just longdesc. Daniel explains that this is to allow authors to target legacy browsers.

Mark: perhaps the D links could be created by the server from longdesc based upon content negotiation (e.g. looking at the user agent field).

Len: the redundancy of longdesc and D-link is kind of like alts on image maps and separate text markup for navigation menus.

Chuck O: the number of people who implemented D-links is small, so it make sense to make the jump to longdesc now and forget D-link.

How should we present longdesc? The guidelines offers several ideas, presuming both D-link and longdesc.

Chuck explains his proposal: if images are turned off instead of the current icon, you would get a different icon with the alt text wrapped in + a "D" acting as a cue that longdesc is present. Right clicking or Shift F10 would bring up the context menu. The image becomes a tab stop when it has a longdesc.

Mark's implementation (Productivity Works) requires you to get to the image and then to drill down using a key. The image's alt text is read out and an aural cue is given to indicate the presence of the longdesc.

Discussion of issues relating to voice recognition for controlling browsers. Chuck described how the Dragon and the IBM voice s/w allow you to operate the browser. Mark talked about the features you want to expose to the user and perhaps bind to telephone keypad functions.

What do we want to say about the use of META and page refresh? Generally this is bad news for screen readers. Perhaps the user should be able to asked to intervene when the timer fires rather than having the page loaded without user interaction.

Chuck O suggests it could be handled via a pop-up dialog just like for moving from a secure to an unsecure page.

Opera: I would like to stick a link in the top of the original page so that the user can click on it. This would be appropriate if the autoloading feature is turned off.

OBJECT element. The content is used to provide an alternative and can include links. We would like to recommend how users identify a link to a longer description. One possibility is to use a PARAM element. Another is to use a hypertext link with a rel value.

Kitch asked Daniel to take ownership of the issue.

Discussion of issues relating to searching within a document. The ability to navigate via headers and/or links. How the user agent indicates matching text.

Daniel: In the compatability section 8 in the guidelines, its unclear what the baseline we expect browsers to support.

Judy asks if we should recommend user agents should implement all of HTML4. Dave says you can't do this without making it clear you are not talking about small systems. Chuck Opperman says you must also say why.

Len raised the issue of large text support. There are a number of things we need to look at for how this is supported.

Wrap up

Next meetings tentatively at Closing the Gap in October 98.
(need to fill in, I just wrote that - dd)