UA Face-To-Face Meeting in PeterBorough, UK

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)