Re: Working Group Decision on 142 poster-alt

Hi Sam,

I'd like to understand some of the reasoning behind this decision as
to help me and others argue for/against proposals in future polls.

On Tue, Mar 29, 2011 at 7:59 AM, Sam Ruby <rubys@intertwingly.net> wrote:
> === Need for text alternatives for placeholder image
>
> As we generally do, we start with the positive effects listed for each
> proposal.  In this case, the positive effects stated for the "No Poster
> Alt" Change Proposal were not found to be applicable and therefore not
> considered (see section below for details).  Taking the positive
> effects listed in the "Introduce a new <firstframe> element" Change
> Proposal, we extract the following objections (paraphrased) to the "No
> Poster Alt" proposal: that it is does not allow for accessibility or
> internationalization requirements, and that the description is
> ambiguous.
>
> The "Introduce a new <firstframe> element" Change Proposal also
> provides a concrete example where it is felt that such text would be
> necessary.

Are you referring to the Clockwork Orange movie poster example?

> At this point we only have objections to the "No Poster Alt" Change
> Proposal, so we turn to examine objections to the "Introduce a new
> <firstframe> element" to see if we find a stronger one.  Each of the
> following are quotes from the survey:
>
>  Given that sighted users won't know (or, if they do, care) that
>  they're looking at the poster image, it would be confusing and
>  inconsistent to have a short text alternative specifically for the
>  poster image for non-sighted users.
>
> This is an opinion.  Given that there was a concrete counter-example
> presented, this opinion was not given much weight.

I agree parts of the quoted paragraph seems based on opinion, however
parts does not seem to be. For example "sighted users won't know that
they're looking at the poster image" does not seem opinion based but
rather based on current video players. All the flash based or browser
based video players that I have interacted with gives little to no
indication that the poster is being displayed as opposed to the
beginning of the video. Hence it would be inconsistent to give AT
users such a distinction.

However I agree that the "if they do [won't] care" and "would be
confusing" statements seem opinion based.

So my question is, do you consider the whole paragraph opinion based?
If so, how could it be reworded such that the backing facts are taken
into account?

My fear here is my objections in other polls will be dismissed as
opinions when I do in fact believe them to be facts.

>  I strongly object to describing the poster frame separately from the
>  video to AT users. This distinction is not made for sighted users,
>  who have no way of knowing if what they are seeing is the first frame
>  of a video or a poster frame. The poster frame is "intended to be a
>  representative frame of the video" and as such, the description of
>  the video should also be a suitable description of the poster frame.
>  If the poster frames brings attention to any specific aspect of the
>  video, it would be appropriate for the video's description to also
>  stress that aspect. Making the suggested disctinction would encourage
>  inappropriate use of the poster frame.
>
> Again, we have a concrete counter-example and no evidence that it is
> "inappropriate".

Can you point out this counter-example a bit more precisely?

I agree that Clockwork Orange example shows a case when you could add
a alternative text to the poster image, however I don't see any
evidence that you couldn't include that in the description of the
video itself. In fact, the quoted text would make a perfect start of a
description of the video itself, far beyond the quality of most
alternative descriptions for images or videos available on the web
today.

>  it seems highly unlikely that people who use the poster incorrectly
>  (to include content that is not representative of the video resource
>  itself) would be aware enough to make the effort of making that
>  inappropriate use accessible.
>
> Again, we have a concrete counter-example and no reason to believe it
> is "incorrect".

Again, could you point out this counter-example a bit more precisely?
As far as I can see the PosterElement proposal gives no argument for
that people would use it correctly.

>  The proposal is mainly based on concern that authors *could* use
>  image that contains unique and valuable information about the video.
>  However, this does not happen in practice.
>
> Again, we have a concrete counter-example.

As far as I can see the PosterElement proposal gives no example of
when a poster has been used to provide valuable information in
practice. It gives a theoretical example, but makes no claim to be a
practical one, no?

> There is also an objection to naming this attribute "first frame", but
> that objection is a "necessary consequence" of the objection that this
> is already implemented by browsers and used by web pages.

