Re: What now ALT?

On 10/8/07, John Foliot <foliot@wats.ca> wrote:
> Jon Barnett wrote:
> > Things like this should not affect the decisions of this working
> > group.  Universality and accessibility are still design principles of
> > this group, and those design principles will affect the decisions of
> > this group.
>
>
> Fair enough, but they are also working on a principle of avoiding "bloat",
> and of "paving cowpaths".
>
> We now have a real world situation (cowpath) that is suggesting, from the
> perspective of accessibility, that having images with *no alt text at all*
> will be deemed inaccessible, and quite possibly, illegal.  Exactly why
> should those considerations not be taken into account?
>
> The current specification is suggesting that images, under certain
> circumstances [1] can exist without an alt value, and still be conformant.
> Yet, if the law suggests that this is illegal, we will have a possible
> scenario that, while technically conformant, will never (should never?)
> exist, for fear of legal ramifications.  So why bother?  Who is going to
> take advantage of this?

I refuse to accept the premise you're asserting here.  If markup can
be conformant and universally accessible without the @alt attribute,
in what world should it be illegal?  That premise begs the question:
- HTML 4 requires @alt for accessibility
- The law requires accessible markup and therefore @alt
- This group questions if markup can be make perfectly accessible -
and even more so - by not including @alt in certain situations
- Your premise is that it would be illegal.  It begs the question
because law only requires accessible web pages.


> I have floated the idea of a reserved value for alt (I suggested alt="_none"
> [with the underscore]) as one possible alternative for instances when
> automated tools do not allow for author supplied alt text.

I entertain those ideas as well.  I don't want to get into that
theoretical solution under this subject heading, but I will say that I
can today write perfectly accessible web pages sometimes using a null
alt (icons that are accompanies by text: an icon of a house followed
by the word "Home") and missing alt (a photo in a gallery that is
perfectly accessibly described by the heading on the page and a
paragraph of text following the image, such as in an application I'm
working on)

> Probably, but they will be
> making a conscious decision to 'abuse', rather than skate by their
> responsibility by pointing to a spec and saying "see, it's allowed".

The exact same argument can be made regarding any abusable markup.  I
can write a web page using nothing but DIV elements styled by CSS, but
that's not very accessible sense a screen reader won't make much sense
of the document structure.  I could use BR elements to separate all my
paragraphs and claim "see, it's allowed", but that's not good markup.
See my previous message: markup that can be used can be abused.  It's
a fact of life that not all conformance requirements are
computer-checkable.

>...
>
>
> > Regardless of what markup is used, we all agree that documents should
> > be universally accessible.  No one has suggested otherwise, and I
> > really hope this subject was not raised to imply that anyone is
> > against accessibility.
>
> Well Jon, there are enough people out there that are concerned about the
> direction that the specification is taking to call that statement into
> question.

And that's nothing but a strawman argument to elicit an emotional
response. While your following statements have merit, saying that
anyone is "against accessibility" is just a personal attack instead of
actually discussing the merit of specific proposals.

> Protracted 'discussions' regarding the possibility of dropping
> accessibility features (@headers/@id, LONGDESC, etc.), based on nothing more
> than "numbers", makes feeling secure about universal accessibility less than
> a given.

The idea is that there much be a better way to provide that
accessibility without @headers or @longdesc.  In the case of @headers,
@scope seems to works just as well semantically (but doesn't appear to
have the best UA support).  I haven't followed that discussion as
well.

@longdesc has poor support outside of AT, so it rarely gets used -
simply putting the <img> inside an <a> element usually serves the same
semantic purpose and works universally.

> Keeping presentational elements such as <i> and <b> are hardly
> beacons of accessible development, but rather of an acquiescence to the fact
> that in 2007, some content creators still don't care.

The draft attempts to assign semantics to these elements.  It's all
still debatable and not a foregone conclusion.

Also, some UA's built-in WYSIWYG editors use those tags, and I don't
know how quickly that will change.

> Newly minted
> concoctions such as <canvas> [http://tinyurl.com/2kbu2x] also seem to be
> missing some key considerations for those users who cannot "see" the canvas
> (the spec speaks of "fallback" content, but does not state how to implement
> this content - as well, if the canvas element must out-put a PNG file [as
> the default], where is the requirement for alternative text for *that* image
> within that element's spec?)[2].
http://www.whatwg.org/specs/web-apps/current-work/#canvas

The content inside the <canvas> element is its fallback content.
Right now it's defined as inline-level, which would exclude <p>
elements, but include <ol>, <ul>, and <table> elements.

This is very similar to the <object> element.

If you have an issue with this, it would be a good discussion.

> I'm not saying that the Working Group are
> against accessibility, but some of the emergent suggestions and
> recommendations are not exactly pro-accessibility either.

If we can define markup that has semantic meaning and does something
useful in rich, graphical UAs, and is accessible, authors will be more
likely to use it.  Markup that does nothing visible except in AT will
get used less.  It makes the author's life easier when writing plain
old semantic markup gets him 99% of the way to an accessible
application.

>
>
> > It is possible today to create an HTML document that meets all
> > programmatically computable conformance criteria and still completely
> > fail at accessibility.  This will always be the case - markup that
> > can be used is markup that can be abused.  Since some countries are
> > extending their "disabled rights" laws to include web page markup, it
> > follows that you can still write a web page that passed an HTML
> > validator but still breaks the law of your land, and again, this is
> > independent of the alt attribute itself.
>
> No argument there, but again, why bother?  On one hand we have possible
> accessibility features being dismissed due to lack of use (LONGDESC), and on
> the other hand we have the newly emergent possibility that images can be
> conformant without any alt value (when quite possibly no-one will ever avail
> themselves to it for fear of legal entanglements). What problem then,
> exactly, is being solved? This needs to be re-thought.
>
>
> > I seriously doubt this decision could be construed to legally codify
> > the HTML alt attribute.  If HTML 5, 6, or 7 can be conformant and
> > accessible without an attribute named "alt", no judge should care or
> > would care.
>
> On the day that this can be shown to be viable, I will back you 100%.  But
> until a better way of ensuring that images have a chance of being made
> accessible that transcends the requirement of the alt attribute, it's the
> best we've got, and to suggest that moving forward it can sometimes be
> optional is just wrong.  You want to replace it with something better?

Well, in the case of the photo gallery, my "something better" is a
line of text to title the image and a box to describe it.  The "title"
appears on the page as a heading or as the "title" of a link.  The
description appears on the page with a full-size version of the image.
 I don't expect to put either of those in the @alt attribute - it
would be redundant.  I don't expect to prompt the author for a third
box of text - he's already described the image enough.  I just expect
a screen-reader to announce the present of the image and read the
description.  I'll use whatever markup is valid and accessible for
this, but requiring the @alt attribute here just seems religious to
me, and alt="" seems dishonest.

--
Jon Barnett

Received on Tuesday, 9 October 2007 03:09:04 UTC