RE: [html4all] New issue: IMG section of HTML5 draft contradicts WCAG 1 & WCAG 2 (draft)

Dave Singer wrote:
> 
> Consider an image that is 'part of the content'
>      <img ... alt="an image">
> tells the user agent that there is a useful alt string that is 

I will insert here "should be" (as opposed to "is")

> worth
> displaying to the user, which is a lie (the string provided is not
> useful), and
>      <img ... alt="">
> tells the user-agent that the image is not 'part of the content',
> it's not worth describing, which in this hypothetical case is also a
> lie, whereas 
>      <img ... >
> tells the user agent the truth, that there is not a useful
> author-provided string.

And herein lies the first fundamental problem.  While your first 2 scenarios
have credibility, they both also illustrate a failure on the content
contributor, not on the technical merits of mandating an alternative text
value to non-textual content.  

The problem with the proposed spec is that it allows a gray area to exist
(in some instances, you don't need an alt value), and the fear (justifiable)
from some quarters is that this gray area can and will be exploited.  I need
only quote one of the HTML5 Working Groups' personal blogs to illustrate
this fear:

	"I am currently following HTML5 (omitting alt) as it wasn't really
clear to me what would be a better solution given the single constrain I
have: not finding it necessary to provide replacement text for all those
images." (http://annevankesteren.nl/2007/09/alt) - Here Anne did not "find
it necessary" - not that he could not, nor that the image was an Ink blot
test that providing alternative text to would invalidate (the two scenarios
suggested in the draft spec), but simply that he did not find it necessary.
The fear is very real!

All three of your examples do dis-service to those that truly need to have
alternative text, but only the third (your "the truth") is a tacit
acceptance, almost approval, of the failure of the content creator to do
anything.  The spec uses "strong language" but does not outright forbid
non-textual content to be compliant without alternative text.  This is a
direct reversal of years of HTML authoring guidelines and web accessibility
teaching.

> 
> Lies are "worse" than the truth.

Endorsing and permitting truths that cause harm, simply because technically
it can be done, is even worse than accepting the truth that still today some
authors cannot be bothered to recognize those in our society who are both
disadvantaged and who could be further empowered if the content author gave
a damn.

And this is problem 2 of this on-going discussion.  At what point does a
technical specification acknowledge social responsibility?  Should it?

Some other thoughts/responses:

Henri Sivonen wrote:
> A piece of software gets images from somewhere and puts them
> automatically out on the Web. What should the developer of that piece
> of software program it to do when an image arrives from whatever pipe
> they arrive from without alternative text? How do you require a
> program to emit something it simply doesn't have without faking it
> with junk?

If sewage passes through a conduit, should the conduit do nothing, or at the
very least attempt to filter out the larger pieces of sewage?  "Faking it
with junk" is an un-defined action:  this is an identified problem, and if
HTML 5 is about identifying and addressing problems, the proposed solution
(do nothing) is not a solution, but rather a burying of one's head in the
sand.


Ryan Parman wrote:
> 
> In regards to the accessibility concerns, it's less important that all
> images have alternate text, and more important that the alternate text
> provided is actually useful. (Occasionally, IMO, accessibility zealots
> tend to trip over their own feet while running to the goal.) Yes,
> accessibility is extremely important -- nobody is arguing that -- but
> sometimes the right answer is "no value."

Fair enough, so what we need then is a method to specifically say that,
which is far different than accepting no information at all, which is what
making alt optional allows.

> 
> In the related (but not identical) point, does having a fake (i.e.
> unusable) value make things *worse* than not having a value (in cases
> where there SHOULD be one -- which is most of them) at all? I'd argue
> that it certainly has the potential to be worse for people using
> assistive technologies, search engine spidering and the like, although
> I admittedly don't have any notable experience with assistive/search
> technology.

Henri S. used the word "fake", but that is undefined.  This once again
points to the need (IMHO) for one or more reserved values that user agents
can "standardize" on (remember, this *IS* about standards) that address
possible scenarios when content authors fail to, or cannot, provide
appropriate alternative text.  "_notsupplied" and "_decorative" are two that
instantly come to mind.  The "_notsupplied" while still far from useful does
signify that the image is probably of value, as opposed to "_decorative"
which is fairly self-explanatory.  "_notsupplied" has the added benefit
(IMHO) of also applying a subtle but real social pressure on content
contributors to do something, but if they choose to ignore that pressure,
then the default of "_notsupplied" still allows compliancy, whilst still
retaining the mandated need for alt values for all non-textual content.


Charles McCathieNevile wrote:
> 4. It means that all legacy testing systems will have to be rebuilt to
> ensure that they recognise this magic string as being equivalent to
> not having any alt attribute.

Chaals and I have discussed this, and he is correct.  However, if the choice
is between having the alt attribute optional vs. legacy tools becoming less
useful, I vote for option 2.  WCAG 2 will necessitate a re-writing of many
testing tools, do we then not embrace WCAG 2 because it breaks legacy tools?
Of course not! Software evolves, in part based on market conditions.  Just
as sure as we will see an Opera 10, we will see testing systems evolve to
new standards.

JF

Received on Friday, 11 April 2008 20:15:47 UTC