Free blind browser?

[jake]

I have learnt a lot from this in just a couple of hours.
Do you know if it is possible to have it read large numbers (such as phone
numbers or ISBN numbers) as a sequence of digits rather than as "millions
and thousands"?

No, not really. Recognising phone numbers should be built into the
system but the current version doesn't appear to do so -- or at least
not properly.

There are ways to force HPR to speak the numbers individually -- but may
well upset other readers.

 

[Frogleg]

Just achieved 2 Bobby-approved sites. Well, first pages, anyhow. Can't
find an active newsgroup for discussion of good practice for the
blind/vision-impaired. Any clues?

 

[Spartanicus]

Just achieved 2 Bobby-approved sites.

Be careful with Bobby, it's advice is rather contentious. It's automatic
checking methods are based on the flawed principle that it's possible to
do what it does with any degree of accuracy, whilst it's obvious that
this is not possible. Striving for Bobby AA and AAA status is imo
generally harmful, not helpful.

In fact I'd go so far as to say that unless your content is specifically
aimed at the disabled you shouldn't make any attempts to facilitate them
beyond what is considered good authoring practice for a quality website.

If you do choose to go down the Bobby road then you'll be adding ugly
kludges to get around the very poor quality of the current crop of
software used by the disabled. In doing so you'll damage the quality of
your work as judged by general good authoring guidelines.

Follow the general good authoring guidelines and you are authoring work
that is of higher quality, this will make it possible for future
assistive technology software to create a better web experience for the
disabled than is currently possible with some authors choosing to
downgrade their work so as to accommodate the current crop of broken
software.

Can't
find an active newsgroup for discussion of good practice for the
blind/vision-impaired.

Here will do, alt.html.web-accessibility sees little traffic but that
doesn't mean that it isn't followed.

 

[jake]

Just achieved 2 Bobby-approved sites. Well, first pages, anyhow.
urls?

Can't
find an active newsgroup for discussion of good practice for the
blind/vision-impaired. Any clues?

Most of them carry little or no traffic:
alt.comp.accessibility
alt.html.web-accessibility
alt.web-accessability

alt.comp.blind-users occasionally carries related information.

regards.

 

[Chris Morris]

Be careful with Bobby, it's advice is rather contentious. It's automatic
checking methods are based on the flawed principle that it's possible to
do what it does with any degree of accuracy, whilst it's obvious that
this is not possible. Striving for Bobby AA and AAA status is imo
generally harmful, not helpful.

Well, certainly doing so for the sake of it. And Bobby's A checks are
obviously flawed.

In fact I'd go so far as to say that unless your content is specifically
aimed at the disabled you shouldn't make any attempts to facilitate them
beyond what is considered good authoring practice for a quality website.

I'd disagree with that. There are a number of things that are very
useful for accessibility that don't really end up in general good
authoring practice.

Use of headers/id on data tables, rather than the easier scope, for
example.

If you do choose to go down the Bobby road then you'll be adding ugly
kludges to get around the very poor quality of the current crop of
software used by the disabled. In doing so you'll damage the quality of
your work as judged by general good authoring guidelines.

