Mailing List Archive

Wikipedia and blind people
Does anybody have experience with making websites accessible
for blind people ? I think this is important in long-term,
but I don't have any experience with that.

So could someone with such experience please describe
what is best current practice in this domain ?
Re: Wikipedia and blind people [ In reply to ]
On Sun, 12 Jan 2003 20:59:04 +0100, Tomasz Wegrzanowski
<taw=Rn4VEauK+AKRv+LV9MX5uipxlwaOVQ5f@public.gmane.org> wrote:

> Does anybody have experience with making websites accessible
> for blind people ? I think this is important in long-term,
> but I don't have any experience with that.
>
> So could someone with such experience please describe
> what is best current practice in this domain ?
>
I've never actually worked alongside a blind web user, but I have
experimented with for or five different "talking browsers" and tested my
sites with them.

The current situation is that most products simply read the text that is
written to the screen. THere is only one browser that understands aural css
(emacspeak) and it's still in development, and only runs on unix/linux. But
the author is on the W3C's aural css committee. Opera has some sort of deal
with IBM over voice technology, but It's not very clear what that is about.

I would regard "best practice" as:
1) Punctuate everywhere! - current screen readers are totally unaware of
the HTML and just ride roughshod over boundaries between structural
elements. So if your H1 doesn't have a full stop at the end, the reader
will run straight on into the next sentence without pausing. You get a
short pause for a comma, a longer one for a full stop or question mark.
Navigation lists also tend to get run into one gooey mass.

2) Use CSS positioning to get the actual page content as high as possible
in the page source. So if the navigation bar is at the bottom of the source
and rendered as a left (or right) column via css, a blind user won't be
forced to listen to the entire site navigation on every page. In table-
driven layouts, content on the left, auxiliary material on the right is
more accessible than the opposite layout.

Note that this does not reduce navigability - the user is NOT forced to
listen to the entire page in order to get to another. This is because most
talking browsers use a separate function which reads a list of all the
links on a page.

Come to think of it, some of the talking browsers I tried did not announce
hyperlinks "inline", which might be a challenge for richly-linked material
such as Wikipedia.

--
Richard Grevers
Christchurch, New Zealand