Minutes from UAWG telecon, 1 May 03
Attendance
dp David Poehlman
hb Harvey Bingham
ij Ian Jacobs
jg Jon Gunderson
mm Matt May
ss Sean Stapleford
Regrets: Jim Allan, Colin Koteles
Minutes
Reviews
jg: Added review for Konqueror
mm: Safari review is ongoing, waiting for feedback from Apple
mm: Review form changes to allow file upload and storage, ongoing
dp: Talked with Freedom Scientific on doing review, ongoing
jg: Opera review? Had problem with DOM access
ij: I believe they implement DOM now
jg: If we can summarize which tests have been implemented and also a view of the report for where a browser needs work, that would be helpful. Anyone interested?
ij: I thought we had that.
jg: It'll take some work to see what will be useful. It'd be nice to have a summary of which tests a browser hasn't fully implemented.
ij: Can do this using CSS. We should allow users to select these views.
jg: Could just add user style sheets for the time being.
:
Charter
ij: Jon, Judy, Matt and I discussed a new charter today. We'll be looking to recruit new members.
jg: Appears to be research into accessibility in pervasive computing devices. Interest among these people in working with WAI. I'd like to move into SVG and multimedia test suites. Will bring up issues in our current guidelines.
jg: I think it would be good to get these stakeholders together to a face-to-face. We should look at what kind of guidance these companies want, and what we can provide.
mm: One thing we can provide here is how to get vendors to agree on how to render content and take in input given the needs of accessibility and what the languages provide.
hb: Outreach issue?
jg: We already have interest in it. I think that it's good to try to get them working interoperably.
:
XHTML2 comments
dp: From what I've seen, what we've discussed seems to be on target.
jg: There's a lot of stuff here.
ij: We went over some of the comments in the f2f. Karl Dubost has taken some of our comments and added his own. So I'm thinking maybe we can get the comments of QA, UA and PF and give them as one. It may be too much for the HTML WG to handle.
jg: We'll want to pick our comments carefully. Wanted to see default behaviors and accessible behaviors as part of the spec. They wanted to have them but not as normative. Jason White has commented that he doesn't like our approach because it limits developers. I think they're important contributions.
jg: Would like a concept of a collection of related links. There is a concept of navigation bars. I think many pages have collections of links. Authors should be able to title and let users navigate to that collection of links.
ij: The nl element is supposed to do that.
jg: Current description of nl is pull-down menus. I don't think we want that to be the only or implied way to do that. Preferably through CSS, want to allow a static view.
ij: Should we ask the user agent for a particular way for links outside or within a page, or just any link, wherever it goes? Agree on the presentation of nl.
ss: Working within a page, I'd want to know whether the link goes somewhere on the same page, another page on the same site, or external.
ij: UAAG requires two of those three. Should we assume authors are going to group certain links? The more I think about it, the more I think it's not going to be useful.
jg: nl should be stylable?
ij: I think they shouldn't define presentation. Spec could go on to say "User agents must or should do the following:", and then subclasses (all graphical UAs). Where we think there's an appropriate UA behavior, we should try to get that in the spec. I think we should find ways to make UAAG requirements palatable.
mm: Author should be able to style as single-line select, multi-line select, or static list.
hb: So shouldn't set a default?
mm: Default helps to determine how the page is rendered.
ij: Should require in CSS the ability for users to override authors?
mm: Always.
jg: Add "Users should be able to move focus to first active element after nl"
ij: That's under user scenario 3.
jg: Users should be able to move between navigation lists.
ij: I don't know that we're going to be able to get 10 user agent requirements in. I think we should mark which ones must be done.
jg: A lot of issues related to content navigation. PF discussed conditional content for images. What did they come up with?
mm: Not resolved in PF. Question about src attribute, and how to add a sub-object that augments instead of replaces content.
jg: If <h1 src="foo"> points to an audio file, what does it do?
ij: It renders the first thing in the hierarchy.
jg: Can you have both a src and an href on this?
mm: Yes.
jg: If they both pointed to html, what would that do?
ij: It says that something selected with href is "activated when the element is actuated".
jg: How would text content work with src?
mm: Mimasa recommends XInclude for text, to flow in the document. With src, it would render as an attached object.
jg: I'm worried that XHTML 2 allows people to do things in many different ways. They could really do some strange things with XHTML 2.
mm: I think that href and src are just shorthand for a and object as they're used now. So I'm not as concerned about this causing inintended consequences as some other potential features.
ss: For audio example, you could play the audio file, a description, a transcript, or an option to download. If it were nested, a user's browser may be preset to give text version instead of playing it automatically.
jg: We look at HTML as a static thing, but multimedia is being incorporated into HTML. So RealAudio content would be done with SMIL, and some time synchronization could happen to allow sequential play.
ij: We spent some time while developing UAAG to determine where (user agent or AT) certain responsibilities are. We focused on the type of content the user agent offered. I don't think we'd get a proposal on making rendering requirements by the HTML WG.
jg: Consensus about conditional content? Matt, sounds like you don't have a real issue with src and href.
mm: Yes. It's just shorthand for the way people have been authoring current content.
ij: I kind of agree with Matt, but think some of the definitions (e.g., of src) need work.
ss: It sounds like right now it's not too bad. Backward compatibility is still a concern, with Lynx, etc.
ij: HTML WG has been pretty explicit in saying that XHTML 1.0 and 1.1 would be backward compatible, and 2.0 would not.
mm: XHTML 2 is not going to be catching on broadly for about 10 years after Rec, so the backward compatibility problem shouldn't be as large.
jg: I think there will be a lot of QA work as this goes on.
dp: I think this approach has potential. We should follow this and make sure accessibility is in the loop.
ACTION ij: Work on summary for XHTML 2 issues (15 May)