Eric Meyer recently posted Don’t Read; Speak!, from which I quote:
[S]creen readers need to become speaking browsers: they need to ignore how the page is visually displayed, and read the content. Use semantic markup when it exists, and otherwise [...] ignore the non-semantic markup and read the content. I can accept that might fail in many cases, so I’ll present a fallback: DOCTYPE switching. If a document has a DOCTYPE that would put a visual browser into standards mode, then be a speaking browser. If not, then be a screen reader.
Amen to that. Somehow this needs to happen. It would require building a browser up from scratch, but as it wouldn’t have to support any CSS (other than voice-specific properties) my guess is that it wouldn’t be anywhere near as difficult as building a visual browser. But who’s going to build it and how would it integrate with existing accessibility software?
Olly wrote:
I’d like to see Mozilla.org step up to the plate. But on the other hand, they can’t do /everything/...
James wrote:
Well, maybe the Mozilla foundation doesn’t need to. I’m sure some motivated open-source hackers can start a project to take Mozilla’s Gecko engine (or indeed KHTML / WebCore) and modify it respond to aural stylesheets rather than screen ones.
Using existing text-to-speech systems (such as the one that seems to be built into Mac OS X) I suspect it wouldn’t even be that hard to do!
Perhaps the web-design community should come up with a spec outlining the features / behaviours we’d like and then see if someone’s interested in doing it!
(and while we’re at it can someone hack Lynx to use tty stylesheets? :D)
James wrote:
Sorry to post again so soon, but I just had another idea:
Wouldn’t it be cool if phones and PDA’s had audio-browsers? Not only for blind people but also for people on the move who don’t have time (or free hands) to browse on the phone’s screen but would happily have a webpage read to them over their earphones?
If we could pursuade Opera / Nokia / Symbian etc… that this could be a new selling point for their products they may take on the task of making a decent audio browser!
darren wrote:
so has anyone any good or bad experiences with browsealoud http://www.browsealoud.com/ (apart from the annual license fee). I’m implementing a site for a client who has to provide it and I’m curious to see what everyone thinks.
Rich wrote:
darren – I haven’t heard Browsealoud mentioned much in accessibility circles. It seems interesting in as much as it’s a screen reader that requires sight to operate, therefore being more of use to those with literacy difficulties such as dyslexia.
Do you know why it is that they ‘need to be provided with the web site, intranet or extranet URL’. It seems odd that the ‘process of making your site speech enabled is handled remotely’. What do they do remotely that can’t be done by reading the website? Perhaps I should request a trial….
I would be grateful to hear of your experience working with Browsealoud, as I’m sure would the WaSP ATF.
darren wrote:
well i might just be an old cynic but I think they need your web address purely to add you to the whitelist of enabled sites, which then means the browse aloud application becomes activated when a user reaches your site. i.e. it’s for licensing issues only. For a site such as this their list price would be about 1500 per year, which seems a little steep.
As for the functionality well it seems to do a pretty good job of reading out the content, but I find the effectiveness very hard to test seeing as I am not that optically disadvantaged, anyone have any good techniques for this?
patrick h. lauke wrote:
i think you may have the wrong end of the stick here. it’s not that we need a new browser. it’s that screenreaders need to interface with current and future browsers better and ignore the styling. they need to leave styling, visual order, etc which the later screenreader versions have started to use, well and truly alone.
as an example: JAWS 4.02 (admittedly antiquated in screenreader terms) in combination with IE 6.0 is perfectly happy reading things that have been styled with display: none; JAWS 6 completely ignores anything thus styled. it should just ignore the styling, dammit. it’s meant for screen/visual display, not audio. as it stands, latest versions of JAWS are trying to be too clever for their own good (actually applying styles?) but fail to grasp other parts of the spec such as @media selectors or media attributes of stylesheet LINK elements.
we don’t need a new browser, we need to get screenreader manufacturers to understand the spec better and honour it, rather than doing this sort of hodge podge they’re doing now.
patrick h. lauke wrote:
caveat emptor.: at least that’s my interpretation of eric’s thoughts, which echo a discussion on various accessibility lists quite a long time ago on the dangers of display:none;
as for browsealoud…i have mixed feelings about it. as darren points out, it feels like what you’re actually paying for (as a site owner) is for the plugin to be “allowed” to read your page. i may do a more thorough analysis later next week (live HTTP headers and ethereal at the ready). also, about a year ago browsealoud had some rather shady “advertising” tactics of having one of their employees pose as a dyslexic user singing the praises of their product…see “dyslexicduncan” at accessifyforum http://www.accessifyforum.com/viewtopic.php?t=819&highlight=browsealoud and my discovery later on http://www.accessifyforum.com/viewtopic.php?p=22009#22009
Rich wrote:
Patrick – Despite what I actually wrote, I’m not necessarily calling for a brand new browser to be developed. I think I’m asking for the same as you – a browser that doesn’t try to interpret the visually rendered page, but instead one that understands the underlying HTML and, ideally, any aural stylesheets that may have been applied.