RE: img@relaxed CP [was: CfC: Close ISSUE-206: meta-generator by Amicable Resolution]

I had been trying to not get into the depths of this issue, but I guess I put my foot in it :).

Without having read up on the huge amount of background material on this topic and the various positions, I will simply write what is done in other formats and standards (PDF, specifically, in this case) and hopefully that may carry some weight.

The PDF standard (ISO 32000-1:2008) has Alt as an optional key for any structural element (14.7.2) and there is a separate section (14.9.3) which goes into detail on how/when/where you MAY use an alternate on various PDF objects (content vs. annotations vs. form fields, etc.).  But throughout the section the wording is MAY - the word choice for a clearly optional (and not even recommended) feature.  Standards such as PDF/A or PDF/X that simply reference these sections of ISO 32000-1 w/o modification will also have the same MAY requirements.  Thus any validation tools that are applied to PDF, PDF/A or PDF/X will only act _IF_ Alt is present, and in that case, simply validate the its value is of the correct type.

PDF/UA (ISO 14289-1), however, has requirements throughout the document for the presence of Alt on Text, Images, Graphics, Annotations and even Math figures.  However, there is no requirement on the value of the Alt - so that an empty string could be valid according to the standard.  So a PDF/UA machine validator would flag missing Alt, but not an empty one. There were various reasons why that was a conscious decision by the committee.   One of the key reasons was around machine vs. human validation of accessibility considerations.  Validation of the value of an Alt can simply not be done by a machine - at least not today - and so a human has to be involved.  Since a human has to be involved anyway, there was no reason to put additional requirements on the machine.  This is true for a number of aspects of the PDF/UA standard - that we expected that the standard could NOT POSSIBLY be validated entirely by machine and would require (secondary) human validation. 

So if I were to simply say that HTML should work in the same way, I would suggest that the alt element be optional in HTML - so that it's absence would not be considered invalid/error by a validator in normal operation.  However, I would certainly think that a validator that is doing WCAG compliance or had an option for "accessibility checking" would certain (at least) warn or even error in the case of a missing Alt.   As to the empty Alt, as noted, I think that also should not be made an error, but perhaps a warning, for the reasons above.

Leonard

-----Original Message-----
From: Sam Ruby [mailto:rubys@intertwingly.net] 
Sent: Sunday, August 05, 2012 10:35 AM
To: public-html@w3.org
Subject: Re: img@relaxed CP [was: CfC: Close ISSUE-206: meta-generator by Amicable Resolution]

On 08/05/2012 09:11 AM, Leonard Rosenthol wrote:
> I can also comment that our tools for PDF->HTML would NEVER write out 
> alt="", as that would be incorrect.  If an image has no alt, then it 
> doesn't get an alt tag.  Alt="" has a completely different meaning.

Generally, on issues such as these, first hand statements from generator developers will be given more weight than forensic analysis of documents, which in term will be given more weight than assertions made without evidence.

We currently have three proposals listed:

http://dev.w3.org/html5/status/issue-status.html#ISSUE-206

Which, if any, of these would be something your tools for PDF->HTML would be willing to implement?  Are there any reasons why one would be better than the other?  Would you rather propose something else?

> FWIW - PDF/UA, the "accessibility standard for PDF", would fail empty 
> alt text.

Would any of the existing proposals fix that?  Should PDF/UA be changed? 
  If so, how?

> Leonard

- Sam Ruby

Received on Sunday, 5 August 2012 16:22:08 UTC