From laura.lee.carlson at gmail.com  Tue Oct 14 01:09:51 2008
From: laura.lee.carlson at gmail.com (Laura Carlson)
Date: Tue, 14 Oct 2008 03:09:51 -0500
Subject: [html4all] Fwd: Accessibility of <audio> and <video>
In-Reply-To: <Pine.LNX.4.62.0810132339510.1237@hixie.dreamhostps.com>
References: <fb6fbf560809091234y1916d4d3hf20fd6a402c238d0@mail.gmail.com>
	<FA9EC650-5408-48B6-99BC-5EF986B22DF5@iki.fi>
	<F8155422C4FF46F98115ABA65B216F67@HANDS>
	<52BD43ED-D76B-4FE5-A341-9FEFDDDCE419@iki.fi>
	<Pine.LNX.4.62.0810132339510.1237@hixie.dreamhostps.com>
Message-ID: <1c8dbcaa0810140109g5ad3f08q9368dc18939ec47d@mail.gmail.com>

For your information reply from the HTML 5 editor:
http://lists.w3.org/Archives/Public/public-html/2008Oct/0029.html
(also in forwarded text message below)

---------- Forwarded message ----------
From: Ian Hickson <ian at hixie.ch>
Date: Tue, 14 Oct 2008 00:55:57 +0000 (UTC)
Subject: Re: Accessibility of <audio> and <video>
To: HTML WG <public-html at w3.org>

This is a reply to about 100 e-mails on the topic of accessibility of
media elements in HTML. I have only explicitly quoted e-mails below when
they introduced new ideas; many of the e-mails merely re-emphasised points
made earlier in the debate.

Before I jump in to specific feedback, I would like to put forward the
vision that I had in mind when first designing the semantics and the API
for <video> and <audio>, with regard to accessibility.

Fundamentally, I consider <video> and <audio> to be simply windows onto
pre-existing content, much like <iframe>, but for media data instead of
for "pages" or document data. Just as with <iframe>s, the principle I had
in mind is that it should make sense for the user to take the content of
the element and view it independent of its hosting page. You should be
able to save the remote file locally and open it in a media player and you
should be able to write a new page with a different media player
interface, without losing any key aspect of the media. In particular, any
accessibility features must not be lost when doing this. For example, if
the video has subtitles or PiP hand language signing, or multiple audio
tracks, or a transcript, or lyrics, or metadata, _all_ of this data should
survive even if the video file is saved locally without the embedding
page.

It turns out that this is actually not a huge problem -- video formats
already have to deal with this. If you buy video from iTunes, all the
metadata is within the file. If you buy audio from Amazon, all the
metadata is within the file. If you transfer a video track from a DVD to a
hard disk, one MPEG file can contain all the subtitles, video, and audio
tracks. Furthermore, unlike images, videos tend to stand alone -- where an
image can mean different things in different contexts, video files tend to
mean the same thing in all contexts, so the accessibility alternatives
aren't situational like image alternative text.

Thus, a fundamental principle of how this feature was designed is that any
accessibility features and metadata features must be within the video or
audio resource, and not in the HTML markup. The hypothesis is that this
results in the optimal experience for all users.



On Mon, 25 Aug 2008, Justin James wrote:
>
> I have become very concerned over the last few weeks regarding the
> accessibility issues in HTML 5. I think that it is great that so many
> people are pushing hard for accessibility around images, which is of
> particular benefit for vision impaired users. However, I fear that
> another group of users is being ignored: hearing impaired users. I find
> it a bit strange that we are spending a huge amount of energy around the
> img/@alt issue, but no one has brought up something like @alt for the
> audio and video tags.
>
> I am of the opinion that in the spirit of fairness and equality, any
> decision made regarding @alt must also be applied, as appropriate, to
> image and video elements as well.
>
> The current draft, as I read it, does not support any type of
> @transcript or @alt type of attribute on either of these tags, making
> them both inaccessible to hearing impaired users, and video inaccessible
> to vision impaired users as well.

I hope that the above introduction now explains the reason for this. It's
not that hearing impaired users (and many other users with special needs)
are excluded, but that to best serve them we should address their needs in
the media resources themselves.


On Mon, 25 Aug 2008, Edward O'Connor wrote:
> >
> > I find it a bit strange that we are spending a huge amount of energy
> > around the img/@alt issue, but no one has brought up something like
> > @alt for the audio and video tags.
>
> This is because, for legacy reasons, <img> is an empty element, and so
> its text equivalent lives in an attribute, whereas <audio> and <video>
> both support rich fallback via their content.

This isn't the intent. The fallback is only intended for legacy UAs. I
would expect all HTML5 UAs, including ATs, to support <video> and <audio>,
exposing alternative tracks, subtitles, etc.


On Mon, 25 Aug 2008, Philip TAYLOR wrote:
> Anne van Kesteren wrote:
>
> > Actually, I think the idea is that the content stream itself is
> > accessible.
>
> That is not something that the HTML specification can (or should)
> mandate.

Indeed, we are somewhat at the mercy of whatever codec and container
formats we end up picking. We should definitely consider accessibility a
high priority when selecting a good codec, though. For example, we
shouldn't pick a codec that requires that subtitles be burnt in.


> > The contents of the <audio> and <video> element are a) for <source>
> > elements and b) for user agents not supporting <audio> and <video>.
>
> But if someone who were unable to hear audio, or see video, were to
> configure his/her browser so as not to render such streams, then such a
> configuration would surely be indistinguishable from "user agents not
> supporting <audio> and <video>", and thus the content would be rendered,
> would it not ?

Such users would presumably enable subtitles, or enable audio tracks for
the visually impaired, rather than disable the media altogether.


On Mon, 25 Aug 2008, Boris Zbarsky wrote:
>
> So if the UA doesn't support the particular codec but does support
> <video> it should not show the fallback content?

Correct.


On Mon, 25 Aug 2008, Boris Zbarsky wrote:
>
> That seems entirely unreasonable to me.  In particular, it doesn't let
> me, as an author, try for a higher-quality codec with fallback to a more
> commonly supported one.

That's what <source> is for. Since the idea is that we will have a codec
that is supported everywhere, that is what the final fallback would be.


On Mon, 25 Aug 2008, Boris Zbarsky wrote:
>
> Hmm.  OK.  So I can fall back to a different codec using multiple
> <source>s. I can't fall back to a video format that only has plug-in
> support, though?

