Re: Investigating the proposed alt attribute recommendations in HTML 5

Removing public-html and wai-xtech and adding www-archive to CC.

On Sep 11, 2007, at 21:36, John Foliot wrote:

> Henri Sivonen wrote:
>> 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.
>
> While I understand that we often use 'short-hand' when using written
> communications, please remember that tools such as JAWS, WindowEyes,
> Emacspeak (and other screen reading technologies) might also output  
> content
> to yet more adaptive technology such as Braille Refresh bars.

I am unsure why you remind me of Braille bars when the context was  
how JAWS manages to tar pit its speech engine by applying a heuristic  
that is spectacularly bad and how I was saying that a heuristic  
doesn't have to be that bad.

I would hope that what a Braille bar can ingest isn't considered to  
limit the design of what sounds the aural facet can render. Is it?

> As well, it
> is totally conceivable that sighted users might want to have screen  
> reading
> technology at their disposal as well: perhaps a user-agent in your car
> dashboard that reads aloud directions to that great new restaurant...

Personally, I don't find it conceivable that anyone who doesn't have  
to use screen readers would want to use them. But anyway, the  
scenario you describe is out of the scope of "accessibility" as the  
word has been applied here and is already successfully addressed by  
dedicated multimodal navigation devices.

[...]
> there is a toggle on/off for the @title attribute - the default
> setting is off, thus relying on @title in lieu of @alt is a dangerous
> presumption)

I think it is rather unreasonable to expect the author to guess what  
the user has chosen to suppress even though the author takes the  
trouble to make it available.

[... Lots of text about JAWS configuration snipped.]

I didn't understand the point you were trying to make with the JAWS  
configuration options. I was merely pointing out that it wasn't hard  
to come up with something that would be better than what the JAWS  
does now according to Steve Faulkner's testing. Do you mean JAWS  
could be configured to behave better than the testing article described?

>> 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.
>
> Small market served by an even smaller corporate base.  Essentially 2
> mainstream front-runners (JAWS and WindowEyes) along with a few others
> (including smaller, localized versions for foreign languages), plus  
> some
> open source stuff that tries real hard but operates on goodwill and  
> free
> time.  The software is also fairly expensive, slowing the "upgrade"  
> path
> considerably.  Unlike browser upgrades (which can be frequent given  
> that the
> software is free), many of the users I know will only upgrade their  
> screen
> reading software when they upgrade their total system - which is  
> probably in
> the 3 to 7 year range (system vendors might be able to tighten this  
> number
> down a bit, but based on Microsoft's OS support plans, this would seem
> roughly right)

What can be reasonably expected feature-wise after that update cycle?  
Is it reasonable to expect JAWS to get fixed so that it won't try to  
read strings that aren't suitable for reading as a fallback, for  
example? Is it reasonable to expect JAWS to get support for new  
constructs such as <figure>?

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

Received on Wednesday, 12 September 2007 07:14:21 UTC