RE: HTML Action Item 54 - ...draft text for HTML 5 spec to require producers/authors to include @alt on img elements.

On Fri, 9 May 2008, Justin James wrote:
> >
> > That's not entirely true, we can mandate whatever we want. We just 
> > can't machine-check much beyond presence and non-null-ness. For 
> > example, we require that authors use <h1> for headers, but we can't 
> > check it without a human (at the moment -- AI might get there 
> > eventually!).
> 
> Anything that cannot be machine-checked should not be in the spec.

I respectfully disagree. I think it's very important that we define 
elements to have clear semantics and that we require that those semantics 
not be misused.


On Fri, 9 May 2008, Justin James wrote:
> 
> Not bonkers in the slightest, from the aspect of “semantic Web". If 
> there are swaths of the spec which cannot be machine-verified, or which 
> are easy (sometimes, even advantageous) to use inappropriately (but 
> still schema-correct), then let’s get rid of this goal of “semantic 
> Web” now, and let’s get rid of the “accessibility” goal.

I think getting rid of the accessibility goal would be terrible. 
Discriminating against people simply based on which media they use is 
immoral and short-sighted.


> Plain and simple, if the semantics of the document cannot be determined 
> accurately and reliably the vast majority of the time, those two goals 
> are impossible.

The semantics of <p> can be determined accurately and reliably. It means 
"paragraph". What can't be determined accurately and reliably is whether 
the author actually put a paragraph there.


> We have a binary choice:
> 
> 1) Retain the inclusion of <p>, <h1>, and other “semantic” elements. 
> Of course, none of them are anything other than <div>, <span>, etc. with 
> a semantic meaning associated with them in the spec, and an unspoken 
> default styling that the browser vendors have all agreed upon.
>
> 2) Remove the “semantic” elements, and only use <div>, <span>, etc. 
> with ARIA (or ARIA-like) descriptors to indicate their semantic purpose 
> (for example: <div purpose=”paragraph”> to replace <p>).

We have many more choiced than that, but let's ignore that for now.

> If we are going to go with choice #1, fine. In that case, I propose that 
> we DUMP @alt, and replace it with a million permutations that are 
> specific, like, “@alt_click”, “@transcript”, an whatever else we 
> think would be appropriate. After all, if we can have a bunch of 
> variants of <div>, <span>, etc. all meant to provide semantic value 
> (with no way of validating the correct usage), then why not start doing 
> the same with attributes too?

We do do that with attributes. We have alt="", title="", src="", class="", 
lang="", and many more.


> But if we go with option #2, now we are looking at a system that makes a 
> heck of a lot more sense, and forces HTML authors (both human and 
> automated) to carefully consider what they are doing. If you make 
> everything a “semantic-less” tag, with 1 or 2 attributes (ARIA, or 
> something like it) that are *required*, then it means that the semantics 
> and the styling are (finally!) fully separated, as the goal has been 
> since HTML 4.

There is no technical difference between <p> and <div purpose=paragraph>. 
They are merely syntacticly different ways of conveying the same thing. 
Neither one of them is machine-checkable.


On Fri, 9 May 2008, John Foliot wrote:
> 
> Right.  I can bang together a small PHP app that uploads photos to my blog
> and call it a "photo sharing site", and then claim dispensation just like
> flickr.  Wrong!

People don't need an excuse to ignore the needs of minorities. They do it 
quite happily already. Requiring alt doesn't change that. At most, it 
might take someone from simply omitting the attribute altogether to 
including bogus alt text, which is actually worse.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Received on Saturday, 10 May 2008 00:31:36 UTC