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

On Feb 5, 2010, at 7:46 AM, Matt May wrote:

> On Feb 5, 2010, at 8:15 AM, Maciej Stachowiak wrote:
>> 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.
> 
> Yes, your ID is closer to the text in question. If you look at the change Ian made, it's clearly made in exactly the same place the text was already.
> 
> http://dev.w3.org/cvsweb/html5/spec/Overview.html?r1=1.3702&r2=1.3703&f=h
> 
> As was discussed on the list, this advice does not belong under this section, but in the Web Browsers section. 

OK. I guess I don't entirely agree with that suggestion - it doesn't fit with the current content in the Web Browsers section. The (poorly named*) Web Browsers section is about issues of broader scope than one element, such as scripting, navigation and history. I could see a case for putting it in the Rendering section. Rendering mostly covers visual rendering in the context of a CSS formatting model, but it also defines other UA requirements such as interactive behavior. But I must admit I  am not entirely clear on what's wrong with having it in the UA requirements portion of the main img element section, with most of the other UA conformance requirements for img (as opposed to mixed in with the authoring requirements for alt, which would be bad and is not the case).


> 
>>> 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.)
> 
> I said here that I approved of your proposal to trim Lachlan's advice.
> 
> http://lists.w3.org/Archives/Public/public-html/2010Jan/1189.html
> 
> Take that, strip the specific advice, point to UAAG, put it in Web Browsers, and we're done. I'll volunteer to update the change proposal to that effect, if we can agree on it beforehand.

I personally agree with pretty all of that other than "put it in Web Browsers". Others may speak for themselves.

> 
>> 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"?
> 
> For one thing, I still think the document as a whole is better off without that entire passage than with it. Ian's edit only takes one poor example to support the previous sentence and replaces it with one that's slightly less poor. We did also discuss the limitations of OCR, and why it's not a significant improvement:
> 
> http://lists.w3.org/Archives/Public/public-html/2010Jan/1103.html
> http://lists.w3.org/Archives/Public/public-html/2010Jan/1107.html

I'm not sure it's worth mentioning specific repair techniques, since that information seems particularly likely to become dated, and is more specific advice than is actually needed.

But your objections against OCR were basically:

1) Sometimes OCR won't give any result - but in that case you are not any worse off than if you had done nothing.
2) OCR might give only the text of a mostly non-textual image, possibly being more confusing than helpful - I am not sure OCR would work that way. I could not replicate such results with the shareware OCR programs I tried as applied to main street images (the example in one of the emails) from Google image search.

On the other hand, it's pretty common to use images of text for fancy headers. Knowledge of CSS image replacement techniques has increased the number of these that are properly accessible. But it seems like a case where OCR would work pretty well (in fact one shareware OCR application I tried was quite successful at turning the logo images of some popular sites into text.) OCR has also historically been a technique used by screen readers for native applications (in cases where OS / application support was lacking). So it has a history as an accessibility repair technique. Obviously not the first choice for how assistive technologies should work, but I feel like you might be overemphasizing the negatives.

Anyway, I think mention of OCR is not really necessary, so this is a bit of a digression.

I'd be happy to personally support a change similar to the one you described above.

Regards,
Maciej


* - I say "Web Browsers" is poorly named because its requirements apply to a wide variety of HTML implementations, not just Web Browsers. Apple develops a wide variety of HTML-consuming applications, including web browsers, an IM client, a mail client, a widget runtime, a widget development tool, an end-user web publishing tool, a help viewer, a dictionary application, an e-book reader and a media player/store app. All of them are affected by at least some of the content in the "Web Browsers" section. "Interactive User Agents" might be more accurate, but even non-interative user agents that support scripting will be affected by much of this content, and practically every kind of implementation is potentially affected by the link relation definitions. Or perhaps it should be called "Scripting and Navigation", since that's essentially what it covers.