Re: "image analysis heuristics" (ISSUE-66)

On Feb 5, 2010, at 5:09 AM, Matt May wrote:

> On Feb 5, 2010, at 5:59 AM, Maciej Stachowiak wrote:
>> On Feb 4, 2010, at 6:11 PM, Ian Hickson wrote:
>>> I've tried to massage the offending paragraph to be less optimistic about 
>>> future implementation strategies, and have included an additional 
>>> paragraph condemning any reliance on alt repair techniques.
>> 
>> For reference, the new text is:
>> 
>> -------------
>> User agents may always provide the user with the option to display any image, or to prevent any image from being displayed. User agents may also apply heuristics to help the user make use of the image when the user is unable to see it, e.g. due to a visual disability or because they are using a text terminal with no graphics capabilities. Such heuristics could include, for instance, optical character recognition (OCR) of text found within the image.
>> 
>> Warning! While user agents are encouraged to repair cases of missing alt attributes, authors must not rely on such behaviour. Requirements for providing text to act as an alternative for images are described in detail below.
>> -------------
>> 
>> Does this satisfy people who objected to the original text?
> 
> No. For one thing:
> 
>> (BTW the warning is bright red and set in bold italics. It is also in a completely separate section from the author requirements for alt text.)
> 
> No, it isn't. The paragraph is precisely where it was before:
> 
> http://www.whatwg.org/specs/web-apps/current-work/#alt

Maybe I'm missing something but it doesn't look to me like the paragraph is in that section (which is the section describing authoring requirements for alt). The nearest linkable id I can find is <http://www.whatwg.org/specs/web-apps/current-work/#img-available>, but you have to scroll down a ways from there to get to the implementation requirements for alt.

> 
> vs.
> 
> http://www.w3.org/TR/html5/text-level-semantics.html#attr-img-alt

>From that link too, if you scroll down a ways you get to the UA implementation requirements for alt.

(Maybe it was just unclear to everyone before that the old text was already separate from the authoring requirements for alt.)

Do you have a change to suggest to make this text more separate?

> 
> Secondly, after all this discussion on the list about this particular sentence, and after several of us (including yourself, Maciej, and Lachlan) came to some kind of agreement on what should be said (and more importantly, where it should be said), it's especially galling to see Ian unilaterally making a minor change that clearly shows his disregard for the WG's input.

I don't remember getting down to the level of a specific single wording, though we did come up with a number of suggestions. That being said, I'm more interested in hearing what further changes would lead to a change you are happy with. Do you have specific specific requests? (Also happy to hear from Lachlan or anyone else who has an opinion on the matter.)

> 
> Third, this still fails to address one of the problems cited in the change proposal:
> 
> "The reason for this is that images themselves are only place markers for what the author intends to express. It is the author, then, and not the image, that is most responsible for determining what fits best as alternate content. And for this reason, no automated tool can possibly claim to sufficiently repair missing @alt content. This sentence only serves to make that less clear.
> 
> "User agents may use any technology they choose to improve the user experience for users with disabilities. Such an implementation may in fact have positive effects, in certain cases. However, it is not necessary to specify this, particularly if by doing so the necessity of human-created @alt is made less than perfectly clear."
> 
> http://esw.w3.org/topic/HTML/ChangeProposals/ImageHeuristics

Can you explain how it fails to address it? It seems to me that the necessity of human-created @alt is made perfectly clear, particularly by the warning. Do you feel that it remains less than perfectly clear? Are you concerned that it may still seem like repair is "sufficient"?

> 
> Finally, Ian provides no justification for making the change he made, instead of the original proposal or the consensus suggestion. This, after a two-page change request, and no fewer than 93 emails, so far, about this one paragraph. If it takes this level of rigor just to get a proposal onto the table, it's not a good sign to see that little if any of the work of consensus-seeking here was actually listened to. And this is one of the most minor and uncontroversial changes of all of the open issues.
> 
> I am extremely disappointed in this result, after what I thought was productive discussion on all sides, that would have improved the quality of the spec overall. I had been hopeful that all that discussion would have ended at a straightforward, consensus-based solution. But instead, we're back to attrition warfare.
> 
> This is yet another example of how unbelievably broken this process is.

I don't think Ian said this is the only or final change he's willing to make. He just took a shot at it, and it seems like he addressed at least part of the concerns in your rationale. Can you please try to give him some constructive feedback about his efforts? If we really can't come to consensus, then we can settle this through Working Group decision. But I think it's a little hasty to give up after one round of changes.

Regards,
Maciej