RE: Is Flickr an Edge Case? (was Re: HTML Action Item 54)

Maciej Stachowiak wrote:
> 
> I am not sure it is in good taste to liken accessibility markup to
> being in jail. That being said, the current draft allows alt to be
> omitted based on the nature and context of the image (i.e. does the
> person or tool generating the HTML know what the image is), not based
> on the nature of the site.

Oh-My-God! I will give you the benefit of the doubt and presume you are
unaware of the "expression" I used - in this case a reference to the board
game Monopoly, whereby you get a card or pass so that you need not suffer
consequences (sitting out your turn), and instead allows you to continue to
play as if nothing is/was wrong.  It has nothing to do with going to jail
(any more than landing your player token on the second corner of the
Monopoly game board), and has everything to do with individuals or entities
skirting their responsibility by invoking the "photo-upload" scenario,
thereby avoiding doing what the specification states they must do, except in
rare (or now apparently not so rare) circumstances.  The fact that it has
evolved from rare instances to some of the most popular sites on the web
today in the space of less than a dozen emails simply serves to illustrate
the severity of the potential loophole.

> 
> I don't believe anyone has proposed site-based special status.

No, instead it is by instance - and now it encompasses millions of web
pages, by your own calculations.  And yet some want a spec that, by it's
writing, practically encourages these sites to avoid adding @alt values -
they don't need to, they are photo-upload sites:

"In certain rare cases, the image is simply a critical part of the content,
and there might even be no alternative text available. This could be the
case, for instance, in a photo gallery..."
[http://www.w3.org/TR/html5/#the-img]

(By my exact reading, this suggests that a photo-gallery site might have
this "special status" - these are not my words, they are directly quoted
from the draft spec.)

> 
> Regardless of the markup used, it is not reasonable to expect an
> ordinary person to provide alternative text when bulk-uploading
> thousands of vacation photos. 

In the real world, I know of nobody who takes "thousands" of vacation
photos, and then bulk uploads them in one single instance.  Ian once asked
if the number was an issue, knowing full well that it is not.  Is there a
magic line: upload less than this number and you *must* include @alt, but
exceed that number by 1 and you no longer have to?  This is specification
language?  Give me a break.

> In the real world we accept that it is
> reasonable to place accessibility burdens on public accomodations,
> such as places of business, sidewalks, or public broadcasts, but not
> on private individuals.

Please stop talking "down" to me, I am not an idiot - I am all too aware of
the responsibilities of entities vs. individuals in regards to their duty to
accommodate - probably more so than you given my decade long involvement in
this field.  None of the /technical/ reasons provided to date are good
enough justification for making the @alt attribute optional - they only
justify avoiding adding textual information to the image in question.
Authoring tools should *always* present a means to add this information, and
if the value is not supplied than that outcome rests with the content author
- why this would affect a requirement of a technical specification is beyond
me.  There are many many rules that are abused, which should not be
justification for omitting the rules. Client side scripting can be "abused"
by authors to the point of destructiveness: should we then roll back the
clock and remove the ability to provide client side scripting?

> That is the legal and moral standard that most
> accept. The remaining question, then, is what to do when a user does
> not provide such information, and how the spec can best encourage
> whatever is the best practice in this situation.

By closing a loophole that can be exploited.  Perhaps by determining a value
or other means to indicate that the content author chose not to provide
textual information, rather than just not even attempting.  

It has been argued that <img src=""> implies that there is no text value
available, but that is not true:  there may very well be text alternative
available that either was consciously not provided, or that an authoring
tool did not allow to be provided (current Flickr interface for example).
There may in fact be *many* reasons why a content author can not, did not,
and/or will not provide a value for @alt.  None of these reasons however
should be justification for *not* providing this information, and more
importantly, none of these reasons are based in a /technical/ ability to do
so, they are all author conscious decisions.  Why user choice in this
scenario should govern the technical spec, yet in the client side scripting
scenario not, has not been explained or justified.  Is it because malicious
JavaScript can still be authored to be compliant?

> 
> Number of people complaining does not affect the truth or falsehood of
> a proposition.

The very same statement can be applied to the claim that alt="" can harm
accessibility.  You are rehashing old business Maciej - move forward or move
on.

> 
> I personally prefer the noalt attribute, although it technically
> "leaves out the alt". I think it has a small advantage (harder to
> accidentally forget to indicate anything about the status of the
> image), but also some disadvantages. Which choice is best should be
> decided on technical merits, not whether the three letters A-L-T
> appear in that order, as if that were some sort of magical talisman
> automatically granting accessibility.

Then let me be extremely clear here: an image without a textual alternative
is incomplete to many users.  How you provide this is secondary to the fact
that it must be provided.  Allowing an image to exist, to be conformant,
when it is incomplete is wrong.  Writing a specification that allows, neigh
forgives, this situation is also wrong, and further has not been
/technically/ proven to be a good idea.  To date, @alt has been the method
that has allowed content authors to directly link this information to the
image.  If you have a better way which does not involve the letters A-L-or T
than by all means speak up.  If noalt is the way forward, then put forth the
pros and cons and let's talk about that - if it emerges as the better way
forward then let's add it to the specification and close this debate.  If
reserved values is the way forward, then debate the pros and cons there and
once again seek closure.  The accessibility community however has been
pretty consistent in their response to date: <img src=""> alone should not
be considered conformant - full stop.

> 
>> Once the WG comes to the conclusion that optional @alt as proposed
>> is a
>> non-starter and starts really discussing a different approach, this
>> debate will continue to churn and go round-and-round 'till the cows
>> come home. There have been many off-line comments within the working
>> group about "dogma" emerging from the accessibility camp, but the
>> responses from the other side are equally immobile and dogmatic -
>> simply stating that <img src=""> will improve accessibility will not
>> make it true, no matter how many times you say it.
> 
> Ironically, a number of proposals other than simply omitting alt have
> been made, including by the Editor, and they have been completely
> ignored by the accessibility camp, as far as I can tell.

Really?  As an avid follower of *all* of the postings to both the
public-html and wai-xtech mailing lists (two official means to discuss this
topic) I have not heard a peep from Ian.  If these proposals have surfaced
in your back-room IRC channel or on the what-wg mailing list than I'm sorry,
I read neither as they are outside of the official W3C process.

I *am* aware of a number of alternative proposals on the W3C wiki
[http://esw.w3.org/topic/HTML/IssueAltAttribute#head-27468e7ee9afd1f9e07186c
8d74f0b0168b3975a], and have in fact requested adding at least 2 entries to
the list (suggestions by others), including one that *did* provide a
scenario that could exist with an optional @alt ("...required except when
the element is a child of x...") - not that I agree to it entirely but I do
leave open the possibility, unlike some of you who insist that the only way
forward is with an optional @alt.  There are also 2 separate alternative
ideas there that I suggested in earlier emails, and they have been quoted
almost directly from those emails:

* "Reserved value for alt like alt="_none"..."
* "Explicitly note and provide as many other ways of providing alt text as
possible..."

Other accessibility advocates have also proposed alternative solutions,
including Steven Faulkner and Leif Halvard Silli; again noted in the wiki
above.

What constructive ideas have *you* contributed towards a better solution?

JF

Received on Tuesday, 27 May 2008 17:38:20 UTC