Really? Can you give an example of where following an accessibility
guideline (at least in the WAI Priority 1 and 2 levels) (rather than
trying to make Bobby believe you're doing so) harms general quality?

Accesskey excepted due to awful browser implementations.

 

[Karl Groves]

Just achieved 2 Bobby-approved sites. Well, first pages, anyhow. Can't
find an active newsgroup for discussion of good practice for the
blind/vision-impaired. Any clues?

You're already off on the wrong foot.
Accessibility is NOT just about blind people.

-Karl

 

[Neal]

Well, certainly doing so for the sake of it. And Bobby's A checks are
obviously flawed.
<img src="elephant.jpg" alt="Summer in Antarctica">

Indeed, this cannot be checked by machine. That in itself is a flaw in
relying on an automatic checker. It fools the unaware into thinking
everything's ok.

I'd disagree with that. There are a number of things that are very
useful for accessibility that don't really end up in general good
authoring practice.

Use of headers/id on data tables, rather than the easier scope, for
example.

Not familiar with these problems. Elaborate?

Can you give an example of where following an accessibility
guideline (at least in the WAI Priority 1 and 2 levels) (rather than
trying to make Bobby believe you're doing so) harms general quality?

Not that you asked me, but here's what I see.

Marking up all quotes with q or blockquote. If it's a brief quotation,
blockquote is inappropriate, and q may or may not add the quotation mark,
so you might end up with this, or "this", or if you add the quotes in the
content anyway, "this" or ""this"".

And http://bobby.watchfire.com/bobby/html/en/gls/g205.html has a bit of
vagueness that might lead someone to think one MUST use XHTML 1.0 instrad
of HTML 4.01.

Accesskey excepted due to awful browser implementations.

Actually, more due to the browsers and OS's already having pre-existing
uses for the key combinations. The flaw is not in the browser, it's in the
accesskey specification.

 

[Toby Inkster]

Actually, more due to the browsers and OS's already having pre-existing
uses for the key combinations. The flaw is not in the browser, it's in the
accesskey specification.

Accesskeys can be implemented in a sane way. See Opera 7.x as an example.

 

[Spartanicus]

Really? Can you give an example of where following an accessibility
guideline (at least in the WAI Priority 1 and 2 levels) (rather than
trying to make Bobby believe you're doing so) harms general quality?

Two examples from memory: Bobby complains about a missing label for a
form when one is clearly provided (apparently not in a place Bobby
approves of), or Bobby's advice to: "Include default, place-holding
characters in edit boxes and text areas.".

I'm sure there are more, these two I encountered myself on a page.

I also attribute kludges like "skip to navigation" and "skip to content"
links to a misguided understanding of accessibility inspired by the
likes of Bobby.

 

[kchayka]

Accesskeys can be implemented in a sane way. See Opera 7.x as an example.

Alas MS and the mozilla folks have not done likewise, so accesskeys
aren't exactly a practical feature. In the current state of things, they
tend to do more harm than good.

 

[Chris Morris]

Two examples from memory: Bobby complains about a missing label for a
form when one is clearly provided (apparently not in a place Bobby
approves of), or Bobby's advice to: "Include default, place-holding
characters in edit boxes and text areas.".

True, though that's a Bobby-related problem rather than a problem with
the guidelines (the former is a bug in Bobby, the latter is an 'until
user agents' and so can now be ignored).

I'm sure there are more, these two I encountered myself on a page.

I also attribute kludges like "skip to navigation" and "skip to content"
links to a misguided understanding of accessibility inspired by the
likes of Bobby.

As problematic as they are, what would you suggest as a better
approach? In certain situations they're very useful.

 

[Spartanicus]

True, though that's a Bobby-related problem rather than a problem with
the guidelines (the former is a bug in Bobby, the latter is an 'until
user agents' and so can now be ignored).

The latter is flagged as an error, not a warning, with no mention of
"until user agents" that I can see. Bobby's "rationale":

"Some access devices will miss a form control if there is no text in it;
that is, they will not tell the user the control is there or allow the
user to input data. Placing default text in the control forces the
access devices to see the control."

Which illustrates my point: they measure accessibility by the behaviour
of (unspecified) broken AT UAs and expect authors to degrade their work
in order to kludge around these AT UA issues, in doing so they create
problems for the rest. It also degrades what can be achieved by proper
(future) AT UAs. This could result in a situation whereby AT UA
manufacturers don't see any point in improving their software because
the quality of the coding used on the web is too poor.

This type of chicken and egg dilemma can be avoided by authoring general
purpose sites to a high general standard and by leaving the AT UA issues
where they belong: for their manufacturers to solve.

As problematic as they are, what would you suggest as a better
approach?

Regarding "skip to" links: omit them. A site who's content linearizes
properly and who's sections are labeled properly is perfectly usable by
people using current AT AUs.

Regarding "this is a table used for layout" type kludges: this should be
solved by not using tables for layout. Using tables for layout is fine
by Bobby provided that such a kludge is present, this is turning things
upside down.

No disabled person that uses the web gives a flying monkey for the
issues that we sometimes fret about. The real accessibility issue for
them (and the non disabled) is that soooo many sites fail to meet
general good authoring standards. Let's do something useful and work on
that instead.

 

[Isofarro]

Just achieved 2 Bobby-approved sites.

Wow - another badge to put next to the "spell checker approved" badge.

Well, first pages, anyhow. Can't
find an active newsgroup for discussion of good practice for the
blind/vision-impaired. Any clues?

Here is a good starting point, along with
comp.infosystems.www.authoring.html. I'd suggest a web site forum instead:
http://www.accessifyforum.com/ - and when you think you've got to grips
with accessibility: http://www.gawds.org/

 

[WebcastMaker]

You're already off on the wrong foot.
Accessibility is NOT just about blind people.

Yea, but you would never know it from reading the forum.... (0_o)

 

[Frogleg]

Frogleg wrote:

Here is a good starting point, along with
comp.infosystems.www.authoring.html. I'd suggest a web site forum instead:
http://www.accessifyforum.com/ - and when you think you've got to grips
with accessibility: http://www.gawds.org/

Thanks. I'm not planning on setting myself up as an expert. I simply
found the topic interesting, wanted to become more aware of what
actual issues are involved in accessibility, particularly low- or
no-vision, and how easy/hard it'd be to implement guidelines, whatever
they are. Figured alt.html wouldn't be particularly interested in an
ongoing discussion, and wanted to know where to find a place to chat.

BTW, my first question will be about 'space' around links. I satisfied
Bobby with a middot in background color, but wondered what the common
solutions are for a menu bar.

 

[Frogleg]

You're already off on the wrong foot.
Accessibility is NOT just about blind people.

As you quoted in its entirety, I am interested in web design for
blind/vision-impaired users. I'm sure accessibility has many facets,
but that wasn't mentioned in my post.

 

[Frogleg]

Bobby's

Thanks to all who picked up on 'Bobby' and pointed out its flaws. I
take it, then, that Bobby is one resource, but qualifying for a
sticker isn't the be-all, end-all of appropriate design. Come to think
of it, W3C validation doesn't ensure a site's any good at all, but
it's a place to start.

 

[Chris Morris]

The latter is flagged as an error, not a warning, with no mention of
"until user agents" that I can see. Bobby's "rationale":

Yes. Which is a bug in Bobby. I know that's not a particularly good
piece of software for its advertised use. Good for some other uses,
though.

This type of chicken and egg dilemma can be avoided by authoring general
purpose sites to a high general standard and by leaving the AT UA issues
where they belong: for their manufacturers to solve.

There's not much in the WAI guidelines marked as "until UAs" - and
most of them you'd want to do anyway:

Priority 2 unless otherwise stated
1.5 Redundant links for client-side image maps (P3)
7.1 Avoid Flickering (P1)
7.2 Avoid Blinking
7.3 Avoid Movement
7.4 Avoid Meta refresh
7.5 Avoid Meta redirect
10.1 Avoid New windows
10.2 Properly position form labels
10.3 [Applies to layout tables only, obsolete UAs] (P3)
10.4 Placeholders, obsolete UAs only (P3)
10.5 Separate links with non-link characters (P3)

10.3 is irrelevant with good authoring practice. 10.4 is an exception,
*but* the Until UAs bit of that has been satisfied. 10.5 is
interesting... Using <li> for lists of links gives a sufficient pause
in current speech UAs, though, and gives a decent separation in
CSS-free UAs.

The rest, I think, are *part* of good authoring practice.

Regarding "skip to" links: omit them. A site who's content linearizes
properly and who's sections are labeled properly is perfectly usable by
people using current AT AUs.

Assuming linearisation for content in one 'block' and navigation in
another 'block' those blocks have to be in some order. In browsers
like Lynx it's quite useful to be able to jump to the second block
quickly.

Yes, HPR has Header Reading Mode and Link Reading Mode, so those links
are redundant in it. But text browsers don't have those modes as
much. Likewise it's convenient in non-CSS browsers (like NS4).

Not 'traditional' accessibility, perhaps, but it comes under my
definition of it.

Regarding "this is a table used for layout" type kludges: this should be
solved by not using tables for layout. Using tables for layout is fine
by Bobby provided that such a kludge is present, this is turning things
upside down.

Again, that's due to bugs in Bobby. We violently *agree* that it's a
poor automated checker.

Yes, attempting to satisfy Bobby may mess up a site. Attempting to
satisfy the guidelines themselves (with a few exceptions in the P3
guidelines like accesskeys and some of the until UAs) doesn't.

 

[Chris Morris]

Thanks to all who picked up on 'Bobby' and pointed out its flaws. I
take it, then, that Bobby is one resource, but qualifying for a
sticker isn't the be-all, end-all of appropriate design. Come to think
of it, W3C validation doesn't ensure a site's any good at all, but
it's a place to start.

Bobby (and other tools) and why they're not adequate
http://www.cs.tut.fi/~jkorpela/www/acctools.html

Some useful guidelines
http://www.w3.org/TR/WCAG10/

 

[Karl Groves]

As you quoted in its entirety, I am interested in web design for
blind/vision-impaired users. I'm sure accessibility has many facets,
but that wasn't mentioned in my post.

You said, you've achieved "Bobby-approved", then you stated you were
interested in discussions on making sites for "blind/ vision-impaired".
Bobby is a (substandard) accessibility checking tool, not a
"is-this-ok-for-blind-people" tool.
Surely you can see where someone would draw the inference that you had
confused yourself as to the nature of accessibility.

If you're really interested in finding out how blind people interact with
the Web, then talk to one or two. I can assure you that the proselytizers on
usenet - though well meaning - don't really understand the way blind people
negotiate Web sites. Most accessibility guidelines are based on "here's
what we think will help those with X problem". Sadly, the Web itself is
such a mess for people who can't see and they don't even notice/ care about
accessibility "features" such as a skip navigation link or table summaries.
The web accessibility guidelines were not formed based on actual usability
tests with persons who are disabled and are based solely on assumptions of
what they think the handicapped will need.

Personally, I make my websites as accessible as reasonably possible, which
always exceeds US Section 508 Guidelines, and goes deep into WCAG. This,
knowing full-well that it often won't mean anything to disabled users, but
it gives me warm fuzzies to think about the handful who may benefit. Beyond
that, it also really isn't that much extra effort. I take it as a quality of
work thing from the beginning, not as additional work.

-Karl