Re: Flickr and alt

Gez Lemon writes:

> I don't think it's wise to base conformance requirements around the
> limitations of validators.

Absolutely.

> Without alt text, images won't be perceivable to some people. If an
> author decides not to provide alt text for whatever reason, that's
> fair enough,

Why?  In circumstances where the author could have provided good alt
text but is merely feeling lazy or ignorant or similar then I'd say that
isn't "fair enough".

> but I don't understand why that should be considered compliant when
> the structure isn't sufficient for some people.

There are multiple 'authors' involved in creating content for many
pages.   For a page on a photo-sharing website there is the website's
development team, who provide the structure, and the user who uploaded
the content (photo plus related information).  There are several
scenarios in which these could be combined:

 1  The site developers don't even try to meet the standards.

 2  The site developers try to meet the standards, and have an option
    for a user uploading a photo to provide alt text.  If no text is
    provided then the page is published without any.

 3  The site developers try to meet the standards, and require alt text
    from a user uploading a photo.  It declines to publish a page until
    alt text is provided.

 4  As for 3, but the site also provides a feature for bulk-uploading
    multiple photos without examining each one individually (such as
    straight from a camera which doesn't provide a way of providing alt
    text when a photo is taken).  In this case photos are published
    without alt text.

 5  As for 4, but the site still insists on bulk-uploaded photos having
    alt text provided before they are published.

Clearly scenario 1 is bad; it should not be condoned by HTML 5.

Scenario 2 is also bad, in that Scenario 3 is the better way of dealing
with this.  No previous HTML standard has permitted scenario 2, and
there seems no reason to start allowing it now when scenario 3 is
plausible as an alternative.

Ffrom an accessibility point of view, scenario 5 is preferable to
scenario 4.  But there seems to be consensus in this thread that
scenario 5 is not a valid business model, that potential users would
avoid the service in favour of a rival which implements scenario 4.

So it would be pointless for the HTML spec to condemn scenario 4 as
being the 'wrong' way of doing things, when it doesn't have a better
approach to suggest.  For that business model, scenario 4 is the best we
can hope to get.

We could, of course, decide that that business model should not be
encouraged, and therefore not support scenario 4.  But surely the HTML
spec should be looking at the validity of mark-up, not of business
models?

Given that there are businesses offering scenario 4, the HTML spec
should tell them how their content should be marked up.  If they do what
the spec says then they have, by definition, conformed to the spec.

If the spec doesn't address scenario 4, then there's no way to
distinguish scenario 4 from scenario 1.  That is, whatever the site
does, their content cannot possibly conform.  So why should they try at
all?  Why should they be bothered about the bits of accessibility they
can do (such as headings and navigation marked up as such, and alt text
on site-provided images and images uploaded singly)?

If we would rather a site chose scenario 4 over scenario 1 then the spec
should state that.

Smylers

Received on Tuesday, 19 August 2008 10:19:06 UTC