RE: Another summary of alt="" issues and why the spec says what it says

Ian Hickson wrote:

> 
> If you can suggest a way to make the text not machine-checkable
> instead of 
> subjective, I'm certainly eager to change the spec to be more machine
> checkable. However, I really cannot see any way to compute whether
> alternative text is valid or not, or whether it is ok for alternative
> text to be omitted or not.

Ergo, as a technical solution, the one proposed is not a solution, but
rather a failure to find a good solution.  I myself cannot accept a
technical standard that bases a key accessibility question upon a subjective
determination by an unknown third-party entity regarding conformance.  Ian,
I *do* appreciate that this is difficult, but 2 key points keep coming back
to haunt:

"WCAG WG is chartered to set Accessibility guidelines and HTML
WG is not; so HTML5 should be careful to create features that support
WCAG and describe their use in ways that conform to WCAG."

"2.  By their charters, WAI groups (here WCAG) are the go-to
experts in matters of accessibility
3.  WCAG requires @alt (WCAG1) or the function that in HTML4
is provided by @alt (WCAG2)"


>> [1] Rare as in 1 in a million, 1 in a trillion, or 1 in 100?
> 
> I have no idea. Does it affect the debate? It happens on major sites,
> like 
> Flickr, so even if Flickr was the _only_ site it happened on, we'd
> still have to deal with it.

