RE: Flickr and alt

Jon Barnett wrote:
> 
> Forcing content on a user-generated content web site, by law, to meet
> a set of accessibility standards is asinine and frightening at the
> same time. There are plenty of countries that would never go for such
> a thing.   

Please name 2.  

Most if not all countries in the "Western" hemisphere have legislation which
protects human rights and the rights of individuals that may be
disadvantaged due to a disability.  These same countries have currently
adopted or reference the W3C's WCAG 1 as the de facto "standard"
[http://www.w3.org/WAI/Policy/], and the first checkpoint explicitly states
that all images must have alternative text.

WCAG 2's language is less specific (in that it is not a tick box item),
however it's intent and stated goal is exactly the same - the information
needs to be perceivable to all.

So while the "law" has yet to be tested, the requirement exists today.
Target.com's biggest problem is/was that images did not have appropriate
alternative text, and they are being sued (class action!) under ADA and not
section 508 - a telling a real point: accessibility is deemed to be
protected by law in the US (at least).  Politically you might argue that is
wrong, as is your right in a democracy, but it is currently the way it is
now, and any web site that chooses to ignore this fundamental fact does so
at it's own risk - including Flickr and/or any other photo sharing site.
The fact that Flickr currently does not seem concerned by the lack of
ability to insert real alt text is a problem - never mind whether up-loaders
want to do so or not.  *That* fact (to me) would lose Flickr their day in
the court (if/when that day comes).

> 
> Smoking laws are a poor analogy.  A better analogy would be fining a
> restaurant for not forcing everyone in a restaurant to use sign
> language while they talk.  

No, that is not a correct analogy either.  It would be closer to fining a
restaurant that had a sink in the staff washroom without having running
water or soap.  *That* fine/law is there to protect everyone, not just a
minority, and the fine would be for not availing themselves of what is
obviously a common sense protocol.  Will this guarantee that all staff
members will wash their hands?  Never.  But not insisting that they do, and
not providing the means to do so is what is asinine, and is more to the
heart of this discussion.

The inclusion of alternative text with an image is not about a minority
"fix", and this discussion continues to revolve around Flickr's inability to
find an equitable solution to a real problem.  It also revolves around the
issue of whether or not content should be deemed "conformant", when clearly
to many it is not.  If it walks like a duck, and quacks like a duck, calling
it a kitten is plain stupid.

IMAGES ON THE WEB WITHOUT SOME ALTERNATIVE TEXT ARE INCOMPLETE.  To pretend
that sometimes they are otherwise, simply because of a question of volume,
or due to an undeclared, undefined *need* to be conformant (and what exactly
do they gain by that?) reminds me of the fable of the Emperor's New Clothes.
(This transcends simply the @alt attribute and speaks to a broader issue,
BTW)

> 
> There is absolutely NO chance I would ever upload 100 photos to a web
> site and write a sentence of text for each picture only to have that
> sentence be invisible to 99% of the public.  If I'm going to write
> 100 sentences, they're going to be captions viewable alongside a
> photo and not alternate text for a photo.

Fair enough then.  Ensure that the spec is written so that when your
captions are <em>directly and programmatically linked</em> to that on screen
caption, that they *then* can be deemed conformant.  Your comment has value,
but you need to think through the full ramifications of the statement.  By
adding the caption, you are ensuring that those who cannot see the image can
glean the meaning, which is what this is really about.  Insisting that
either/or be present (@alt or @caption) to be conformant is not
unreasonable.  Suggesting that:

<body>
<img src="" />
</body>

...should somehow be considered complete simply because you repeat it 100+
times is a hollow argument, and not based upon any kind of logic.  Should
browsers be "allowed" to render this kind of cruft?  Some say yes, others
say no, but in either case it should not be deemed "conformant".
  
> 
> I'm also sure at least 50 of those images wouldn't get captioned at
> all because I simply don't have the time.  If Flickr suddenly
> required me to caption all 50 of those images, I would just insert
> junk into the textbox for the caption or I would find a photo sharing
> site without such a silly requirement for me, as the user.  

This is your choice.  This is not a reason however to somehow excuse these
types of sites from providing the appropriate ability to ensure that
alternative text is present, nor a justification to absolve these sites from
this responsibility so that they too can claim "conformance" even when they
are not.  They are not. 

Meanwhile, Eric Eggert wrote:
> 
> What we really need is imo not yet another sub use of the alt
> attribute but a way to connect those informations to the image and
> indicating that there is an image in the page even if the alt text is
> not present.
> 
> I'm a huge fan of <figure> and <legend> for these use cases.

Eric has it almost right.  However, as I read the current Draft, there is no
specific requirement for these attributes to be present (in the absence of
appropriate @alt values) to be conformant.  While the draft offers us:

  <figure>
  <img src="1100670787_6a7c664aef.jpg" alt="{photo}">
  <legend>Bubbles traveled everywhere with us.</legend>
  </figure>

It is unclear however whether: 

  <figure>
  <img src="1100670787_6a7c664aef.jpg" alt="{photo}">
  <legend></legend>
  </figure>

...would be conformant, as well as:

  <figure>
  <img src="1100670787_6a7c664aef.jpg" alt="{photo}">
  </figure>

I suspect that most accessibility advocates could accept the first instance
(I have in principle), however the second and third instances are
effectively useless and should not be deemed conformant.  I do not see this
specificity in the draft spec, my only real issue at this time.

JF

Received on Tuesday, 19 August 2008 00:37:13 UTC