If you wish to try providing video encoded using a non-ubiquitous codec
using <video>, and, if that fails, switch to a rendering using an NPAPI
plugin, you can use script -- however, that isn't expected to be a common
case (at least on the long term; it might be a common case in the
transition period where we don't have a uniform codec, but we shouldn't
optimise for that case).


On Mon, 25 Aug 2008, Philip TAYLOR wrote:
>
> Scenario : the Principal addresses the University and his address is
> recorded; his aide asks the webmaster to put the video up on the web.
> The webmaster looks at the video and finds there are no closed-captions,
> no subtitles, no accessibility features at all.  What is he to do ?
> Refuse to put it up.  That would be a brave webmaster indeed.  No,
> instead he puts it up, then relies on the intelligent design of HTML 5
> to allow him to add accessibility features to overcome the deficiencies
> of the raw material. And it is our responsibility to make sure that he
> can do this.

The idea is that he would put those accessibility features in the video
file itself, rather than just in the HTML. That way they don't get lost
when the user moves the file around (e.g. to use their accessibility-
optimised video player).


On Mon, 25 Aug 2008, Philip TAYLOR wrote:
>
> OK, that's a constructive suggestion.  But it also seems to be an
> attempt to hive off the responsibility for providing accessibility
> features on others (in this case, the designers of SMIL).  Why don't we
> just bite the bullet and make HTML 5 accessible, full stop ?

We should look at the Web platform as a whole as a single entity. HTML5 is
just one small part of that. Given that outlook, it doesn't really matter
which committee designs the accessibility features, so long as they are
there. What matters is what is the best technical solution for them. The
best technical solution here is to have the accessibility features as
closely associated with the moving pixels as possible, in the video file
itself.

One could equally ask the question "Why don't we just bite the bullet and
make HTML 5 define the entire video format". Features like subtitles are
no more or less important than features like the actual moving pixels of
the dog on the skateboard -- they are all part and parcel of what the
video is, and should be together.


On Mon, 1 Sep 2008, Justin James wrote:
>
> I can imagine the furor if we also applied this logic to images, by
> saying, "if you want accessible images, use a format that natively
> supports metadata of alternate text, or put a
> subtitle/caption/legend/etc. in your image." Heads would roll. On this
> other hand, I also agree that it is not HTML's responsibility to
> pre-determine every possible accessibility scenario for every possible
> type of content and account for it.

The big difference with images is that they are often situational (their
meaning changes based on where they are placed), which is much more rarely
the case with videos and audio tracks.

(Also, frankly, accessibility of images is a much less well-understood
problem than accessibility of audiovisual entertainment.)


> A middle ground that I would like to propose, would be for @alt to be
> allowed on any type of non-text element, as well as @longalt (or
> @longdesc), and a @longalturl attribute, which would allow for an URL to
> be given for a FULL textual representation. For example, with an image
> respresenting a math formula:
>
> <img src="formula.gif" alt="The Fibonacci Sequence" longalt="The
> Fibonacci Sequence expressed as a mathematical formula."
> longalturl="http://www.domain.com/fibonacci_text.html">
>
> Does this make sense? Would this meet the needs for providing
> accessibility metadata on non-img elements, while not getting in the way
> of providing multimedia content?

I think this is the wrong approach -- we shouldn't be emphasising the
separation between parts of the population, we should be working to unify
everyone. It's much better to have computers use the same input (e.g.
MathML for this example) and adapt the output to the user than to make
certain users be effectively "second class citizens" that have to be
treated specially.

Getting back to video and audio, transcripts and lyrics are a good example
of this. Instead of just providing transcripts to users who can't make
full use of the video or audio, it is better to provide them to everyone.
Many users who are otherwise quite capable of looking at video and audio
may desire transcripts.


On Mon, 1 Sep 2008, Lachlan Hunt wrote:
>
> OK, let's look at the various kind of alternatives that could be potentially
> provided for people who either can't watch or don't want to watch the video.
>
> * Transcript of spoken content.
> * Textual descriptions of relavant non-spoken content.
>   e.g. descriptions of significant actions or sounds in the video.
> * Still images illustrating significant moments from the video.
>   e.g. images of presentation slides, if the video was of someone giving
>   a presentation.
> * A link to download the video, possibly in alternative formats, to
>   watch in an external media player, perhaps in several formats.
> * Video embedded in the page using an alternative method
>   e.g. Flash, the Cortado Theora applet, or whatever
>
> Any or all of those could be provided and all of them would be suitable for
> people in the following categories:
>
> 1. People using browsers that don't support <video>
> 2. People using browsers that do support video, but don't support the
>    codecs used.
> 3. People who can't see the video well (blind or visually impaired)
> 4. People who can't hear the video well (hearing impared or no
>    headphones/speakers available)
> 5. People who want to search the content of the video
>    e.g. Instead of seeking through the video to find the information
>    they want, just look through the transcript, from which they can also
>    copy quotes if they want.
>
> Given that the alternative content is useful to so many people,
> regardless of physical disability or technological limitations, it makes
> sense for it to be provided in a way that makes it available to
> everyone.  This is one reason why hiding alternative content away within
> the video element is not helpful because it only makes it readily
> available to a small subset of those people who might want or need it.
>
> Another reason to consider is that we know very well what authors do
> when they are encouraged to hide alternative content specifically for
> accessibility within elements.  For example:
>
> <noframes>Your browser does not support frames, Please upgrade to
> Netscape 4</noframes>
>
> <noscript>Sorry, your browser doesn't support javascript.</noscript>
>
> <object ...>Please install flash</object>
>
> It might work ok for <video> during the transitional period when not all
> browsers implement it, since authors will gain practical benefits by
> including alternative embedding mechanisms within the video element.
> e.g.
>
> <video src="movie"><object data="movie"></object></video>
> <p><a href="movie">Download movie</a>
>    <a href="transcript">Read transcript</a> ...
>
> But, in the long term, after browsers with native video support are more
> widely used, we'll likely start seeing people leaving the video element
> empty or including useless messages, and accessibility loses.  Whereas
> by encouraging people to use visible alternative content, everybody
> wins.

Indeed.


On Tue, 2 Sep 2008, Leif Halvard Silli wrote:
>
> This has me asking: Why couldn't the poster image just be a regular
> <img> element, rather than an attribute?

It's not clear to me how it would work as an <img> element. An attribute
is simpler.


