Re: Investigating the proposed alt attribute recommendations in HTML 5

Simplest is best, get too many and that any spec that evolves moves forward 
along well established lines to improve the ability to put power in the 
hands of users.  I would hope that the burden on authors would be lessened 
as well but not at the expense of the user experience.
beeps and boops in there and I get lost.  Most of what we need, we already 
have if markup is propperly used.  I can use html verballizations in JAWS to 
render what of images I want and can get quite sofisticated about it.  I 
only see that the user experience can be improved if people use the Markup 
as it is intended
----- Original Message ----- 
From: "Henri Sivonen" <hsivonen@iki.fi>
To: "David Poehlman" <david.poehlman@handsontechnologeyes.com>
Cc: "Steven Faulkner" <faulkner.steve@gmail.com>; "HTMLWG" 
<public-html@w3.org>; <wai-xtech@w3.org>
Sent: Tuesday, September 11, 2007 7:40 AM
Subject: Re: Investigating the proposed alt attribute recommendations in 
HTML 5



On Sep 11, 2007, at 13:31, David Poehlman wrote:

> What would you like jaws to do?

I think that isn't quite the right question. I think the right
question is, what blind Web users would prefer to hear with the
constraint that another human can't be consulted and only software
heuristics can be used.

Without knowing the actual preferences blind users have, the
following are guesses off the top of my head. I imagine each of these
to surpass what JAWS does:
  * Saying "image". (Even this is better than reading the Flickr file
names!)
  * Playing an beep or "aural icon" that takes less time to play than
the speech engine takes to say "image".
  * Playing a different aural icon based on image dimensions, format,
EXIF presence, color histogram and advance statistics on these
properties so that the aural icon represents a probabilistic
categorization as photo, thumbnail photo, illustration, icon,
advertisement, etc.
  * Reading the file name if (and only if) the file name consists of
segments that are words found in a dictionary of the language that
the speech generator speaks.

> Jaws is not a voice browser.

I didn't mean to suggest it were. I was using "voice browsing" to
refer to both browsing with browsers that are designed to talk and
with graphical browser plus screen reader combinations.

> If your question is: "what woulmost popular also which if we are is
> a flawed
> approach since as I said with jaws, html5 should not focus on internet
> explorer but rather focus on what the community needs and how to
> provide it.
> If this is is the case, I am happy.

I am asking what kind of improvements to screen readers are realistic
within, say, the next 7 years. As a software developer, I can assess
what kinds of problems are algorithmically solvable and I think I
understand market dynamics as they relate to server-side development
and to browser development. I don't understand the market dynamics of
screen readers, though.

> If we are focusing on IE, we need to back up and redirect.

It would sure be nice if we had the freedom to think past the current
versions of JAWS as used with IE.

> The answer
> is that when you see it in the ua parsing engine, if it is
> propperly parced,
> we'll see it soon after in the screenless desktop environments.

The division of work between the browser and the speaking desktop
environment is an implementation detail that should not be prescribed
in the markup spec. However, if, due to market dynamics or whatever
inertia, vendors of speaking desktop environments simply won't
improve the treatment of images that lack alternative text, perhaps
the spec should suggest that it would be good for the user experience
if the browsers took over and faked an alt text.

> The user agent is not mentioned here but it seems that we are
> talking about
> the

It appears that the rest of your message got cut off.

-- 
Henri Sivonen
hsivonen@iki.fi
http://hsivonen.iki.fi/

Received on Tuesday, 11 September 2007 21:15:10 UTC