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

Sorry for top posting here, but can I make a suggestion?

Matt's original change proposal was a simple one: to remove the one
paragraph.

Discussion about this change proposal evolved into general suggestions for a
new paragraph, either in the same location, or a new location. What the new
paragraph states and where seems to be the object of some contention. Or
perhaps, just the location, I can't tell from the discussion.

Would it not be a cleaner move to return to Matt's simple change proposal,
about removing the paragraph, and then call for new change proposals about
text and location of this particular paragraph?

The new change proposals aren't necessarily counter proposals, because none
of the new proposals disagree with Matt's change proposal, which was to
remove the one paragraph. They're original change proposals that somewhat
bypass the "file-a-bug/editor-response/create-issue/create-change-proposals"
process.

This separates what seems to me, to be two different actions: one that
doesn't really seem to have disagreement (remove the existing paragraph);
one that does have some contention (a new paragraph in the existing
location, as compared to the same new paragraph in a new location).

Sorry this is procedural discussion, but seems relevant to solving this
issue and moving forward. Cleanly, at least.

As for Web Browser section name, that's an entire new thing and unrelated to
the change proposal under discussion.

Shelley


On Fri, Feb 5, 2010 at 10:52 AM, Maciej Stachowiak <mjs@apple.com> wrote:

>
> 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.
>
>
>