> So, take that poster image again. If instead of building the poster
> image into the <video> element, one cold design the <video> element so
> that one may use the <img> element in order to display a poster image,
> then there would be no problem with fallback for the poster image, as
> the <img> would provide that fallback.

Given that most poster frames are autogenerated, and thus don't have
useful alternative text, it's not clear to me what this gives us.


On Tue, 2 Sep 2008, Matthew Raymond wrote:
>
> Perhaps we can provide some attribute values for |rel| along these lines:
>
>  * "transcript"
>  * "slideshow"
>  * "download"
>
> We could then associate such content using the <figure> element:
>
> | <figure id="figVideo1">
> |   <video [...]> [...] </video>
> |   <legend>
> |     <a href="..." rel="transcript">
> |       Click here for a transcript.
> |     </a><br>
> |     <a href="..." rel="download">Download Quicktime version.</a><br>
> |     <a href="..." rel="download">Download Ogg Theora version.</a>
> |   </legend>
> | </figure>
>
> UAs could then be given the latitude to present this however they wish,
> while legacy UAs would just provide the fallback for the video plus a
> series of links. Plus, if UAs choose not to provide any special handling
> of the content, at the very least it's still accessible to everyone.

I encourage people to register these rel="" values in the wiki and to try
them. I am very interested in what experience with this teaches us. If it
turns out to be a good idea, it's definitely something we could add to the
spec.


On Tue, 2 Sep 2008, Smylers wrote:
>
> If people start wanting to use videos for logos, decoration, mere
> illustration, text replacement, as icons, or whatever then they would
> need <img>-like alt text -- and we'd have the same thing as with images,
> where a single image could serve different purposes (and as such require
> different alt text) on different pages.
>
> But there doesn't seem to be a desire for such use of videos -- they all
> seem to be in the category of being 'important content' on the page --
> so, as Lachlan suggests, alternative representations could be embedded
> in the video and still be appropriate.

Agreed.

