W3C home > Mailing lists > Public > public-html@w3.org > March 2012

RE: CP, ISSUE-30: Link longdesc to role of img [Was: hypothetical question on longdesc]

From: Sean Hayes <Sean.Hayes@microsoft.com>
Date: Wed, 21 Mar 2012 19:40:43 +0000
To: Charles Pritchard <chuck@jumis.com>
CC: John Foliot <john@foliot.ca>, Silvia Pfeiffer <silviapfeiffer1@gmail.com>, David Singer <singer@apple.com>, "janina@rednote.net" <janina@rednote.net>, xn--mlform-iua@målform.no <xn--mlform-iua@xn--mlform-iua.no>, "rubys@intertwingly.net" <rubys@intertwingly.net>, "laura.lee.carlson@gmail.com" <laura.lee.carlson@gmail.com>, "mjs@apple.com" <mjs@apple.com>, Paul Cotton <Paul.Cotton@microsoft.com>, "public-html-a11y@w3.org" <public-html-a11y@w3.org>, "public-html@w3.org" <public-html@w3.org>
Message-ID: <E9A92BD0A4FC934EB7935470A46D15240906CA64@DB3EX14MBXC325.europe.corp.microsoft.com>
Yes, my first impression was that the link was outside of the video, my mistake sorry. 

I think I see what you are trying to do, which is hide an image inside the video, but by virtue of its position associate that image and its longdesc with the video; however if you do that then the spec says that content should not be shown to the user except in older browsers that don’t understand the video element. I interpret rendering the longdesc within that content to be part of "showing". Since the user agent would not be showing the image, it would not be providing a link to the description within the image to the user either.

Since the spec says "in particular, this content is not intended to address accessibility concerns." I think that reinforces that view.  Hence my question. Are you interpreting the spec differently, or are you proposing to change it such that the fallback content can in fact be used to address accessibility concerns.

But, even if it did work, from a practical perspective I don’t think we can adopt this idea, because for the foreseeable future fallback content in a video is actually likely to be taken up by a video rendering mechanism (e.g. Flash) that does work in older browsers.


-----Original Message-----
From: Charles Pritchard [mailto:chuck@jumis.com] 
Sent: 21 March 2012 19:04
To: Sean Hayes
Cc: John Foliot; Silvia Pfeiffer; David Singer; janina@rednote.net; xn--mlform-iua@målform.no ; rubys@intertwingly.net; laura.lee.carlson@gmail.com; mjs@apple.com; Paul Cotton; public-html-a11y@w3.org; public-html@w3.org
Subject: Re: CP, ISSUE-30: Link longdesc to role of img [Was: hypothetical question on longdesc]

In your reply you stated: "it looks to me as if on loading the page the poster image will appear twice". Did we clear that up?

Your next reply is about the fallback content. In my example, the image has surrounding anchor tags. It links to another page, presumably where the user can download the video.

I am not at all suggesting we alter the fallback behavior.

I'm suggesting that aria-describedby pointing to an image element with a @longdesc attached would have semantic meaning.

Would you take another close look at my example code and let me know i it ought to be expanded for clarity?

-Charles


On Mar 21, 2012, at 10:50 AM, Sean Hayes <Sean.Hayes@microsoft.com> wrote:

> So are you proposing a different handling of video fallback content? I'm still not seeing how this works. If it is fallback content you would only see the poster (and by implication the poster description) if the browser didn't handle video.
> 
> -----Original Message-----
> From: Charles Pritchard [mailto:chuck@jumis.com] 
> Sent: 21 March 2012 17:14
> To: Sean Hayes
> Cc: John Foliot; 'Silvia Pfeiffer'; 'David Singer'; janina@rednote.net; "'xn--mlform-iua@målform.no'"; rubys@intertwingly.net; laura.lee.carlson@gmail.com; mjs@apple.com; Paul Cotton; public-html-a11y@w3.org; public-html@w3.org
> Subject: Re: CP, ISSUE-30: Link longdesc to role of img [Was: hypothetical question on longdesc]
> 
> The content within the video tag is fallback content.
> The image would only appear once.
> 
> -Charles
> 
> On 3/21/2012 6:01 AM, Sean Hayes wrote:
>> I may be missing something in your example, but it looks to me as if on loading the page the poster image will appear twice, and then the second image does not disappear as the video starts. It may work from an ARIA perspective, but from a design POV I don't see this as a solution to the issue, can you elaborate how this is supposed to work?
>> 
>> -----Original Message-----
>> From: Charles Pritchard [mailto:chuck@jumis.com]
>> Sent: 21 March 2012 07:55
>> To: John Foliot
>> Cc: 'Silvia Pfeiffer'; 'David Singer'; janina@rednote.net; "'xn--mlform-iua@målform.no'"; rubys@intertwingly.net; laura.lee.carlson@gmail.com; mjs@apple.com; Paul Cotton; public-html-a11y@w3.org; public-html@w3.org
>> Subject: Re: CP, ISSUE-30: Link longdesc to role of img [Was: hypothetical question on longdesc]
>> 
>> On 3/20/2012 11:18 PM, John Foliot wrote:
>>> This is the very same reason why aria-describedby cannot point to "hidden"
>>> text, as it too will be flattened to the same string text, using the same
>>> computational rules.
>> Can we get by with aria-describedby pointing to an embedded image tag?
>> 
>> <video poster="poster.jpg" aria-describedby="poster"
>> longdesc="videolongdesc.html" aria-label="My video">
>> <a href="videolongdesc.html" title="My Video"><img id="poster"
>> src="poster.jpg" longdesc="posterlongdesc.html" alt="My Poster" /></a>
>> </video>
>> 
>> We're pointing aria-describedby at an element with special semantics:
>> img @longdesc, and it's not a display: none/@hidden element,
>> so we're not violating any laws there... though I would have no
>> expectation that the img could gain focus as fallback for video.
>> 
>> It looks kind of ok from an ARIA perspective, though it still loses a
>> little something from non-aria.
>> I've argued we may want to look at allowing users/authors more easy
>> access to displaying fallback content.
>> 
>> In that case, the typical user could both see the longdesc, and see the
>> fallback content (and then follow that longdesc).
>> 
>> 
>> -Charles
>> 
>> 
>> 
>> 
>> 
>> 
> 
> 
> 
> 

Received on Wednesday, 21 March 2012 19:41:22 UTC

This archive was generated by hypermail 2.3.1 : Monday, 29 September 2014 09:39:31 UTC