RE: [html4all] HTML5 Alternative Text, and Authoring Tools

Dave Singer wrote:
> More intriguing is Microsoft Word.  I'm using 11.3.5 (Word 2004 for
> the Mac). 

The irony <grin> of an Apple employee commenting on a Microsoft application

> You can insert images in documents, and you can save documents as
> HTML.  Now, generating HTML is not the primary purpose of this tool.
> In Word documents, there is no place to enter (as far as I can tell)
> alt text, and indeed, when you save as HTML, it generates an IMG
> without an alt attribute at all.

Currently... (However we always want to improve things... This is one of the
arguments put forth by both sides of the discussion... It's the path forward
that is under debate)

> Imagine that Word did NOT have "save as HTML" and you are a junior
> engineer assigned to writing this functionality, and you are told
> that your HTML must be conformant, and you can't ask for changes in
> the rest of Word.

*BUT*, if the only way to create conformant documents is to ensure that
<img> has @alt, then it is up to the *senior* folk that junior reports to to
make the decision to either a) create non-conformant HTML, or b) allow
changes to the app beyond the basic requirement envisioned.  As in life, you
cannot suck and blow at the same time, and if the specification requirement
mandates something to ensure conformance, then programmers either do it or
don't do it - there is no gray here. 

> You are told that as a 'save as' plug-in you have
> no interactivity, no access to the user.  (And even if you did, I
> cannot imagine how a user would react if asked for alt text for all
> images at save time, and anyway, who says the person doing "save as
> HTML" was the original author anyway?)

Ah yes, MS WORD. Let's see here:  File >> Properties >> 

	Summary Tab: Title, Subject, Author, Manager, Company, Category,
Keywords, Comments

	Statistics Tab: Created, Modified, Accessed, Printed, last Saved By,
Revision Number, Total editing time, Statistics: Pages, Paragraphs, Lines,
Words, characters, characters (with spaces) (**)

	Contents Tab: Document contents (**)

	Custom Tab: Name, Type (!), Value (!!), Properties (!!!)

... And that's in my version of MS Word 2003.  Ain't metadata grand?

I see at least 3 places where adding the ability to provide alternative text
to images intended for html export could be modified (noted with **)
including the Custom Tab which appears move-in ready for this kind of
extended function/requirement (noted with superfluous use of !!!).

Given that tools such as Acrobat can add image alt text, and given that the
HTML5 requirement would demand @alt for conformant documents, and given that
Word appears to be ready to take up this challenge, (and given that MS
really doesn't like losing market share to lawyers)...

The final *programming* decision would rest with Redmond and document
conformance with the document author.  Again, the current state of poor
authoring tools should not be a factor in assessing "syntactical
requirements" (Henri Sivonen) of HTML 5.

> Given how poor all these choices are, some have suggested noalt in
> this case (which seems to be semantically equivalent to (a), though
> it reinforces that the tool *knew* it was in a bad position, that
> leaving alt out was not accidental).  I've (half-seriously) suggested
> alt-trustworthiness-level ranging from 0 (it's completely worthless,
> I only put in a value so as to pass syntax conformance) to 100 (the
> alt text is a brilliant and insightful piece of masterly writing that
> could not be improved on in so few words).

Nope, save as non-conformant.  If content authors do not care about ensuring
"completeness" and thus conformance, chances are that they do not care about
conformance period.  This is what this whole debate *really* boils down to -
how to achieve "conformance" without that nasty "bolt-on" of accessibility
(and /that/ whole thread strand served to highlight one of the other
problems in the discussion).

One thing that has not been made clear in all of this round-about is what
are the *CONSEQUENCES* of non-conformant HTML 5?  At least a few voices
(mine being one) have suggested that if <img> is syntactically incomplete,
that it be "broken" in exactly the same way that this string: '<img
alt="John posing with his motorcycle" />' would be "broken" (and what would
the consequence of that be?).  I remember "back-in-the-day", teaching how to
author HTML in notepad and having students "forgetting" to close their
<table>s and the resultant problem in Netscape 4.  I can tell you, one error
like that in the classroom and those students *never* forgot to close their
(layout) tables again.

Yes, it is harsh, but so too is the notion that a document can be
"conformant" and complete when, as Gez Lemon has pointed out, it is *NOT*
complete for some users.  

And so to those across the table from me - can you clearly and plainly state
what the consequences would be for HTML documents that are non-conformant.
I know you want that documents be conformant, that is not the question.
What *exactly* are the consequences?


Received on Friday, 16 May 2008 17:14:18 UTC