(We can use animated GIFs and Flash as a surrogate for the demand here. I
don't think we see them used that much for those roles.)


> Each video's title, or other information which helps pick between them,
> obviously _could_ be included in the HTML next to the video.  But this
> may be of no benefit to sighted users.  Consider a page with videos of
> speeches, with the poster frames containing head-shots of different
> presidential candidates, each with a visible caption of their name and
> party: putting their this information additionaly on the page with HTML
> would be repeating it visually; that would be unnecessary for sighted
> viewers, and I'm not sure it's reasonable to insist that authors should
> include this duplication for accessibility reasons.
>
> I'd've thought it better that there's some way in which non-image
> alternative to the poster frame could be made available for speaking
> browsers.

This is true; in general, however, the title could be obtained from the
header of the video files, which would be more likely to be provided than
metadata in the page. I agree that this would become unwieldy in the face
of many videos, but I'm not sure an attribute would be better at that
point. I would encourage authors to use <figure> and <legend>, potentially
hiding the <legend> element from visual users.


On Wed, 3 Sep 2008, Smylers wrote:
>
> Ah.  I'd presumed that <video> is intended to cope with all desires for
> embedding videos in webpages; are there some situations in which <video>
> is inappropriate and a different HTML 5 element should be used?

I don't believe so. <video> is intended for all current uses of video on
the Web.


On Wed, 3 Sep 2008, Dave Singer wrote:
>
> We've actually been thinking about the framework for accessibility of
> media elements in HTML5.  Note that this is rather different from
> discussing (say) caption formats or the like.  I've attached a 'thought
> piece' on the subject, which attempts to lay out some of the needs as we
> see them, and also proposes a way ahead.
>
> http://lists.w3.org/Archives/Public/public-html/2008Sep/att-0118/html5-media-accedssibility.html

In general I agree with this document, though, for the reasons described
above, I do not agree with the conclusions regarding providing alt,
longdesc, or other fallback inside the HTML file itself.

How has work regarding media queries on this topic progressed?

Others argued that media queries weren't a suitable technology; should we
instead provide this information in an attribute or two? (It would be easy
to do so, provided we could decide on a set of axes. I am not qualified to
know what the right axes are, but given a set, and guidance on likely
extension directions, I would be happy to provide syntax for this.)


On Wed, 10 Sep 2008, Lachlan Hunt wrote:
>
> http://wiki.whatwg.org/wiki/Video_accessibility#Selection_Mechanisms

This is very useful, thanks.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

-- 
Laura L. Carlson


From joshue.oconnor at cfit.ie  Tue Oct 14 03:39:32 2008
From: joshue.oconnor at cfit.ie (Joshue O Connor)
Date: Tue, 14 Oct 2008 11:39:32 +0100
Subject: [html4all] Fwd: Accessibility of <audio> and <video>
In-Reply-To: <1c8dbcaa0810140109g5ad3f08q9368dc18939ec47d@mail.gmail.com>
References: <fb6fbf560809091234y1916d4d3hf20fd6a402c238d0@mail.gmail.com>	
	<FA9EC650-5408-48B6-99BC-5EF986B22DF5@iki.fi>	
	<F8155422C4FF46F98115ABA65B216F67@HANDS>	
	<52BD43ED-D76B-4FE5-A341-9FEFDDDCE419@iki.fi>	
	<Pine.LNX.4.62.0810132339510.1237@hixie.dreamhostps.com>
	<1c8dbcaa0810140109g5ad3f08q9368dc18939ec47d@mail.gmail.com>
Message-ID: <48F476E4.1050807@cfit.ie>

Hi Laura,

Thanks for that. After a first pass, I think I would agree with much of
Ians line of thinking.
I like the idea of the <video> and <audio> elements natively containing
all of the needed accessibility content (or more correctly multi modal
content) without the need to it to be bolted on via using other attributes.

Authoring environments that made use of this model and easily supported
an author who wished to create captions, or embed sign language and/or
other content along with a broad UA support and simple authoring
semantics would be great.

Cheers

Josh






From laura.lee.carlson at gmail.com  Tue Oct 14 10:24:32 2008
From: laura.lee.carlson at gmail.com (Laura Carlson)
Date: Tue, 14 Oct 2008 12:24:32 -0500
Subject: [html4all] Fwd: Accessibility of <audio> and <video>
In-Reply-To: <48F476E4.1050807@cfit.ie>
References: <fb6fbf560809091234y1916d4d3hf20fd6a402c238d0@mail.gmail.com>
	<FA9EC650-5408-48B6-99BC-5EF986B22DF5@iki.fi>
	<F8155422C4FF46F98115ABA65B216F67@HANDS>
	<52BD43ED-D76B-4FE5-A341-9FEFDDDCE419@iki.fi>
	<Pine.LNX.4.62.0810132339510.1237@hixie.dreamhostps.com>
	<1c8dbcaa0810140109g5ad3f08q9368dc18939ec47d@mail.gmail.com>
	<48F476E4.1050807@cfit.ie>
Message-ID: <1c8dbcaa0810141024v16356605pf341f63ac8aeedcf@mail.gmail.com>

Hi Josh,

> Thanks for that.

You're welcome.

> After a first pass, I think I would agree with much of
> Ians line of thinking.
> I like the idea of the <video> and <audio> elements natively containing
> all of the needed accessibility content (or more correctly multi modal
> content) without the need to it to be bolted on via using other attributes.

As Jim Jewett said [1] , something to keep in mind is that

> In an ideal world, the accessibility features would be in the video.
>
> In the real world, often they aren't.
>
> The page creator may not be able to modify the audio or video.
> Sometimes this is a matter of not having the video (embedded 3rd party
> videos) or not having legal authority; sometimes it is just a matter
> of not knowing how.
>
> By all means encourage authors to put the accessibility information
> within the video.  But there needs to be a fallback for cases where
> that doesn't happen.

John Foliot has talked of a clean, semantic, explicit association to
transcripts, text descriptions, captions, audio descriptions and/or
streams that could be toggled on or off by the end user. I have tried
to capture some of that in the Wiki. [2] He has also provided examples
that hint on some best practices that not only native players and but
HTML 5 as a whole could approach multi-media content.[3]

Best Regards,
Laura

[1] http://lists.w3.org/Archives/Public/public-html/2008Oct/0035.html
[2] http://esw.w3.org/topic/HTML/MultimediaAccessibilty#head-dc0ce4228a48f99201392137b5d2a809be400570
[3] http://esw.w3.org/topic/HTML/MultimediaAccessibilty#head-9dc3a1bce8ca03b38a207a12b27c25e2fcd47aeb

-- 
Laura L. Carlson


From laura.lee.carlson at gmail.com  Tue Oct 14 16:52:44 2008
From: laura.lee.carlson at gmail.com (Laura Carlson)
Date: Tue, 14 Oct 2008 18:52:44 -0500
Subject: [html4all] Accessibility of <audio> and <video>
In-Reply-To: <Pine.LNX.4.62.0810132339510.1237@hixie.dreamhostps.com>
References: <fb6fbf560809091234y1916d4d3hf20fd6a402c238d0@mail.gmail.com>
	<FA9EC650-5408-48B6-99BC-5EF986B22DF5@iki.fi>
	<F8155422C4FF46F98115ABA65B216F67@HANDS>
	<52BD43ED-D76B-4FE5-A341-9FEFDDDCE419@iki.fi>
	<Pine.LNX.4.62.0810132339510.1237@hixie.dreamhostps.com>
Message-ID: <1c8dbcaa0810141652g3cd59cbdx5b12c06f994fbefc@mail.gmail.com>

Ian Hickson <ian at hixie.ch> wrote:

>  I encourage people to register these rel="" values in the wiki and to try
>  them. I am very interested in what experience with this teaches us. If it
>  turns out to be a good idea, it's definitely something we could add to the
>  spec.

I added this proposal [1] to the Wiki [2].

[1] http://esw.w3.org/topic/HTML/MultimediaAccessibilty?action=show#head-6777ebb969c3272d7447e5a6b67ffb84b8f841b9
[2] http://esw.w3.org/topic/HTML/MultimediaAccessibilty

Best Regards,
Laura

-- 
Laura L. Carlson


From jason at jasonjgw.net  Tue Oct 14 17:02:59 2008
From: jason at jasonjgw.net (Jason White)
Date: Wed, 15 Oct 2008 11:02:59 +1100
Subject: [html4all] Fwd: Accessibility of <audio> and <video>
In-Reply-To: <1c8dbcaa0810141024v16356605pf341f63ac8aeedcf@mail.gmail.com>
References: <fb6fbf560809091234y1916d4d3hf20fd6a402c238d0@mail.gmail.com>
	<FA9EC650-5408-48B6-99BC-5EF986B22DF5@iki.fi>
	<F8155422C4FF46F98115ABA65B216F67@HANDS>
	<52BD43ED-D76B-4FE5-A341-9FEFDDDCE419@iki.fi>
	<Pine.LNX.4.62.0810132339510.1237@hixie.dreamhostps.com>
	<1c8dbcaa0810140109g5ad3f08q9368dc18939ec47d@mail.gmail.com>
	<48F476E4.1050807@cfit.ie>
	<1c8dbcaa0810141024v16356605pf341f63ac8aeedcf@mail.gmail.com>
Message-ID: <20081015000259.GA6752@jdc.jasonjgw.net>

On Tue, Oct 14, 2008 at 12:24:32PM -0500, Laura Carlson wrote:
 
> As Jim Jewett said [1] , something to keep in mind is that
> 
> > In an ideal world, the accessibility features would be in the video.
> >
> > In the real world, often they aren't.
> >
> > The page creator may not be able to modify the audio or video.
> > Sometimes this is a matter of not having the video (embedded 3rd party
> > videos) or not having legal authority; sometimes it is just a matter
> > of not knowing how.

A more serious concern would be whether the audio/video format supports it,
and if it does, whether client-side software can extract it. This approach
also requires the audio/video file to be retrieved over the network, unless
the textual alternatives are at the start (prior to the audio/video data). The
latter is problematic for those with slow connections or strict band width
quotas.



From joshue.oconnor at cfit.ie  Wed Oct 15 04:49:35 2008
From: joshue.oconnor at cfit.ie (Joshue O Connor)
Date: Wed, 15 Oct 2008 12:49:35 +0100
Subject: [html4all] Fwd: Accessibility of <audio> and <video>
In-Reply-To: <1c8dbcaa0810141024v16356605pf341f63ac8aeedcf@mail.gmail.com>
References: <fb6fbf560809091234y1916d4d3hf20fd6a402c238d0@mail.gmail.com>	
	<FA9EC650-5408-48B6-99BC-5EF986B22DF5@iki.fi>	
	<F8155422C4FF46F98115ABA65B216F67@HANDS>	
	<52BD43ED-D76B-4FE5-A341-9FEFDDDCE419@iki.fi>	
	<Pine.LNX.4.62.0810132339510.1237@hixie.dreamhostps.com>	
	<1c8dbcaa0810140109g5ad3f08q9368dc18939ec47d@mail.gmail.com>	
	<48F476E4.1050807@cfit.ie>
	<1c8dbcaa0810141024v16356605pf341f63ac8aeedcf@mail.gmail.com>
Message-ID: <48F5D8CF.2020700@cfit.ie>

Hi Laura,

>Jim Jewett said:
>In an ideal world, the accessibility features would be in the video.
>
> In the real world, often they aren't.
>
> The page creator may not be able to modify the audio or video.
> Sometimes this is a matter of not having the video (embedded 3rd party
> videos) or not having legal authority; sometimes it is just a matter
> of not knowing how.
>
> By all means encourage authors to put the accessibility information
> within the video.  But there needs to be a fallback for cases where
> that doesn't happen.

Yes, of course

> John Foliot has talked of a clean, semantic, explicit association to
> transcripts, text descriptions, captions, audio descriptions and/or
> streams that could be toggled on or off by the end user.

Yes. We need an approach that covers all bases.


> He has also provided examples
> that hint on some best practices that not only native players and but
> HTML 5 as a whole could approach multi-media content.[3]

Thanks I will check them out.

Cheers

Josh

[3]
http://esw.w3.org/topic/HTML/MultimediaAccessibilty#head-9dc3a1bce8ca03b38a207a12b27c25e2fcd47aeb




From laura.lee.carlson at gmail.com  Wed Oct 15 11:21:46 2008
From: laura.lee.carlson at gmail.com (Laura Carlson)
Date: Wed, 15 Oct 2008 13:21:46 -0500
Subject: [html4all] Accessibility of <audio> and <video>
In-Reply-To: <48F6227B.3050408@splintered.co.uk>
References: <fb6fbf560809091234y1916d4d3hf20fd6a402c238d0@mail.gmail.com>
	<FA9EC650-5408-48B6-99BC-5EF986B22DF5@iki.fi>
	<F8155422C4FF46F98115ABA65B216F67@HANDS>
	<52BD43ED-D76B-4FE5-A341-9FEFDDDCE419@iki.fi>
	<Pine.LNX.4.62.0810132339510.1237@hixie.dreamhostps.com>
	<fb6fbf560810140822o852fd4bx1c14d9d2c185a8c4@mail.gmail.com>
	<Pine.LNX.4.62.0810150908370.1237@hixie.dreamhostps.com>
	<48F6227B.3050408@splintered.co.uk>
Message-ID: <1c8dbcaa0810151121sab4a013o780dab5d8d68b340@mail.gmail.com>

Hi Patrick,

You wrote [1]:

> What's the error handling of a video or audio that lacks natively embedded
> alternatives, closed captions, etc?

It doesn't seem that the spec currently addresses that specifically.
Regarding video error handling the spec says:

<quote
cite="http://www.w3.org/TR/html5/video.html#video">

...the user agent may provide messages to the user (such as
"buffering", "no video loaded", "error", or more detailed information)
by overlaying text or icons on the video or other areas of the
element's playback area, or in another appropriate manner.

User agents that cannot render the video may instead make the element
represent a link to an external video playback utility or to the video
data itself.

User agents should provide controls to enable or disable the display
of closed captions associated with the video stream, though such
features should, again, not interfere with the page's normal
rendering.

User agents may allow users to view the video content in manners more
suitable to the user (e.g. full-screen or in an independent resizable
window). As for the other user interface features, controls to enable
this should not interfere with the page's normal rendering unless the
user agent is exposing a user interface. In such an independent
context, however, user agents may make full user interfaces visible,
with, e.g., play, pause, seeking, and volume controls, even if the
controls attribute is absent.

User agents may allow video playback to affect system features that
could interfere with the user's experience; for example, user agents
could disable screensavers while video playback is in progress.

</quote>

Regarding video fallback the spec currently says:

<quote
cite="http://www.w3.org/TR/html5/video.html#video">

Content may be provided inside the video element. User agents should
not show this content to the user; it is intended for older Web
browsers which do not support video, so that legacy video plugins can
be tried, or to show text to the users of these older browser
informing them of how to access the video contents.

In particular, this content is not fallback content intended to
address accessibility concerns. To make video content accessible to
the blind, deaf, and those with other physical or cognitive
disabilities, authors are expected to provide alternative media
streams and/or to embed accessibility aids (such as caption or
subtitle tracks) into their media streams.

</quote>

Regarding audio fallback the spec currently says:

<quote
cite="http://www.w3.org/TR/html5/video.html#audio">

Content may be provided inside the audio element. User agents should
not show this content to the user; it is intended for older Web
browsers which do not support audio, so that legacy audio plugins can
be tried, or to show text to the users of these older browser
informing them of how to access the audio contents.

In particular, this content is not fallback content intended to
address accessibility concerns. To make audio content accessible to
the deaf or to those with other physical or cognitive disabilities,
authors are expected to provide alternative media streams and/or to
embed accessibility aids (such as transcriptions) into their media
streams.

</quote>

[1] http://lists.w3.org/Archives/Public/public-html/2008Oct/0045.html

Best Regards,
Laura

-- 
Laura L. Carlson


From foliot at wats.ca  Thu Oct 16 13:23:16 2008
From: foliot at wats.ca (John Foliot - WATS.ca)
Date: Thu, 16 Oct 2008 13:23:16 -0700
Subject: [html4all] Accessibility of <audio> and <video>
In-Reply-To: <1c8dbcaa0810140109g5ad3f08q9368dc18939ec47d@mail.gmail.com>
References: <fb6fbf560809091234y1916d4d3hf20fd6a402c238d0@mail.gmail.com>	
	<FA9EC650-5408-48B6-99BC-5EF986B22DF5@iki.fi>	
	<F8155422C4FF46F98115ABA65B216F67@HANDS>	
	<52BD43ED-D76B-4FE5-A341-9FEFDDDCE419@iki.fi>	
	<Pine.LNX.4.62.0810132339510.1237@hixie.dreamhostps.com>
	<1c8dbcaa0810140109g5ad3f08q9368dc18939ec47d@mail.gmail.com>
Message-ID: <009101c92fcd$06272680$12757380$@ca>

Ian Hickson wrote:
> 
> 
> Fundamentally, I consider <video> and <audio> to be simply windows onto
> pre-existing content, much like <iframe>, but for media data instead of
> for "pages" or document data. Just as with <iframe>s, the principle I had
> in mind is that it should make sense for the user to take the content
> of the element and view it independent of its hosting page.

If all we are getting is another region, why bother?  What exactly would be the difference between <video> and <object id="video"> or even <div id="video">?  There is a *reason* for specifically naming that region a container for video, and as such we should be able to then provide some native support to specific aspects of this form of multi-media delivery.

> You should be
> able to save the remote file locally and open it in a media player and
> you should be able to write a new page with a different media player
> interface, without losing any key aspect of the media. In particular,
> any accessibility features must not be lost when doing this. For example,
> if the video has subtitles or PiP hand language signing, or multiple audio
> tracks, or a transcript, or lyrics, or metadata, _all_ of this data
> should survive even if the video file is saved locally without the embedding
> page.

In principle this is not wrong, but it introduces a level of bloat and complexity that should not exist.  "Burning" all modes of information transfer into one single unit makes it difficult to substitute or access specific modes of information - detangling as it were - based upon user need.  It also flies in the face of current web content construction: we don't "burn" images into web pages, but rather reference them via URI, so instead of using a tried and true convention, you are proposing a "new" means of delivering content via the web, simply because it now has the added ability to include an audio stream and motion simultaneously?

Consider this: burning a transcript/caption into a media file presumes that the user cannot hear the audio stream, but can read the onscreen text.  But how then could we re-purpose a transcript text for Braille output?  Extraction like that becomes difficult to impossible.  What if you want to also include the PiP Ian references, along with a caption file in the native language, plus perhaps translated sub-titling as well?  This introduces file bloat, as *all* of that digital data must travel down the pipe - there is no way that the end user gets to choose what they need or want - it becomes an all or nothing proposition - OLE for the web?

> 
> It turns out that this is actually not a huge problem -- video formats
> already have to deal with this.

This presumes that you do not completely understand the problems noted above.  It is not a forward thinking position, but rather one that suggests that the status quo is good enough.  There have been too numerous debates to count on whether HTML 5 should be pushing the envelope of rather reflect current practices (the now aged "Pave the cow paths" discussion), but if we are to improve an already difficult situation, we should, IMHO, be thinking about how to improve problems that might not be completely self-evident to the casual observer.  Delivering multi-media content is one such area, and I think the current proposal falls significantly short here.

> If you buy video from iTunes, all the
> metadata is within the file. If you buy audio from Amazon, all the
> metadata is within the file. If you transfer a video track from a DVD
> to a hard disk, one MPEG file can contain all the subtitles, video, and
> audio tracks.

There is a world of difference between metadata and full data - as the difference in names alone suggests.  Let's look at the above noted examples:

1) video from iTunes:
Currently, if/when a captioned video asset is made available via iTunes, it is true that the caption file is burned into the .m4v file (using the bizarro, but apparently TV industry standard .scc binary caption format).  This is a problem from a number of different perspectives: first, working with the .scc format is extremely complicated (it shouldn't be, but it is, and I know this from personal experience), so the entry barrier for even those who wish to "Do the Right Thing" is high (although this could and probably will change).  But the larger problem is that because of its direct 'burning' into the media, the text transcript becomes "hidden" from indexing engines; it cannot be outputted to alternative output devices (such as a Braille refresh bar), the text cannot be re-scaled (you should see how small captions are on an iPhone), and in effect you have a moving image file with text embedded into it, and no @alt value associated to it.  Accessible? You decide.

2) audio from Amazon - (all the metadata is within the file):
But is it?  Oh sure, you get the artist, title, song-length and maybe even the "album cover", but do you get the full CD booklet, complete with liner notes, alternative photos, production notes, thanks-you's from the band, etc.?  Back when I bought vinyl LPs, "albums" even came with posters, postcards (and I think I still have my Billion Dollar Bill from Alice Cooper's Billion Dollar Babies LP).  Nope, in the interest of smaller file sizes you get the bare-bones minimum.  However, when it comes to accessibility, bare-bones minimum is often not enough, so we need to ensure that if/when you need more, you can get at it.  Keeping the additional pieces separate, but easily accessed on demand is an efficient and scalable solution: hoping that everything can be burned into one asset is almost a guarantee that the additional stuff will not be included.

