Raw minutes from 7 June 2001 UAWG teleconference

7 June 2001 UA Guidelines Teleconference

Agenda announcement:
 http://lists.w3.org/Archives/Public/w3c-wai-ua/2001AprJun/0245

Minutes of previous meeting 31 May:
 http://lists.w3.org/Archives/Public/w3c-wai-ua/2001AprJun/0230

Next meeting: 14 June

Present: Jon Gunderson (Chair), Ian Jacobs (scribe), Stephanie Potter
(RealNetworks), Erik Hodge (RealNetworks), Geoff Freed (WGBH), 
Harvey Bingham, Mary Beth Janes (Apple), Mickey Quenzer, 
David Poehlman, Cindy King (Gallaudet)

Regrets: Tim Lacy, Jim Allan, Eric Hansen, Gregory Rosmaita

Reference document 4 June 2001 Guidelines:
 http://www.w3.org/WAI/UA/WD-UAAG10-20010604/

----------------------
Discussion
----------------------

Issue 500: Checkpoint 4.6 positioning requirement.
  http://server.rehab.uiuc.edu/ua-issues/issues-linear-lc3.html#500

Accessibility requirements:
 * Move captions off of video (interference)
 * Move captions over video track (low vision)

CK: One reason to allow for overlapping is that the author has not
provided the captions; a third-party has provided the captions. One
example is television.

IJ: People have asked us why top/bottom/left/right is not sufficient.

CK: If you have a video with wording already on it (e.g., there are
alerts at the bottom of the screen), you can't always assume that the
caption will go in a particular location (where there might be
critical location).

GF: I think that Quicktime does this already.

/* Ian introduces the issue */

EH: I'd like to speak to the points about system-captions:

 * We're not making any plans to change our SMIL 1 behavior.
 * We're working on our SMIL 2 implementation. (There are some
   additional switches for subtitles.) The author places captions
   in a particular location. 

IJ: Is your concern override of author style or the reflow issue?

EH: The latter. Sometimes there are interdependencies. There is also
the ability within SMIL to move regions. The author can allow control
of regions (e.g., on keyboard events).

IJ: That's why we suggested that it would be possible to render the
captions in a separate viewport.

EH: Yes, that could be done.

IJ: The transparency part would be covered by control of foreground
and background colors (checkpoint 4.3, which is separate). 

EH: In the Windows environment, this can be done: allowing one
viewport to show through another.

MBJ: I'm mostly here to take questions back to our group.

EH: If the author doesn't specify that the captions are in a separate
viewport, does the UAAG requirement still apply? 

SP: Suppose the author creates a presentation with both video and
captions in the same viewport.

IJ: Our requirement still holds, and there are several implementation
options: same viewport, different viewport.

SP: It can get complicated if you pull, say, four different captions
out into four different viewports (e.g., in different languages or
multiple speakers, or a news presentation with one media window, one
window with a stock ticker).

IJ: But if the author can already specify that, why is it more
complicated?

SP: If it's allow only what the author can do, then that's less of a
problem.

IJ: Right, we don't require any more than what the author can do.

CK: Check out http://depts.gallaudet.edu/

/* IJ checks out this page, but it's almost empty... */

CK: Most of the time you want captions in a separate viewport. Authors
don't want their visual space left blank in cases where the users
don't want to view captions.

EH: Question: If you have captions below the video and the user
requests that the captions go in a separate viewport, would it go
against the spec if we left the text in place and created a separate
window? 

IJ: I think it would be ok if the first captions were not overlapping
with the video, and the user wanted to move the (second) captions to
overlap the video.

HB: The one they move around would be enlarged text. 

IJ: Why not allow two configurations:
 
 1) view in place
 2) view in separate viewport

IJ: Allow the user to toggle them independently. In short: the
tool already does what we want, but not always when we want it. We are
asking for configuration to do these things even when the author
hasn't said so.

MQ: A good reason to have captions in a separate viewport is to allow
users with screen access programs to zero in on specific information.