What does "necessary consequence" mean here? Are any changes that
require changes to deployed browsers going to automatically going to
receive such an objection? While I agree it's good to be conservative
with making changes to UAs which might break existing content, if the
chairs are automatically adding such objections to the mix, they might
want to confer with UAs first to see if they share the concern.

All UAs have experience with deprecating features. Some are harder to
deprecate than others.

> Finally, there is this:
>
>  I object to introducing a <firstframe> void element that is likely to
>  appear before the <source> elements. In all browsers that do not
>  implemented support for <firstframe>, any following <source> elements
>  would become child elements of <firstframe> and thus would not be
>  considered in the resource selection algorithm. In effect, that video
>  would be completely broken in those browsers. (Yes, this is also a
>  problem with <track> and introducing new void elements in general.)
>
> Looking deeper into this it turns out that the "Introduce a new
> <firstframe> element" Change Proposal is internally inconsistent.  It
> provides spec text that describes an element with a value of a url, but
> then provides examples where the value is placed in a src attribute.
>
> At this point, we have strong objections to the requirement that the
> firstframe MUST contain alt, and an inconsistent Change Proposal.
>
> For completeness, we evaluate the objections to the "No Poster Alt"
> proposal.  Along with responses to objections already dealt with, a
> discussion on what would be the best name, as well as the following
> statements which reinforce the arguments in the original change
> proposal:
>
>  HTML5 should have a mechanism to provide that indication to people
>  with disabilities. Currently it does not. <firstframe> provides that
>  possibility.
>
>  the firstframe image can have value in itself
>
> These arguments are strong, but do not address the strong arguments
> against making this indication mandatory.  The evidence for the need to
> provide a separate textual description of the firstframe is indirect
> (in the form of an example poster that somebody *might* use) vs direct
> (a list of actual sites that deploy videos today and an explanation as
> to why a requirement to make providing an alternate text description
> mandatory would be inappropriate in those cases).  Additionally there
> is the problem that the "Introduce a new <firstframe> element" Change
> Proposal is internally inconsistent, and that it introduces a
> non-backwards compatible change which affects existing content and
> implementations without providing a migration plan.
>
> *** Decision of the Working Group ***
>
> Therefore, the HTML Working Group hereby adopts the "No Poster Alt"
> Proposal for ISSUE-142.  Of the Change Proposals before us, this one
> has drawn the weaker objections.

So it seems like the PosterElement mostly failed on the fact that it
asked that the element would be required, and that the proposed
changes were internally inconsistent. Not due to the fact that it
failed to motivate a need for the new feature.

My concern here is that the standard for introducing a new feature is
fairly low. The change proposal for adding the feature provided a
situation when the feature *could* be used. However I don't see
anywhere in the change proposal where it actually demonstrates where
the feature is *needed*.

The counter proposal asking that the feature is not introduced points
out that the poster can already be described: "it should be described
as part of the description of the video element itself."

I have been unable to find a explanation for why this solution does
not work. Neither the PosterElement proposal, nor the Group Decision
rationale gives a reason for why this solution is not enough and thus
why the new feature is needed.


My concern here is that it's very hard to argue against adding a
feature. For any given feature it is always possible to construct a
scenario where the feature solves a use case better than existing
solutions. And if the feature is relatively easy to implement, say
about a week for an initial implementation, it seems hard to argue
that the implementation cost is prohibitive.

However at the same time we couldn't possibly implement every feature
which solves some use case and takes less than a week to write an
initial implementation for.

So at that point the process becomes that we'll add any feature to
HTML5 which someone has enough free time to come up with a use case
and write a change proposal. This seems like a terrible way to
prioritize features.

So, how can I, as someone who cares about focusing HTML5 on a small
but powerful feature set, argue against adding features?

And note, I care about this not just as an implementor (many of the
features I'm arguing against are not ones that I will personally
implement), but as someone who has uses and teaches others about HTML
and believe that a smaller platform is one that is likely to contain
fewer mistakes and is easier to learn.

/ Jonas

Received on Tuesday, 29 March 2011 21:42:22 UTC