3) a video track [on] a DVD to a hard disk - (one MPEG file can contain all the subtitles, video, and audio tracks):
Really?  Have you actually "cracked open" a DVD and studied it, or made a copy of it?  As someone who has copied more than one movie from disc-to disc (using a nifty little tool called DVD Shrink) I know with certainty that DVD's have numerous "regions", with each region containing a part of the total presentation.  To minimize compression of the movie (to fit on an off-the-shelf DVD) I routinely deselect Spanish subtitling, (often English captioning too as I have no specific need), and even remove "trailer" data that I really do not need or want.  Thus the DVD model is actually one of compartmentalization (including chapters - from the onscreen menu you can do "scene selection"), and *not* one single monolith file.  The DVD model also allows you to toggle on and off captions or sub-titling and take advantage of numerous other "Menu" commands.  Why can't the newly minted <video> element look to feature this type of enhance functionality?


> Furthermore, unlike images, videos tend to stand alone -- where
> an image can mean different things in different contexts, video files tend
> to mean the same thing in all contexts, so the accessibility alternatives
> aren't situational like image alternative text.

This is a wrong view of video accessibility.  As with any other multi-modal delivery mechanism, access to the various modes might differ from person to person.  While there may be less ambiguity about the "meaning" of the asset, the means by which a particular user might access some or all of the supporting pieces that make the multi-media "multi" differs.  This is where accessibility needs to be addressed.