Except, as Jim Jewitt notes: "Taking out the alt requirement will remove any
pressure on flikr to fix this."
[http://lists.w3.org/Archives/Public/public-html/2008Apr/0456.html]  See,
this is the point - push it back on the offending authors/sites to get their
houses in order, not mangle the next-gen authoring language to forgive crap.
This is the social pressure point that has been brought up, but that the
(CS)engineers want to side-step.  Just because you *can* is not a reason,
and should certainly not be entrenched into a spec. 

> 
> 
>> [2] Or perhaps the content provider just can't be bothered to add an
>> alt text because "...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)
> 
> No, the spec makes the alt attribute required in this case:
> 
>    When it is possible for alternative text to be provided [...] text
>    that conveys can serve as a substitute for the image must be given
>    as the contents of the alt attribute.

But how can this be enforced, or even checked, when the very same spec says
that under "certain circumstances"...  All Anne needs to do is claim that
his is one of those "certain circumstances", and, given the subjective
criteria, he is once again "conformant".  Talk about Magic Tokens - this one
clause is a Get-Out-of-Jail-Free card of the highest order.

> 
> The [...] bit is a non-normative clause giving examples of such cases:
> 
>    for example if the image is part of a series of screenshots in a
>    magazine review, or part of a comic strip, or is a photograph in a
>    blog entry about that photograph,
> 
> "Not bothering" is not one of the reasons that the spec gives for not
> providing alternative text. I can make this more explicit if you like.

Let's look at this.  The text reads: "When it is possible for alternative
text to be provided..." - first of all, the circumstances cited are tainted:
I *CANNOT* add alt text to my Flickr images today because the interface does
not allow me.  Should the interface change to allow for content authors to
add real alternative text, then some would, some wouldn't, some might get it
right, and others might get it wrong - however the "possibility" aspect is
not a technical restraint, but rather a programming restraint/fault of the
current Flickr UI.  

To be more explicit, you (and the site/program/application seeking to use
this clause) must give a "technical" reason why it is not possible, not a
"human" reason why it is not, and to date I have not seen one.


> 
> It's just an example. The normative text is "In a rare subset of these
> cases, there might be no alternative text available. In such cases,
> the alt attribute may be omitted, but the alt attribute should be
> included, with a useful value, if at all possible.". That's all. It
doesn't
> make any judgments about whether this does or doesn't apply to wikis or
CMSes.

And again, this is problematic.  "Rare subset" is undefined, and so any time
a site/application/author explicitly ignores the specification point that
states "...text that conveys can serve as a substitute for the image must be
given as the contents of the alt attribute." they can cite that they are
part of the rare subset, and we have nothing to fall back on that demands
they offer a burden of proof.  And so, gradually, we see more and more
pages/sites/applications that become members of the "rare subset" club that
eventually we have as many critical images with no useful values attached as
we do with. 

> 
> 
>> [4] I note that we've upped the ante to 8,000 from 3,000.  So then,
>> if the number of images uploaded < 8,000 then alt *must* be
>> included, but if the number of images uploaded >= 8,000 it can
>> become optional? 
> 
> No, that's again just an example and the number is meaningless. I can
> make 
> it smaller if you want. It's just a random number.

Citing a large number in the non-normative part (as opposed to my measly 4
images on my Flickr account) suggests that at some point the ability of the
content author becomes diminished by the volume of images to be dealt with -
after all adding alt text to my four photos would take me all of 5 minutes
to do, should I both care to do so, and was programmatically provided the
means to do so.  And so your assertion that the number is meaningless, yet
at the same time increasing it from 3,000 to 8,000 leads me to believe that
the volume factor and thresh-hold is one that does count for something.  I
can add alt text to four images, but doing so to 8,000 is hard (although, I
might add, still possible).  So the spec leaves open a gray area that
apparently *is* hinged on volume.  Remove the number issue, and (presuming a
good UI) it is possible to provide alt text to 4, 40, 400, 4000 or 40,000
Flickr images - it boils down to time and effort.  How to eliminate the
possibility of Flickr claiming they can't perform this function, and make
the spec criteria more specific I do not know, but this is the nut of the
problem - at what point do we through up our hands and cry uncle... It's not
about "can't", it's about "won't".

If the W3C says that WAI and not HTMLWG are responsible for Accessibility
guidelines, and WAI says that "WCAG requires @alt (WCAG1) or the function
that in HTML4 is provided by @alt (WCAG2)", and the only example you can
provide is one where it is a question of willingness, and not technical
feasibility, then you must/should accept the experts advice.

> 
> 
>> In such cases, the alt attribute may[5] be omitted, but the alt
>> attribute should be included, with a useful value, if at all
>> possible." [http://www.w3.org/html/wg/html5/#alt]
> 
> This is the actual normative conformance criteria.


And so, again, we require a "technical" reason why it is not possible, not a
'social' reason, such as when Joe Public uploads their vacation photos.
Technically he *could* add alt text, but maybe he won't.

And so this is your real problem - how do you let Flickr off the hook when
they have no control over the content supplier?  I argue you don't: make it
difficult for Flickr to live with the Status Quo, and provide them with real
fallback mechanisms rather than absolution.

> 
>    D. Mark the image as being critical-but-of-unknown-content.
> 
> Options A-C all result in a worse accessibility situation. D is not
> possible in HTML4, and is the option we want to provide in HTML5. How
> we 
> provided it is up to us. As listed at the top of this e-mail, I'm
> aware of 
> three syntax proposals for D (omitting alt to indicate this case,
> introducing a new attribute value to indicate this case, and
> introducing a 
> new attribute to indicate this case) and one conformance definition
> proposal for handling D. I've cited above the e-mails listing the
> problems 
> with two of the syntax proposals, and the "unready" conformance
> proposal 
> doesn't solve the problem (sites that care about conformance want to
> conform, they don't want to reach a level of "unready" conformance),
> so 
> that leaves us with just what the spec says now.

Your emails cite your reasoning, but often the reasoning is subjective and
is inter-sprinkled with your own opinion.  Where it is short on technical
merit, it becomes long on conjecture.  To whit:

"The problem is that I am skeptical that magic keywords won't be abused as
much as the simpler syntax we have now... If we had reason to believe that
these new magic values wouldn't be abused as much as the current proposal,
then I'd agree. However, I think that that would be naive." (Scorecard: 2
"I"s, 1 "I'd", and one "we")
[http://lists.w3.org/Archives/Public/public-html/2008Apr/0458.html]

"...another reason why I personally prefer simply omitting the alt=""
attribute rather than introducing keywords." (Scorecard: 1 "I", 1
"personally")
[http://lists.w3.org/Archives/Public/public-html/2008Apr/0439.html]

"There is *absolutely no practical difference* to the UA between omitting
the alt="" attribute altogether, and having the alt="" attribute set to some
magical reserved value. They are functionally identical, and user agents can
get as much information from either."  (This is also the email where you set
about "randomly" picking on my 4 image Flickr account)
[http://lists.w3.org/Archives/Public/public-html/2008Apr/0434.html] 
While there is no "I"s in this response, there is an assertion with no
proof.  The practical difference has been debated by others (notably Joshue
O'Connor and David Poehlman), and you cannot argue that something = nothing:
<img src="" /> does not equal <img src="" alt="{any_value}" /> and no matter
how many times you say it, it does not become true - unless you can
technically prove otherwise.

"Reserved values are just syntactic variants on omitting the attribute.
There is no practical difference. (Well, other than reserved values being
significantly less usable in today's UAs, and omitting the alt="" attribute
being cleaner, which is why the spec says to omit the attribute instead of
inventing some new reserved value.)"
[http://lists.w3.org/Archives/Public/public-html/2008Apr/0431.html]
Hey, wait a minute, didn't you just say that there is no practical
difference in the previous email, and now you are saying that there *ARE*
differences?  Which is it?  How can variants be identical, when the very
definition of variant is "manifesting variety, deviation, or disagreement"
[http://www.merriam-webster.com/dictionary/variant]

If you are going to directly oppose the recommendation of the PFWG, then the
burden of proof rest upon you to prove your assertions, which you have not
done.

> 
> The words "may" and "should" are defined by RFC2119 and have very
> specific 
> conformance meanings in the context of HTML5:

[from RFC2119 - http://www.ietf.org/rfc/rfc2119]

MAY   
   This word, or the adjective "OPTIONAL", mean that an item is
   truly optional.  One vendor may choose to include the item because a
   particular marketplace requires it or because the vendor feels that
   it enhances the product while another vendor may omit the same item.

(and so, as I stated, it is "subjective".  Flickr "may" decide that adding
the alt-text feature to their interface may hurt them in the marketplace, so
they won't/don't do it.  The spec forgives this, not on technical merit, but
because "the marketplace" makes it uncomfortable for them.)

   An implementation which does not include a particular option MUST be
   prepared to interoperate with another implementation which does
   include the option, though perhaps with reduced functionality.

(the page is non-conformant would be "reduced" functionality - a token value
that admonishes that alt text was "_notsupplied" would be reduced
functionality as well.  If, as you claim, HTML5 should be focused on the
users, then I have no issue making it harder on the people who profit from
putting stuff on the web.)

   In the
   same vein an implementation which does include a particular option
   MUST be prepared to interoperate with another implementation which
   does not include the option (except, of course, for the feature the
   option provides.)

...and again, it is unclear how providing absolutely no information about a
critical image (if you could prove a technical reason why it was not
present) can "interoperate" with an interface that seeks this information,
especially when all other things being equal (conformant) most images have
some alternative text, be it good, bad or indifferent.


> 
> I have given these proposals serious thought and I have listed the
> technical reasons for rejecting those proposals. This is the same
> process I have followed for all the other issues in the spec so far.

I beg to differ - regarding the reserved values/magic tokens question, you
have not provided *ANY* technical reason in the 4 responses cited above, but
rather only your opinion and conjecture.

> 
> I don't know what else you want me to do, short of ignore the
> technical reasons I've listed and go with one of the other proposals
despite my
> conclusions.

Your conclusions on not based on use-case scenarios - none have been
formally provided or tested.  Your conclusions are not based on empirical
data or survey - again none has been provided.  I have not read anything
"technical" in any of the responses outside of the fact that you believe
that the current proposal is "cleaner", which from an engineering
perspective may seem good, but does little to really affect accessibility
concerns.

> The problem is that if you want me to ignore technical
> considerations and go with your solution, I end up with a propblem
> when people in an opposing camp ask me to ignore technical considerations
> and go with _their_ solution. How do I pick which solution to follow?

Listen to the W3C experts, as *mandated* and "...make @alt on <img> an
across-the-board requirement (even if sometimes
it has the value of &quot;&quot;)"; and if a new scenario exists (as you
suggest), then work within the recommendation to find a workable solution
that does not contravene current recommendations by said experts - or push
it back to said experts to propose a solution, rather than go with your
*opinion*.

JF

Received on Thursday, 17 April 2008 00:47:25 UTC