[html4all] from hixies log - Fire, a two-hour weekend, accessibility, and other rants

[John Foliot]

Ian Hickson wrote:
> 
> As the spec says: "the alt attribute should be included, with a useful
> value, if at all possible". 

But *should* is not strong enough.  It will be too easy for developers to
wiggle though this loophole.  It's like saying that seatbelts should be
worn... But instead we have seatbelts *must* be worn (in California it's
"Click It or Ticket"... You know that)

> It goes on to say that "since some users
> cannot use images at all (e.g. because they have a very slow
> connection, or because they are using a text-only browser, or because
> they are listening to the page being read out by a hands-free
> automobile voice Web browser, or simply because they are blind), the
> alt attribute should only be omitted when no alternative text is
> available and none can be made available". There's no point going any
> further than that -- in the cases where no alternative text is
> available and none can be made available, requiring it will only make
> pages non-compliant, it won't improve accessibility at all.

It will be non-compliant only if alt="" is non-compliant; given the
gazillion web pages that currently have alt="", backwards compatibility will
insist that this remain viable.  Thus the net effect will simply be that a
mandatory attribute is made optional.  Too easy to abuse!

> 
> 
>> Wrong!!! Content *MUST* (not may) be provided inside the video
>> <http://www.whatwg.org/specs/web-apps/current-work/#video1>  element
>> so that older Web browsers, which do not support video
>> <http://www.whatwg.org/specs/web-apps/current-work/#video1> , can
>> display text to the user informing them of how to access the video
>> contents.
> 
> So you're saying that the following should not be compliant?:
> 
>    <p><video src="monkey.mpeg" controls autoplay></video></p>

Audio tracks should *never* be allowed to autostart (conflicts [you] with
[are] screen [at] readers [the] - but [video] I know [page] that we'll never
completely win that battle...) but IMHO, <video src="monkey.mpeg" controls
autoplay></video> should be non-compliant.

>    <p><a href="monkey.mpeg">Download the Monkey video</a>.</p>

I would think that instead, something along the lines of:
	<p><video src="monkey.mpeg" caption="path to text file"
link(sic)="path to alternative option(jpg or png?)"><a
href="monkey.mpeg">Download the Monkey video</a></video></p>

...could address multiple needs.  Providing the link to the video external
to the <video> region presumes that the end user will be able to consume
video, in the same way that concert promoters would presume that all
attendees would be hearing the music...

(this also pretty much reflects on the current "cowpath" of <object> and
<embed>)

> 
> 
>> "User agents should not show this fallback content to the user"
>> (Why not? How does this help anyone?)
> 
> Compliant HTML5 user agents must not show the fallback content to the
> user because compliant HTML5 user agents must support the <video>
> element, and thus the fallback content (intended at legacy user
> agents) is not appropriate for HTML5 user agents.

This addresses legacy UA's, but what of AT tools?  Given that they often
integrate themselves with current UA's (JAWS uses IE or Firefox) - what
then?  The current suggestion is only half of a solution.

> 
> The deaf might not be able to hear the video, but they can still see
> the video and watch the subtitles. Why should they be *prevented*
> from seeing the video at all, which is what would happen if the
> fallback was shown instead?

Subtitles?  Where in
<http://www.whatwg.org/specs/web-apps/current-work/#video1> is there
reference to subtitles/captioning?  How, in <video> do you select to have or
not have captioning/subtitles?

Deaf users will presumably be using the same visual browser as the hearing,
so, presuming they will be using a "compliant" browser...  I don't get how
they would be disadvantaged

The "fallback" is for when part of the multi-sensory presentation is
restricted, either due to physical limitations of the user (blind, deaf), or
by situational considerations (such as a noisy environments require
captioning), etc.  None of these considerations are apparent in <video> (and
yes, I know, it is under review: however...)


>> 
>> Contrast this against suggestions to make alternative text optional
> 
> It isn't optional.

You just said, "...alt attribute should only be omitted when no alternative
text is available..." 
That sure reads like an option to me.  Given that "...Duh...I can't come up
with alternative text, so I'll simply not include any..." will be made a
viable choice, the possibility of abuse exists.  This may seem like a
legitimate option from an engineering perspective; it is a lousy option
(read Non-option) from the social responsibility perspective.  I've called
this a Pandora's box before, and will continue to do so.


> 
> LONGDESC is hidden from most users -- why shouldn't they get access
> to the long descriptions? 

EXACTLY!  But currently it is not in the draft, and "stats" of 0.06% being
touted on the IRC channel in reference to the "current sorry state of
LONGDESC" suggests that it will be abandoned.  It should be in the draft
*now*, but open to exploration/discussion - protests of 'code-bloat'
notwithstanding.  Until there is an equivalent or better solution, failing
to have the status quo (as a bare minimum) in the spec is seen (rightly or
wrongly) as a backslide on accessibility.  Why do you guys fail to see this?

> Far better is to make the long descriptions
> available to everyone, not just to the blind,

Right, so the spec must say: LONGDESC - compliant UA's will provide a means
for users to access this information.  Currently the silence is deafening!

> 
> I think you are trying to read the opposite direction into the spec,
> but I don't see what you describe as being there.

Ian, read this again.  Read my previous note.  You are applying Universal
Access principles, but the "accommodation" aspect is being left behind (at
least this is the perception).  I might be one of the noisiest, but you have
to know I am not the only one who feels this way. I want HTML5 to work, I
want it to move the web forward (contrary to what some of the WHATWG folk
might think). But I want it to move forward for all, and walking away from
any of the minor gains we have made to date is a non-starter: if you can
improve what we have today, great, but moving backwards (which often appears
to be the case when things like LONGDESC are "not yet included") will be
fought for, long and hard.

JF