Re: Screen readers - usage stats?

Hi Nick

sorry - long post...

> On Wed, 14 Apr 2004, Ian Anderson wrote:
> > > What compelling reason could there be to have stats of this
type?  I can
> > > think of some that have nothing to do with the web but none that
do.

I think you're attributing those words to me in error. they were
written by David Poehlman who was replying to an original post by Adam
Guasch-Melendez.

>
> Screenreaders are by definition a tiny market share at most sites.
> If that is a reason not to care about them, then let's forget all
> about accessibility.
> I know that's not what you meant, but it's the same underlying
argument.

I didn't take this to be David's meaning at all, and I can't see how
you got that interpretation


> Browser-specific authoring is the Root Of All Evil on the Web.

Agree, sorta... :)

> Seriously, that's a lot like authoring for "both browsers".  By
doing
> that you are contributing to
>   * lock-out (of people with different equipment)
>   * lock-in (of people with supported equipment, all of which is
>     proprietary)

Since I supplied no examples, I can understand you taking this meaning
from my words. I can assure you, the situations I am talking about are
relatively minor differences in presentation, and I lock no-one in or
out. BUT - users will get different user experiences based on their
choice of software and preference settings. It's unavoidable, and my
point was that looking at market share is, in the real world, the
common way to decide which way to jump. I'm not talking about
excluding anyone, but I *am* talking about quality of user experience.

For example, the site in question uses frames. JAWS reads the title of
the content page after the title attribute of the frame, then moves to
content; Window-Eyes reads the title of the frame and skips directly
to the first line of the content. The WE user receives less contextual
information than the JAWS user, but is hardly locked out. To
compensate, I ensure that the first H1 on the page has identical
content to the title and in an accessibility tips page, I encourage
all screen reader users to use their headings navigation shortcuts as
soon as they are on a page.

In another case, some text hidden in the navigation menu indicates to
screen reader users which link is lit up to show the current section -
a necessary hack because the site's navigation is in a separate frame
from the content. (It's a banking site. They all use frames for some
flipping reason. Don't even start with me on the frames thing...) I
"hide" the text by enclosing it in a span tag that's absolutely
positioned and throw it up out of the viewport by a couple hundred
pixels - safe "hiding" that ensures all screen readers should still
read it, unlike display: none. Both the "hidden" orientation message
and the link text itself are enclosed in a single link tag. JAWS reads
the orientation text and menu text as a single link properly e.g.
"link: current section - account status"; WE reads the orientation
text and the link text as separate links e.g. "link: current section"
"link: account status". Go figure, there's no justification for this
one, unlike some of WE's other annoying habits. Moving the orientation
text outside the link doesn't read sensibly in JAWS. Hence a dilemma
emerges. Which way to code? There's a heck of a lot more JAWS users
than WE users, and in this case WE is being an arse.

See, market leaders are leaders for a reason. JAWS, in my opinion, is
a better tool than Window-Eyes. JAWS deals better with standard
markup, common accessibility techniques and correct HTML than
Window-Eyes, in my experience at least. To get around WE's
over-helpful or broken behaviours, I'd frequently need to tweak the
HTML so that it wasn't structured properly and in effect punish the
users who bought the better software.

[Caveat; as I mentioned, I use these tools exclusively on default
settings and I am aware that changing the preferences could affect the
behaviour in either direction.]

To compare the situation to general web design, when you're designing
a site to web standards, you are rewarding better browsers and the
users of those browsers. You don't stop users of older, broken or bad
browsers accessing your sites, but their inferior user experience
resulting from the bad behaviour of their chosen software subtly
encourages them to start using better software.

JAWS isn't popular because it's the most expensive, it's popular
presumably because it's good and people judge it worth the money.

> If there are legitimate reasons to present things differently, you
should
> do so by empowering your users to choose, not by second-guessing
their
> needs.  The kind of user-options offered by mod_accessibility do
this,
> and if you think its output can be tailored for optimal presentation
> with particular screenreaders, I'm listening.

It's not about presenting things differently, but best practice is
currently to have just one site. You have to choose one way of doing
things, and this is why there are dilemmas.

I presume mod_accessibility is an Apache module, or PHP? The server
environment in question cannot use either of these. I am not familiar
with the properties of this mod, and I'm not sure I agree with the
idea of tailoring output for different screen readers. It looks like
you're contradicting yourself against your earlier points. Perhaps you
can elucidate what you mean here?

Received on Thursday, 15 April 2004 17:02:11 UTC