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

[Ian Hickson]

On Wed, 5 Sep 2007, John Foliot wrote:
>
> 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.

Per RFC2119, "should" means that there may exist valid reasons in 
particular circumstances to ignore a particular item, but the full 
implications must be understood and carefully weighed before choosing a 
different course. In this case, the spec is clear as to what those casse 
might be -- namely that there isn't any useful alt="" text available in 
the first place, despite the image being the whole point of the page.

What should flickr do? They have no alt text available. Anything they add 
(filename, tags, title, comments, EXIF data) would actually be _worse_ 
than simply not having any alt text and letting the UA apply advanced 
heuristics designed by accessibility experts.


> 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)

Seatbelts are a great example. Seatbelts in California are required... 
*except in certain situations*. For example, employees of the post office 
doing mail delivery are exempt while they are delivering mail. It also 
doesn't apply to people in ambulances. Or to people with physically 
disabling conditions or medical conditions which would prevent appropriate 
restraint in a safety belt.


> > 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

Specifiying alt="" on a critical image is actively *harmful* to 
accessibility. That's exactly what we *don't* want to encourage!


> > 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>)

I think it is ridiculous to say that this:

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

...should be non-compliant, especially if the proposed alternatives is:

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

...because the latter is less useful to those with video-capable browsers.

This is especially true because most authors wouldn't do anything that is 
specifically for the blind or deaf (because they wouldn't think about 
them). We need to encourage practices that authors will do to help the 
majority user that *also* help the minority user, not practices that will 
be ignored because the author doesn't see a significant ROI.


> >> "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.

I don't understand what you're saying. Either they support <video> or they 
don't.


> > 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?

3.14.7. The video element: "User agents may allow users to view the video 
content in manners more suitable to the user".


> How, in <video> do you select to have or not have captioning/subtitles?

That's up to the UA.


> > 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.

Why is longdesc="" (for blind users) better than <a href=""> or <p> (for 
all users)?

The overwhelming majority of the uses of longdesc="" (and there aren't 
that many to start with) are bogus. Where's the evidence that *users* are 
actually using it and finding it helpful?

So far as far as I can tell we have one usability study video:

   http://www.cfit.ie/html5_video/final/HTML5WG_longdesc%20(1).wmv

...and if you watch it you'll see that the blind-from-birth JAWS 
power-user in the study didn't even know longdesc existed before it was 
shown to him in the study.

Just because something is designed to help the blind, or the deaf, or 
whatever, doesn't mean it works. I do not care at all about adding 
features to help users if those features don't work. We need actual 
practical measurable gains to usability and accessibility. It makes no 
sense to wave talismans around that make us feel better if they don't 
actually result in real improvements.


> > 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.

I don't understand why you are fighting. I don't even understand who or 
what you are fighting, or what you're fighting for.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'