- From: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
- Date: Thu, 24 May 2012 07:46:52 +1000
- To: Benjamin Hawkes-Lewis <bhawkeslewis@googlemail.com>
- Cc: Charles McCathieNevile <chaals@opera.com>, HTML Accessibility Task Force <public-html-a11y@w3.org>, "Edward O'Connor" <eoconnor@apple.com>, Geoff Freed <geoff_freed@wgbh.org>, Laura Carlson <laura.lee.carlson@gmail.com>
On Thu, May 24, 2012 at 1:03 AM, Benjamin Hawkes-Lewis <bhawkeslewis@googlemail.com> wrote: > On Wed, May 23, 2012 at 1:59 PM, Silvia Pfeiffer > <silviapfeiffer1@gmail.com> wrote: >> On Wed, May 23, 2012 at 6:11 PM, Benjamin Hawkes-Lewis >> <bhawkeslewis@googlemail.com> wrote: >>> On Wed, May 23, 2012 at 7:53 AM, Silvia Pfeiffer >>> <silviapfeiffer1@gmail.com> wrote: >>>>> It is unnecessary to mint a new element to satisfy UC1 (transcript as >>>>> linked resource); it would be simpler for the IDREFs in transcript="" to >>>>> directly point at the <a> that links to the transcript. >>>> >>>> I was told that hidden <a> elements are a real problem, since they >>>> gain keyboard focus. Putting the link into a <div>-like element avoids >>>> this. >>> >>> Today, a simple link to a transcript is one of the two common ways of >>> surfacing a transcript. >>> >>> Authors who want to hide the link can use CSS "display: none;" in all >>> browsers applying their CSS or HTML @tabindex="-1" to remove the link >>> from the tab order in all browsers. If we continue to allow references >>> into @hidden content, they could also use @hidden to hide the link. >>> >>> Alternatively, authors can leave the link in the tab order and use CSS >>> or JS to ensure the link is visible on focus. >>> >>> Using a normal a@href has a better backwards compatibility story than >>> adding an attribute to transcript. >>> >>> So I don't understand the problems with: >>> >>> <transcript><a href="url">Transcript</a></transcript> >> >> I don't mind this approach. >> >> >>> or >>> >>> <a href="url">Transcript</a> >> >> This has all the problems that I listed about lack of semantics, lack >> of machine-discoverability when used without an actual <video> element >> etc. See previous email. > > I don't understand … the semantics and the machine-discoverability > arise from the @transcript attribute that refers to the a element by > IDREF: > > <video transcript="transcript"></video> > <a id="transcript" href="url">Transcript</a> When you have a video element on the page, yes. Note that I said "when used without an actual <video> element". Here is an example where there is no video element on the page: <a href="video.avi">Download the video</a> <transcript src="transcript.html">This is a video transcript</transcript> A search engine can discover this as a video transcript even without a video element present on the page. Take that advantage on top of the possibilities of browser-side rendering of off-page transcripts on the page. And most importantly, transcripts are a semantic piece of content in their own right, even more so than <article> or <footer> or <header>. Marking <a>, <div>, <p>, <iframe>, or any other element as a transcript-containing element is unclean and ugly - a <transcript> element is elegant and extensible to transcript-related features. Many other things are enabled with an explicit semantic element. It could for example receive an aria landmark so you can jump directly to them with AT. It could be content that is automatically downloaded with the video page for offline viewing. Finally, the transcript is still marked up even if the author forgets accidentally to put a @transcript attribute on the video element. It will be announced as the transcript to AT never the less. I think there are plenty of advantages and opportunities to it being a new element. Cheers, Silvia.
Received on Wednesday, 23 May 2012 21:47:41 UTC