> 
> Thus, a fundamental principle of how this feature was designed is that
> any
> accessibility features and metadata features must be within the video
> or
> audio resource, and not in the HTML markup. The hypothesis is that this
> results in the optimal experience for all users.
> 

I think that this hypothesis is now open for serious questioning.
(And as an aside, I thought that HTML5 specs were determined by user testing and proof, and *not* by hypothesis...)

****************
Comments on comments:
>> The current draft, as I read it, does not support any type of 
>> @transcript or @alt type of attribute on either of these tags, making 
>> them both inaccessible to hearing impaired users, and video 
>> inaccessible to vision impaired users as well.

Ian Hickson wrote:
> 
> I hope that the above introduction now explains the reason for this.
> It's
> not that hearing impaired users (and many other users with special
> needs)
> are excluded, but that to best serve them we should address their needs
> in
> the media resources themselves.

This simply shifts the burden of unbundling to the media player and/or design of the media.  If HTML keeps images (be they .gif, .jpg, or .png) as separate yet linked assets in a "document", why would we use a different model for a "video document"?

Ian Hickson wrote:
> 
> This isn't the intent. The fallback is only intended for legacy UAs. I
> would expect all HTML5 UAs, including ATs, to support <video> and
> <audio>,
> exposing alternative tracks, subtitles, etc.

