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

On Sat, Mar 24, 2012 at 6:42 PM, John Foliot <john@foliot.ca> wrote:
> Silvia Pfeiffer wrote:
>> Yes, I appreciate that. I don't think there is any dispute of that.
>> I'm just saying that since we don't know what frame the author *or
>> browser* chooses to represent the video - of the thousands of frames
>> that a video contains (or in fact any image) - the frame is only
>> that:
>> a frame representing a short glimpse of the video.
>
> *IF* a) the author chooses to select a frame of that video, convert it to a
> .jpg and then reference that .jpg via @poster, or b) the poster frame is not
> author declared, at which point the browser is free (per the spec) to select
> a frame from the video to display as the placeholder image, *THEN* your
> assertion is correct.

We're looking for a general solution which covers all cases.

> However if the author chooses to declare that placeholder image using
> @poster, then we *DO* know what the frame (or any other graphic image) is -
> as it is being expressly declared via @poster, so you cannot always say we
> don't know what frame the author is choosing.

Any content that is being published with a CMS will have that problem.

> What you keep sidestepping however is the scenario whereby the art
> department creates an image outside of the film director's series of moving
> images. In this case, the page author will be referencing an image that
> never originated from the film itself, but from a separate, disparate
> source. This has not been addressed.

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.


> Let's dissect the spec. It states:
>        "The video element is a media element whose media data is ostensibly
> video data, possibly with associated audio data."
>
> Question: is a JPG video or audio data?

It's ostensibly video data, because like video data it is a rendered
image region on screen that is expected to turn into moving images.


> The spec continues:
>        "The poster attribute gives the address of an image file that the
> user agent can show while no video data is available. The attribute, if
> present, must contain a valid non-empty URL potentially surrounded by
> spaces."
>
> Confirmation that the @poster {object} is in fact an image file, and not
> video data. Further, also a backhanded acknowledgement that it is a separate
> file that *isn't* a video.

This part is the technical part, not the UI presentation part. We've
agreed that it makes no difference where the image comes from for the
viewer. The spec, however, has to be concise for the author.

> So physically they are different data objects, different data types. Since
> both the Video (mime-type = video/mp4) and the image (mime-type =
> image/jpeg) are both visual assets, they both require textual equivalents.

Again you're moving to the technical level, which is irrelevant. You
cannot right-click on the poster and do "view image". So it is part of
the video. If the author really wants to be sure that the image is
treated as an img object for some reason (e.g. to be able to right
click on it and treat it as an image), then he has to author it with
an <img> element and overlay it on top of the video. In this case you
have all the functionality for <img> available and don't need a
separate poster-alt.

>> Therefore, there is
>> no semantic difference between what the video contains and what the
>> image contains: you can in fact identify the video with the long
>> textual description and the image with the short textual description.
>
> Respectfully - No. There is a semantic difference, and there is a physical
> difference. What you are suggesting (at least, what I am hearing) is that
> conceptually to you, a sighted person, there is a symbiotic and logical
> linking of the two objects that create a composite understanding of what it
> is you are looking at being physically rendered on screen.

Sort of. That conceptual and visually presented one object that I can
see needs to be presented to non-sighted users as one object, too. 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.

>> Now, my solution for the short textual description of a video was
>> @aria-label. If that is indeed not possible (like John seems to
>> argue,
>
> Be careful of paraphrasing what I am saying.  Silvia, a significant part of
> this is understanding what the various values in the Accessibility APIs
> take, what they do, and how they "work".
>
> In the Accessibility APIs, they have the concept of an AccName (Accessible
> Name). The ARIA Implementation Guide[1] explains how to determine the
> Accessible Name this way[2] (paraphrased):
>
> Both aria-labelledby and aria-label map to the AccName. User agents are
> supposed to first look for an aria-labelledby value; if none exists it falls
> back to looking for an aria-label. If neither exists, then the instruction
> is to look for a host-language equivalent (in HTML that equates to @alt),
> and if *that* does exist, then look for a unique identifier (such as a file
> name).

@alt does not exist for video. So it seems @aria-label is perfectly adequate.

> This can be "proven" with standard images today: screen readers "finds" an
> image and looks first for an aria-labelledby value, then an aria-label
> value, then an @alt value, and then something unique. We rarely see the
> first 2 in garden-variety HTML docs, but often see @alt (good!). In that
> case, the screen reader uses, as the AccName, the string value of @alt: if
> that value is {null} (aka alt="") then the reader "reads" the null value and
> says nothing (it is also, at this point, the equivalent to
> role="presentation", which will also have the same effect). However, when
> there is no alt at all, not even alt="", then it drills down further (as
> described above) and finds something unique - the file name - and announces
> that out loud.
>
> So, to the AAPIs, essentially aria-labelledby = aria-label = @alt.
>
> However, while aria-labelledby *can* express rich text (as it is marked up
> and in the viewport), both aria-label and @alt can only take string text,
> which means both aria-label and @alt cannot render HTML rich content, such
> as alt="<span lang="fr">Le petit d&eacute;jeuner</span> - a short story".
> This is true of @alt, and this is true of aria-label.

This is only a problem for mixed-language pages / text alternatives.
It is rare to happen.
Since we've lived with it for <img>, we might as well accept it for
<video>, so as not to over-complicate things.
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.

Silvia.

Received on Saturday, 24 March 2012 08:07:40 UTC