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

Ian Hickson wrote:
> namely that there isn't any useful alt="" text
> available in the first place, despite the image being the whole point
> of the page. 

Actually, this would probably be more accurately described as "there isn't
any useful alt="" text PROVIDED in the first place".  All images *could*
have useful alt text, if the tools allowed authors to provide it, and sites
like Flickr bothered to try and allow content creators to add as much.  What
is useful?  Who decides this?  What makes "Photo 27 from my Spring vacation"
not useful? It might not be great, but my friend James (a JAWS power user)
could go to a Flickr page and search for that, and then download it (so that
somebody could describe it to him, of he could send it off to Café Press to
have a T-shirt printed, or...)  Currently, screen reading technology can
process alt="something" easily, even if it isn't great.  Removing alt, and
asking AT to come up with another means of "heuristically" dealing with an
author shortcoming is, frankly, disheartening and wrong.

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

Says who?  At some levels, this too is the crux of the matter.  

You are a big "data" guy, show us the stats to support this claim. Who has
been queried on this?  Where is the survey, how statistically valid is it?
These are legitimate questions that are always being ducked.  

You continually tell people like me that you need the use cases, the proof
in the wild, the hard data to back up our claims; that "gut" alone is not
enough.  I posed this very question in the WHATWG blog, and have yet to get
an answer:  you might believe that the alt text currently generated by
Flickr is useless (and granted it ain't great), but how many blind users
concur with your point of view? If you have the right to insist that we back
up our claims, then surely we have the same right to ask you to back up
yours.

> and letting the UA apply
> advanced heuristics designed by accessibility experts.

What heuristics? Hocus Pocus, abracadabra? It's a great theory, but provide
specifics:  nothing can conjure up "intent" or "meaning" without some kind
of author support/author input - currently heuristics are supplying
"filename, tags, title, comments, or EXIF data"; if it is going to be better
than that, how?  Telepathy?  Until this can be defined and proven to work,
"excusing" sites from having even marginally useful alt text is wrong.

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

Fair enough, but who will this be enforced by on the web?  You might have a
"medical condition" that excuses you from wearing a sealt belt, but if a
Highway Patrol car pulls you over, condition or not you'll get a ticket -
which you will then need to contest in court: the cop is not the judge.  How
will you be able to transcend this to the web?  There are always exceptions
to a rule, but making it too easy to invoke the exception dilutes the rule. 

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

And the proof of this claim can be found at:__________________ (?)  Granted,
it does little to aid accessibility, but you emphasize *harmful* - please
back this up.

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

How and why?  Video capable agents will see and process the <video> "tags",
non-supporting UA's will ignore unknown elements and process what they know.
There is a long and well understood tradition of this in HTML that goes back
to the days when I was authoring in notepad: <noscript>, <noframes>,
<embed> within <object>: you want a paved cowpaths, there's plenty of
cowpath with this concept.  And if you want to "download" and save the
video, here again there is a long tradition of "right-click >> Save As" (or
equivalent depending on your UA and OS).  Again, more cowpath.

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

You mean like provide a second paragraph that allows users to download a
video?... That's my experience too.


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

And so you honestly believe that authors will specifically and deliberately
write:


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

...yet at the same time are incapable of specifying a URI (once) for a media
file and have the WYSIWYG authoring tool insert that path into a compacted
code piece like:

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

(and I appreciate the fact that the second time you typed that you removed
the autostart - thank you!)

Ian, if well informed content creators want to truly ensure access to the
video resource, then yes, an "in the clear" link is great, but now you are
dreaming if you believe most will do so... Where is the ROI in that?  And
where, within the <video> element is the means for 'alternative' content if
you cannot process a video file - period?  What of the deaf-blind user?  We
need text transcripts that should be programmatically processable by UA's
and AT tools without a lot of user intervention: and the ability to encode
this needs to be easy for authors to do from their authoring environment.
This means that the element should be able to take a multitude of
attributes, attributes currently "missing" in the spec.  

These are the types of things we need to be seeing, not suggestions that
because it's hard to conjure up alternative text for Flickr uploads,
sometimes alt text can be left out. 


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

Internet Explore 8 might support <video>, but that means absolutely nothing
to a JAWS user using JAWS 9 with IE8.  Or a deaf user who can see just fine,
but can't hear the audio track of your video being played in Opera 11.  How
is <video> going to address their needs?  Directly, not obtusely, or by
*expecting* authors to provide:
   <p>Download the transcript at: bar.html</p> or 
   <p>The descriptive text for this video can be found at: foo.html</p>


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

OK, so what in the element of <video> *directly* associates my
"transcripts/hickson_video.html" file to the media resource, so that the UA
(or an Adaptive Technology working in conjunction with the User Agent) can
*transparently* access the alternative presentation?  Where/what is the
hook?

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

...because reminding content creators that "a picture is worth a thousand
words", but if you're blind you need those thousand words, needs to exist.  

Ian, in my earlier post, I made the distinction between "Universal Access"
(<a href=""> or <p>) vs. "accommodation" (Longdesc=""); either you get that,
or you don't, but that is the reason.  There may not always be a need, but
when it exists, it needs to be addressed (as with headers/id).  A bar graph
or pie chart are two obvious examples... They are visualized often *because*
putting out the "text equivalent" will take up "...too much screen
real-estate".  That currently User Agents do a lousy job of processing
longdesc is not the fault of longdesc, but rather the UA s.  It has never
gotten a fair shake. 

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

Yes, I have seen the footage.

> 
> Just because something is designed to help the blind, or the deaf, or
> whatever, doesn't mean it works.

And this also holds true for permitting some images to not have alt text, or
for <video> element to not have alternative fallback attributes, etc. as
well.


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

When implemented properly, and when using tools that process longdesc
correctly, Josh's video demonstrates a practical, measurable gain to
accessibility.  I've seen nothing to counter that...

Yes, you can scour Google and find any number of webpages that don't do
longdesc correctly, but that's not the point - I can find a whole raft of
pages that just cease to work in Firefox because they were "created" to work
in Internet Explorer - there is no excuse for crud, no matter how or why.  I
thought that one of the points of HTML 5 was to get away from that.

> It makes no
> sense to wave talismans around that make us feel better if they don't
> actually result in real improvements.
> 
> 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.

Yes, this is very clear.  You don't understand why I am angry, why Tina
Holmeboe (and others) walked away in frustration, why Jukka Korpella, Joe
Clark, Jim Thatcher and other published web accessibility authors are
missing in action, why T.V. Raman is conspicuous by his absence, why Laura
Carlson invested countless hours and enormous effort to rally support for
headers/id (culminating in an official response from WAI P&F), why Roger
Johansson left and has cautiously returned to the WG, why Greg Rosmaita and
Philip Taylor and Leif Silli also pound away at you, and on and on and on.
You have your vision, and deviation or questioning of that vision is
suspect.  

Under most circumstances, we could probably agree to disagree, have a beer
and get on with it (I suspect you are a decent guy, and I am not always
angry - we both live in the Bay Area and I'd gladly buy you that beer);
unfortunately with the next gen authoring language on the line, the stakes
are too high and those of us who disagree with your proposals will continue
to work to negate aspects of them, or insist that what you dismissively
refer to as "talismans" remain because we know that done right, they can
work and assist the disabled.  Don't take it personally.

And for what it's worth, I have worked hard to keep this note focused and
non-combative (and away from "working" lists): I have asked you for hard
answers to specific questions, but without those answers you are simply
asking us to do what you refuse to do for us - take your word on it.  That
doesn't cut it.

JF

Received on Thursday, 6 September 2007 06:40:22 UTC