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

Dave Singer wrote:
> 
> Whoever commented that this is a psychological and policy issue
> rather than technical are right!

This has been a philosophical debate from the onset, and archived
transcripts abound at public-html@.  For what it's worth, I wrote earlier
today (in response to your posting):

"At what point does a technical specification acknowledge social
responsibility?  Should it?"

> 
> When a significant proportion of a democratic society doesn't obey a
> set of laws, then yes, I do actually think it's time to examine those
> laws and the effect they were trying to achieve, because they may not
> be succeeding.

This is not *exactly* the case we have today.  For at least the past 6, 8,
almost 10 years, images without appropriate alternative text have for the
most part at least had alt="".  While this is less than optimal, it is an
established convention, a default setting in most authoring tools, and a
poor but established precedent.  I would rather that the situation did not
exist, that all images had appropriate alternative text, but we don't have
that.

At debate however is the notion that the current status quo is somehow
harmful, as opposed to just less useful.  One camp is suggesting that in
light of the numerous images with no alternative text, and citing sites such
as flickr as being notorious for not providing a means (whether the content
provider wished to or not) of providing alternative text, that the spec
allow for some images, some of the time, under special conditions, to be
'excused'.  At heart is the fact that it is a subjective decision however,
and as such cannot be machine measured for compliance - and I have
previously cited one of the Working Group's blogs as evidence that the
author did not feel it necessary to provide alt text, and that this was
allowed within HTML5. Not that it was not possible, only that *he* thought
it not necessary.  

The other camp (of which I am firmly entrenched) argues that this is the
thin edge of the wedge, and that allowing the spec to back-peddle on
existing requirements (from HTML 3.2 on) that insisted on the alt attribute
(not to mention also contravening both the existing WCAG 1 and Draft WCAG 2)
causes as much "social harm" as the purported harm being created by alt="".
This assertion has never been adequately addressed by the first camp that I
am aware of, and I have been embroiled in this debate for some time. 

> 
> I think we are in violent agreement about goals and struggling with
> ways.  This all hinges around the subtlety of accessibility design.
> Good accessibility results from
> a) good specifications that enables it
> b) good authoring that provides it
> c) good user-side engineering that exposes it
> 
> So, it's not hard to see ways of building systems that fail on one of
> these three.  For example (this is a pure strawman) "if everyone
> would write a transcript of every video they posted, and link it,
> then user-agents could speak the transcript to those unable to see
> the video".  It's not hard to see that such a specification is poor
> because it's vague about how long or detailed the transcript is and
> what language it's in, or how it's synchronized with the other audio
> (or interleaved with it), it's unlikely to be done by authors, and
> (partly because of the spec. problems) rather hard to present to
> users.  Fail on all 3 counts.

Exactly the point.  The current spec language is regrettably vague, in that
it cites 2 possible scenarios, but leaves open the possibility of other
"reasons" for not providing alternative content - the criteria is
subjective.  

The reasons cited are real, but the solution proposed is not a solution, but
rather a throwing up of the hands and saying, "..and then if you can't (or
won't), don't, and we'll still allow you to be conformant".  I argue that
this is fundamentally wrong.

The "solution" might have merit on a technical level, but it undoes close to
a decade's worth of precedence of social engineering (of attempting to
educate the masses on the need to provide alt text, of authoring tools
trying *very hard* to enable this, etc., etc.).  If, as I asked earlier,
there is a social requirement for the next generation authoring language to
continue to encourage content authors to provide useful textual information
to those who are unable to visualize an image, then the proposed "solution"
fails (based upon your 3 point criteria), and needs to be re-visited.  Some
of us (myself for sure) have suggested that a small subset of informative,
reserved values be established to address edge case requirements (and even
mainstream requirements at times) that the Draft authors are suggesting.
Next generation authoring tools could be re-tooled to allow content
contributors to choose, with a tick of a box, a default value of
"_decorative" for images in that category; flickr and it's kin should be
re-tooled to allow contributors to provide alt text, but in the absence of
author supplied content to default to "_not supplied"; both of these
conditions would be "informed" (as such) decisions/values, and conformance
checkers and other "validators" could then flag new content (or even when
retrofitting prior content) that had simply alt="" as being problematic and
worthy of review/repair.  

This solution: 

  A) enables authoring tools and automated sites the ability to provide some
measure of semantic meaning to images, even if such meaning is of little
true value.  It does however also maintain the status quo of requiring alt
text with images, and from a social-engineering perspective re-enforces the
need/value of doing the right thing. 
[Your a) good specifications that enables it]

  B) rather than the open, subjective situation the current draft suggests,
this locks down the envisioned edge cases that the current proposal suggests
to address with a pro-active solution. 
[Your b) good authoring that provides it]

  C) with a small subset of reserved values that have been standardized and
entrenched into a next-gen spec, authoring tools, user-agents, and adaptive
technology alike can take advantage of this standardization and can deal
with this DOM node value as it requires. 
[Your c) good user-side engineering that exposes it]

It is worth noting that all of these points have been expressed over
numerous occasions to the Draft Working Group, and yet rather than examining
the merits of alternative solutions they have stead-fastedly maintained that
the current proposed solution is the best solution, despite protestations
from many, both from within and outside of the HTML WG. (It is for this
reason that you might sense a fair bit of "heat" from some quarters...)

JF

Received on Saturday, 12 April 2008 02:14:16 UTC