DP: Some users may find it confusing to have too many captions tracks
running simultaneously. Users may want to turn them on and off
independently.

GF: I was a little puzzled by the scenario where you have two captions
regions at once.

IJ: How important is transparency?

CK: Traditionally captions have a background. Having a black
background behind white lettering is preferred. We did some research a
few years back with deaf users. We did shadowing and other variations,
and, because of the video behind it, the users preferred a background.
I think transparency is an important option, but shouldn't be a
requirement.

EH: I think that whether you have a requirement for transparency or
not, our QA department would require it of us.

IJ: Our spec says:
 
  "Note: When captions overlap the synchronized visual track, the user
  should be able to view the visual track behind the captions."

IJ: I think we would need to be clearer that transparency should be a
configurable option.

/* Ian reads 4.6 of 4 June 2001 draft */

EH: Clarifying a: If the author can specify it, the user can?

IJ: Yes.

IJ: Is it reasonable to think of an implementation where the user can
change values in the DOM?

EH: The SMIL DOM will probably not be in the SMIL 2
Recommendation. We're interested in the SMIL DOM, however. We would
implement all DOM things in one effort. People want to read the DOM
data more than write values into the DOM.

/* Review of RN comments from 10 May */

RealNetworks:

  "3.2 Difficult to apply to a SMIL playback environment in a useful
  way.  Unlike HTML, *all* media (text included) is done as included
  media which the SMIL engine itself has little knowledge of.

IJ: Wouldn't the player simply not hand off the content to another
plug-in?

EH: The SMIL player would have to query the server for information
about the content type. At that point, it could choose not to play the
information. It's not as simple as it sounds.

EH: Would silent playing satisfy 3.2?

IJ: Yes. We've talked about that explicitly.

RealNetworks:

 "3.3 Seems mutually exclusive with 2.5.  May require changes to
 client-server protocol for RealText, seems very difficult for Live
 Text applications, and may not be possible in other settings."

IJ: We distinguish streaming content from animated presentation of
that content. E.g., movie subtitles are streamed but not animated.

EH: We use text as building blocks. But animation is about moving
glyphs. The problem with letting it be "still". E.g., a series of news
items that scroll up and constantly refresh.

IJ: We've already said you can drop packets.

EH: I'm ok with that.

EH: With a marquee, there's no concept of a line break.

EH: Would a source view be sufficient?

IJ: In my opinion, not ideal, but sufficient.

JG: Yes, I think that a source view would be sufficient. Casual users
may not realize that a source view would satisfy their needs. It seems
like there's an authoring issue here, as well.

JG: How much flexibility does the author have in breaking up the text
into chunks?

SP: Typically it will all be done in one request. Suppose you are
pulling content from a database.

EH: I think that streaming text format presentation should be done on
the client side.

IJ: Do you throw away received text content?

EH: There are configurations (loop=true) where we keep content. But in
general, we throw out content as soon as it's not visible any more.

MQ: But I may not have had time to read the text that's arriving.

IJ: In general, we say don't rely on the author's time specification.

DP: I'm not sure that real text can be used by a screen reader
anyway. In order for real text to work with screen readers, it would
have to be converted to something usable.

EH: You could create a realtext window that is 10k pixels high (for,
say, 1000 lines), and allow the user to scroll through it.

/* GF and EH are working on a new standard for streaming text */

GR: I've been coordinating this with the WAI PF WG. In fact, I think
it's on the agenda for the next WAI PF call.

Resolved:

 - Checkpoint 3.3 does not allow the user agent to drop packets in the
 case of streaming content. The user must have access to all the same
 content, but in non-animated and non-blinking form.

----------------------
Future plans
----------------------

JG: We expect to invite developers during Candidate Recommendation
to talk about 

Action IJ: Send IJ comments (to RN review) to stephp@real.com

-- 
Ian Jacobs (ij@w3.org)   http://www.w3.org/People/Jacobs
Tel:                     +1 831 457-2842
Cell:                    +1 917 450-8783

Received on Thursday, 7 June 2001 16:54:23 UTC