W3C home > Mailing lists > Public > public-html@w3.org > February 2012

Re: Request to Reconsider Alt Guidance Location

From: Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no>
Date: Sun, 26 Feb 2012 19:51:16 +0100
To: Steve Faulkner <faulkner.steve@gmail.com>
Cc: HTML Accessibility Task Force <public-html-a11y@w3.org>, public-html@w3.org, Judy Brewer <jbrewer@w3.org>, Janina Sajka <janina@rednote.net>
Message-ID: <20120226195116279027.43b0041f@xn--mlform-iua.no>
Steve Faulkner, Sun, 26 Feb 2012 08:56:39 -0800:
>> As result, there will be nil -
>> zero - normative requirements -
> 
> no there will be the machine checkable requirements
> presence or lack of the alt attribute.

OK. So on/off validation, like in HTML4: Only a check of whether the 
alt attribute is present but no check of its content. That would touch 
many issues and subjects that we have debated - like the claims that it 
is sometimes better to not offer any @alt. One could argue that HTML5's 
current approach, were there is no simple predicability about whether 
it validate to not drop the @alt, is better. So the CP should probably 
explain why this change would be better.

On the other side: The current HTML5-conformance validation — like the 
HTML4 validation — has a 'loop hole subset': Presence of an empty alt 
attribute, will always make the img validate - regardless of generator 
string or other gotchas. So, while an HTML5 validator will display an 
error for

         <a href=foo ><img src=bar ></a>

   it will not display an error for

         <a href=foo ><img src=bar alt='' ></a>

Thus, the simple route to validity, for lazy authors and authoring 
tools, remains to include an empty alt=''. 

I guess this speaks in favor of the change you have worked on. But then 
again, it could perhaps also be possible to plug this hole in the HTML5 
validation - e.g. by making the latter example an error.
-- 
Leif H Silli 
Received on Sunday, 26 February 2012 18:51:50 UTC

This archive was generated by hypermail 2.3.1 : Monday, 29 September 2014 09:39:30 UTC