W3C home > Mailing lists > Public > public-html@w3.org > January 2010

Re: Discussion on Change Proposal for ISSUE-66

From: Maciej Stachowiak <mjs@apple.com>
Date: Thu, 21 Jan 2010 22:16:11 -0800
Cc: Shelley Powers <shelley.just@gmail.com>, Jonas Sicking <jonas@sicking.cc>, HTML WG <public-html@w3.org>
Message-id: <61CB5624-45DB-4C7F-BEB3-5A203186A684@apple.com>
To: Matt May <mattmay@adobe.com>

On Jan 21, 2010, at 9:55 PM, Matt May wrote:

> On Jan 21, 2010, at 10:35 PM, Maciej Stachowiak wrote:
>>> http://www.w3.org/TR/AERT
>> This seems to be focused on repair techniques for authoring or evaluation tools, where they find a problem and make or suggest changes to the markup. It doesn't seem relevant to this situation.
> AERT is basically a human-language version of an evaluation tool's heuristics for detecting broken content. It's relevant here in that it contains rules for determining broken @alt content, and steps on how to repair it. Your previous message suggested some heuristics; I'm just pointing out that similar work has already been done within W3C.

If you check out this section, you will see that it describes actions that are appropriate for an authoring or evaluation tool, but not for a browser or scren reader:

The actions suggested include "Prompt the user for a text equivalent for the image" and "After user has entered an "alt" attribute for the image, check the site for other instances of the image". Clearly the "user" being referenced here is the author (i.e. user of the authoring tool), not the end user of a browser. Or at least, I assume everyone agrees it would be ineffective for a screen reader to prompt a blind user to enter a text equivalent for an image while browsing.

So I stand by my statement that this document not relevant. It's pretty clearly about authoring-side repair, not client-side repair once you have received broken content. Interesting ides, but not really the same problem space.

That being said, I think it's detection of suspicious alt values is something that might be useful on the client side.

>> I see the following in UAAG: <http://www.w3.org/TR/UAAG10/guidelines.html#tech-missing-alt>
>> 1) This seems to not only allow but require UAs to repair missing content. Therefore, I think HTML5 should at least allow repair of some form. We could either make this an explicit MAY-level requirement, or just let it be implicit that repair is allowed. I think it's probably better to be explicit to remove room for doubt.
> I would support a statement that makes reference to UAAG requirements on missing @alt.

All right, let's see if anyone comes up with suitable wording.

>> 2) The suggestions cited there (using the URL, content type, or element type) are potentially useful, but the idea of using OCR is not mentioned at all. Perhaps OCR was less practical when UAAG was first published.
> Not necessarily. I remember this being discussed in the UAWG. UAAG tended to shy away from recommendations that weren't applicable to all web content, and in the case of OCR, the issue was that in various cases it was either bound to fail due to excessively small text; or with logotypes (say, the Coca-Cola logo); or in cases where text is present, but not representative (a Brazilian flag would result in alt text of "Ordem e Progresso"; a photo of the main street of an American town might result in "M McDonald's Billions and Billions Served Texaco Speed Limit 25").

You are right that it could sometimes fail. Other times it could give weird results. It seems to me that even the odd results you describe may still be better than saying "IMG01279.JPEG" or "JPEG image", which is what you may well get from the URL or content type.

>> That being said, I think this suggests an update to UAAG rather than different advice in the spec. What's the best way to provide feedback on UAAG?
> Their list is w3c-wai-ua@w3.org. They're working on UAAG 2.0 presently:
> http://www.w3.org/TR/UAAG20/


>> I think our minimum level of consideration should to be to ensure that things *required* by UAAG are at least *allowed* by HTML5.x. In this case, I think we can satisfy that goal by making sure that repair for missing alt is allowed in HTML5, without going into too much detail about what techniques could be used. What do you think?
> Insofar as HTML5 is more of a user agent spec than HTML 4, I agree. What I'd like is more clarity in the text of the section on @alt about what is expected of authors (i.e., don't rely on browsers to generate it for you), and what is intended to repair nonconforming content. Given that authors will refer to this, I think that division should be made much clearer.

Almost all the text in the alt section describes what is expected for authors. I think it's just this one statement allowing repair that would need to be distinguished.

Received on Friday, 22 January 2010 06:16:46 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 29 October 2015 10:15:57 UTC