Re: Text description for @poster (was RE: CP, ISSUE-30: Link longdesc to role of img [Was: hypothetical question on longdesc])

On Sun, Mar 25, 2012 at 1:47 AM, John Foliot <john@foliot.ca> wrote:
> Silvia Pfeiffer wrote:
>>
>>
>> Even that image is a placeholder image for the video and therefore a
>> short description of what the viewer will later see in the full video.
>
> This is patently false. It could be *any* image, displaying *any* visual
> design the art people choose. It could contain text never spoken or
> displayed in the movie, it could contain other content also never rendered
> in the film. We simply cannot say or know at this time how authors will use
> their ability to insert a placeholder image in the video bounding box, prior
> to the start of the video. We have given the authors that ability, at which
> point we have lost control over what will be chosen.
> http://www.collativelearning.com/PICS%20FOR%20WEBSITE/ACO%20expanded/posters
> /clockwork.jpg

It frankly doesn't matter what picture the publisher chooses - it is a
place holder for the video with video controls on top of it and
therefore looks like a video and behaves like a video and provides
information about the video. If the publisher chooses  a misleading
image, then the text would need to be misleading, too. It does not
change my argument.

Have you heard of duck typing? It states that "When I see a bird that
walks like a duck and swims like a duck and quacks like a duck, I call
that bird a duck." Similarly here, when I see an image with video
controls that behaves exactly like a video, it *is* a video for all
intents and purposes.


>> I
>> don't want to have the screenreader read out something like "image of
>> blah blah blah", then immediately followed by "video of blah blah
>> blah". What is it now? Is it an image or a video? Can I interact with
>> it or not? That's confusing.
>
> Respectfully, what you as a sighted person wants, versus what numerous
> non-sighted people have expressed wanting, don't match up.  As what *I* want
> is to respect and deliver what non-sighted users are asking for here, I
> really don't think what *you* want has the same relevance.

I was using the word "I" as a placeholder for "I as a screenreader
user", not for myself. I'm sorry if that wasn't clear. I wanted to
find out what user experience you are after with poster-alt and
aria-label being filled at the same time.


> I have already suggested that for a short-text description, there is an
> extreme likelihood that the short-text (Accessible Name) would most probably
> be the same thing.

Excellent. That means we don't need a poster-alt and we can use
aria-label as the only short text representation of the video. We are
converging!

> It is the longer textual descriptions that I am more
> concerned about, and the feedback I have received also confirms that. So
> let's for the moment agree that the short text for either visual asset will
> be the same. Let's focus on the longer textual descriptions.

I agree, we need a solution for long textual descriptions. I believe
@aria-describedAt will work. But we can have that discussion.


>> This is only a problem for mixed-language pages / text alternatives.
>> It is rare to happen.
>
> Evidence? Entire Foreign film festivals moved onto on-line delivery may
> disprove that assertion quickly...

That would be, say 100 films out of millions published on the
Internet? That's still a small problem.

>> Since we've lived with it for <img>, we might as well accept it for
>> <video>, so as not to over-complicate things.
>
> Is not one of our goals to improve things?  Again, I'm not too fussed
> personally, but we *should* make sure there is some form of consensus.

I mean: we should find the same solution for both and not come up with
yet another way of doing things that developers have to learn.

>> For the rare case where the author needs proper marked-up text for
>> i18n, we should recommend the use of @aria-labelledby or
>> @aria-describedAt.
>
> Aria-describedat is not yet really a *thing*, so we really cannot recommend
> using it,

Ah, sorry, that was a typo: I meant aria-describedBy here (for short text).

> In all of your response Silvia, you have still not suggested how to provide
> longer textual descriptions for both visual assets, you have only asserted
> that you don't want 2.

I don't know what discussion you were having, but I was primarily
focused on the short text discussion and that one attribute is
sufficient for it and it includes the poster alt text.

> I and others disagree with your assertion, and
> further we still lack a means to even provide 1 long textual description,
> never-mind 2.

We're working towards @aria-describedAt as a solution. I myself
registered the bug for @transcript. So I am in agreement that we need
a solution. But I would prefer a common solution across elements.

> This causes me a fair bit of frustration.

What are your use cases for multiple long text descriptions?

I indeed think we need one solution for all complex elements that all
screenreaders and Web developers can follow. Multiple solutions will
be confusing to author and confusing to implement support for.

I agree that there may be several diverse types of documents that can
be called a long textual representation of the video. But only one of
them should be the long text representation that the screenreader
reads out. All the rest should just be normal links near the video
that anyone can follow. Happy to have this discussion.

Regards,
Silvia.

Received on Sunday, 25 March 2012 02:17:44 UTC