How?  How will the UAs detangle the various pieces required, based upon user demand?  How will the UA even notify the user of one or more less obvious features of a media asset: the presence of a sub-title file, or a caption file or alternative track?  What part of the spec instructs us on how this is achieved? Have any of the UA implementers that are part of the Working Group been able to provide a proof of concept?  Will the user be able to enlarge text without the need to enlarge an entire video screen, if for example, the onscreen action is perceived as only supporting the transcript, and not vice-versa? (Consider: How many times have you listened to the TV while reading a book or magazine?  Is the TV screen or the audio stream the "more important" then?)

> > > Actually, I think the idea is that the content stream itself is
> > > accessible.
> >
> > That is not something that the HTML specification can (or should)
> > mandate.

Ian Hickson wrote:
> Indeed, we are somewhat at the mercy of whatever codec and container
> formats we end up picking. We should definitely consider accessibility
> a high priority when selecting a good codec, though. For example, we
> shouldn't pick a codec that requires that subtitles be burnt in.

This completely contradicts what you said in your opening piece: "... one MPEG file can contain all the subtitles, video, and audio tracks."  This is quite confusing.

> >
> > So if the UA doesn't support the particular codec but does support
> > <video> it should not show the fallback content?
> 
> Correct.

So we *are* looking for a one-size-fits all solution.  Thus any such solution needs to ensure that each mode of the multi-modal/multi-media asset can be exposed and used independent of any of the other modes.  That is what is going to ensure real accessibility.

> >
> > Scenario : the Principal addresses the University and his address is
> > recorded; his aide asks the webmaster to put the video up on the web.
> > The webmaster looks at the video and finds there are no closed-
> captions,
> > no subtitles, no accessibility features at all.  What is he to do ?
> > Refuse to put it up.  That would be a brave webmaster indeed.  No,
> > instead he puts it up, then relies on the intelligent design of HTML
> 5
> > to allow him to add accessibility features to overcome the
> deficiencies
> > of the raw material. And it is our responsibility to make sure that
> he
> > can do this.

In the real university scenario that I work at, the video will go up ASAP, whilst the caption piece will follow along as soon as it is ready.  This might not be perfect, but it *is* pragmatic.  Being able to upload to the server the transcript/caption file 12 to 72 hours after the video file and have it "catch up" to the video "...already in progress" isn't my first choice, but it does achieve the big-picture end goal, without the need to do further post-production on the video asset.  The current media play simply knows that now the transcript is available, and exposes the toggle button on the controls.  Intelligent, efficient, and graceful.

> 
> The idea is that he would put those accessibility features in the video
> file itself, rather than just in the HTML. That way they don't get lost
> when the user moves the file around (e.g. to use their accessibility-
> optimised video player).

This is simply silly.  Today I can "save" a web page to my local drive, and the UA saves the HTML document, the CSS document and all of the images (pathing intact no less).  Nothing gets "lost", so how/why would it be any different if the html document had referenced links to the various pieces that comprise the complete multi-media experience?  This is a hollow and unfounded assertion.


> >
> > OK, that's a constructive suggestion.  But it also seems to be an
> > attempt to hive off the responsibility for providing accessibility
> > features on others (in this case, the designers of SMIL).  Why don't
> we
> > just bite the bullet and make HTML 5 accessible, full stop ?
> 
> We should look at the Web platform as a whole as a single entity. HTML5
> is
> just one small part of that. Given that outlook, it doesn't really
> matter
> which committee designs the accessibility features, so long as they are
> there. What matters is what is the best technical solution for them.
> The
> best technical solution here is to have the accessibility features as
> closely associated with the moving pixels as possible, in the video
> file
> itself.

Or so you hypothesize.  Once again I put the burden of proof on you to prove that this assertion is true - I believe that I have refuted your major reasons already, but would welcome further data that suggests that the "media as monolith" scenario you propose is currently in practice and meets end user accessibility requirements.  

My experience with captioning .m4v files for deliver to mobile devices such as the iPhone suggest otherwise. (And I can provide examples of such as required: http://phobos.apple.com/WebObjects/MZStore.woa/wa/viewPodcast?id=272900846 and download the last two episodes - they are captioned. Can you scale the text?  Can you extract the text and output it to a Braille output device? No.  By contrast, see: http://ecorner.stanford.edu/authorMaterialInfo.html?mid=1532 where the transcript [and translated transcript] can be accessed independent of the media. THIS is what we should be striving for IMHO)

> 
> One could equally ask the question "Why don't we just bite the bullet
> and
> make HTML 5 define the entire video format". Features like subtitles
> are
> no more or less important than features like the actual moving pixels
> of
> the dog on the skateboard -- they are all part and parcel of what the
> video is, and should be together.

In an OLE world, perhaps.  But the web is not OLE, each piece of the rendered onscreen output is a separate and inter-linked resource.  Images stand alone, style sheets stand alone, HTML stands alone, scripting stands alone..... (and each piece can be download, saved and otherwise manipulated alone)

> 
> Getting back to video and audio, transcripts and lyrics are a good
> example
> of this. Instead of just providing transcripts to users who can't make
> full use of the video or audio, it is better to provide them to
> everyone.
> Many users who are otherwise quite capable of looking at video and
> audio
> may desire transcripts.

Correct.  A deaf person might want the lyrics to a song and not need the audio stream.  Yet the possibility may exist that the only place the lyric currently exists is 'burned' into the audio asset.  Excessive overhead for zero gain - it would be far simpler to simply grab the piece required - the text lyrics - and leave the rest of the media behind: a more bandwidth friendly and efficient solution.  As an added bonus, if the lyric file (in POSH) included a <link rev=""> to the media itself then it makes the media that much more 'index-able' than if it were burned into the song.

> On Mon, 1 Sep 2008, Lachlan Hunt wrote:
> >
> > OK, let's look at the various kind of alternatives that could be
> potentially
> > provided for people who either can't watch or don't want to watch the
> video.
<SNIP>
> > Given that the alternative content is useful to so many people,
> > regardless of physical disability or technological limitations, it
> makes
> > sense for it to be provided in a way that makes it available to
> > everyone.  This is one reason why hiding alternative content away
> within
> > the video element is not helpful because it only makes it readily
> > available to a small subset of those people who might want or need
> it.

Here, Lachlan and I actually are on the relative same page. I would add to his thoughts by suggesting that each alternative should be easily accessed independent of other supporting pieces as required.  Think "right click" on a webpage image and "view image".

Ian Hixson wrote: 
> I encourage people to register these rel="" values in the wiki and to
> try
> them. I am very interested in what experience with this teaches us. If
> it
> turns out to be a good idea, it's definitely something we could add to
> the
> spec.

+1.  I have earlier suggested how <link rev=""> used with captions/transcripts/lyrics might have huge payoffs for SEO, in that media assets could have a much finer, granular indexing, base not upon "keywords"(metadata), but actual content.


> > But there doesn't seem to be a desire for such use of videos -- they
> all
> > seem to be in the category of being 'important content' on the page -
> -
> > so, as Lachlan suggests, alternative representations could be
> embedded
> > in the video and still be appropriate.
> 
> Agreed.

Disagreed.

> On Wed, 3 Sep 2008, Dave Singer wrote:
> >
> > We've actually been thinking about the framework for accessibility of
> > media elements in HTML5.  Note that this is rather different from
> > discussing (say) caption formats or the like.  I've attached a
> 'thought
> > piece' on the subject, which attempts to lay out some of the needs as
> we
> > see them, and also proposes a way ahead.
> >
> > http://lists.w3.org/Archives/Public/public-html/2008Sep/att-
> 0118/html5-media-accedssibility.html
> 
> In general I agree with this document, though, for the reasons
> described
> above, I do not agree with the conclusions regarding providing alt,
> longdesc, or other fallback inside the HTML file itself.

And for reasons I have elaborated on at length, I do not agree with *your* conclusions.  At the very least then, I do not believe this should be considered "closed".

Sincerely

JF




From laura.lee.carlson at gmail.com  Wed Oct 22 09:24:38 2008
From: laura.lee.carlson at gmail.com (Laura Carlson)
Date: Wed, 22 Oct 2008 11:24:38 -0500
Subject: [html4all] Minutes: Technical Plenary 22 Oct 2008
Message-ID: <1c8dbcaa0810220924x4a437a6l5c935b0f3201e928@mail.gmail.com>

Technical Plenary Minutes are at:
http://www.w3.org/2008/10/22-tp-minutes.html

Best Regards,
Laura

-- 
Laura L. Carlson


From jfoliot at stanford.edu  Wed Oct 22 10:57:33 2008
From: jfoliot at stanford.edu (John Foliot)
Date: Wed, 22 Oct 2008 10:57:33 -0700 (PDT)
Subject: [html4all] Minutes: Technical Plenary 22 Oct 2008
In-Reply-To: <019101c93467$eecc44d0$cc64ce70$@lee.carlson@gmail.com>
References: <019101c93467$eecc44d0$cc64ce70$@lee.carlson@gmail.com>
Message-ID: <009f01c9346f$aa7a0f30$ff6e2d90$@edu>

<q> TBL: I did both. We have to acknowledge the past, but we are, very
importantly, designing for the future. We are designing, not
documenting.</q>

Wonder if Hixie is listening...

JG


> -----Original Message-----
> From: list-bounces at html4all.org [mailto:list-bounces at html4all.org] On
> Behalf Of Laura Carlson
> Sent: Wednesday, October 22, 2008 9:25 AM
> To: html4all
> Subject: [html4all] Minutes: Technical Plenary 22 Oct 2008
> 
> Technical Plenary Minutes are at:
> http://www.w3.org/2008/10/22-tp-minutes.html
> 
> Best Regards,
> Laura
> 
> --
> Laura L. Carlson
> 
> _______________________________________________
> List_HTML4all.org mailing list
> http://www.html4all.org/wiki
> Archives: http://html4all.org/mailman/private/list_html4all.org/


From jfoliot at stanford.edu  Wed Oct 22 11:03:18 2008
From: jfoliot at stanford.edu (John Foliot)
Date: Wed, 22 Oct 2008 11:03:18 -0700 (PDT)
Subject: [html4all] More thoughts (RE: Minutes: Technical Plenary 22 Oct
	2008)
In-Reply-To: <019101c93467$eecc44d0$cc64ce70$@lee.carlson@gmail.com>
References: <019101c93467$eecc44d0$cc64ce70$@lee.carlson@gmail.com>
Message-ID: <00a101c93470$78365d20$68a31760$@edu>

<IanJ> ...so if Boeing says "we need something" you should listen to them.

(and so, if the Web a11y community says "we need something"?)

<IanJ> ...it's really important that their systems work.





> -----Original Message-----
> From: list-bounces at html4all.org [mailto:list-bounces at html4all.org] On
> Behalf Of Laura Carlson
> Sent: Wednesday, October 22, 2008 9:25 AM
> To: html4all
> Subject: [html4all] Minutes: Technical Plenary 22 Oct 2008
> 
> Technical Plenary Minutes are at:
> http://www.w3.org/2008/10/22-tp-minutes.html
> 
> Best Regards,
> Laura
> 
> --
> Laura L. Carlson
> 
> _______________________________________________
> List_HTML4all.org mailing list
> http://www.html4all.org/wiki
> Archives: http://html4all.org/mailman/private/list_html4all.org/


From laura.lee.carlson at gmail.com  Fri Oct 24 10:39:46 2008
From: laura.lee.carlson at gmail.com (Laura Carlson)
Date: Fri, 24 Oct 2008 12:39:46 -0500
Subject: [html4all] More Minutes and Notes from the f2f
Message-ID: <1c8dbcaa0810241039y3dd71146g336d0803f09b9fb7@mail.gmail.com>

http://www.w3.org/2008/10/23-html-wg-minutes.html
http://www.w3.org/2008/10/24-html-wg-minutes.html
http://lists.w3.org/Archives/Public/www-archive/2008Oct/0023.html
http://lists.w3.org/Archives/Public/public-html/2008Oct/0089.html

Best Regards,
Laura

-- 
Laura L. Carlson