Free blind browser?

[jake]

In message <[email protected]>, Chris Morris

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.

The problem with that idea is that it assumes that all sites are the
same.

HPR *could* get to any section that was headed by a link or a heading,
but only if the section was so authored.

Anyway, it would still be too slow a method of getting anywhere on a
reasonably-sized page or site.

e.g. 'stop reading' 'go into xxx reading mode' 'forward' (or 'back')
'forward' 'forward' 'forward' etc. then 'return'

It makes much more sense to have a simple 'skip navigation' or 'go to
navigation' as the first entry on the page. That way the user simply has
to depress 'return' on hearing it.

And if you're looking through a site that's got a lot of pages, then
that's just got to be a bonus.

All organisations for the visually-disabled (as well as national and
local governments) recommend it. I somehow doubt that they're all wrong
;-)

[snip]

regards.

 

[jake]

[snip]


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

Hard to argue with.

regards.

 

[jake]

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.

Two tools that you should really take a look at:

The WAVE Accessibility Tool --
http://wave.webaim.org/index.jsp (very good for a first pass)

and (if you've got plenty of time to use it):

A-prompt Web Accessibility Verifier--
http://aprompt.snow.utoronto.ca/


regards.

 

[Spartanicus]

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.

Enter headers, one h1 to describe the page, h2's for each "block" (e.g.
Content, Navigation), this is general good authoring.

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).

The real problem is that certain things (blocks) form virtually no
obstacle for 2 dimensional (visual) access, but they become a hindrance
when the document is accessed linearly (e.g. by a speaking UA). Navbars
for example, they provide convenience in 2D mode, but they are a
hindrance in linear mode. The proper way to solve that is substituting
navbars with a "one link up" type navigation for linear access.
Unfortunately that requires a AT UA that supports the css aural media
type.

Again, that's due to bugs in Bobby.

No, they advocate that tables used for layout is fine provided that the
aforementioned kludge is present. This is not a "bug" but the result of
a flawed principle of measuring accessibility by using the current crop
of grossly deficient AT UAs as the yardstick.

Yes, attempting to satisfy Bobby may mess up a site.

That's what you initially questioned.

 

[Chris Morris]

Enter headers, one h1 to describe the page, h2's for each "block" (e.g.
Content, Navigation), this is general good authoring.

I don't know. Should navigation have a <h2>Navigation</h2> above it?
I've seen good arguments for not doing so. Anyway, how does this help
Lynx? Unless I missed something when reading the documentation it
doesn't have a header-skipping mode.

That's what you initially questioned.

No it's not, at least not intentionally. I said in
<[email protected]>:
} > 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.

And I think the problem is that I interpreted your 'them' as "the
disabled" whereas reading your post again now I think you meant
"Bobby's recommendations".

Ah well, such is usenet.

 

[Neal]

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.

Difference between validation and Bobby - validation is an objuective
check which makes no claim to consider the quality of the content or
design, or accomodation of browsers which don't fully conform. It deals
with correctness of code only.

Bobby ostensibly checks for accessibility, but in reality it looks for a
limited number of patterns on the page and recommends changing them if it
doesn't match what it thinks is accessible. Some of accessibility is
subjective, and requires a human eye to discern.

 

[Spartanicus]

I don't know. Should navigation have a <h2>Navigation</h2> above it?

Or a lower level heading, I don't subscribe to the notion that no header
levels should be skipped.

<h1>Page description</h1>
<h3>Content</h3>
Content
<h3>Navigation</h3>
Navigation

is also fine provided that there are no h2's or more h3's anywhere else
on the page (assuming there are 2 "blocks"). Needless to say that
typically the display of these headers on screen would be suppressed.

I've seen good arguments for not doing so.

Which are?

Anyway, how does this help Lynx?

Who said anything about "helping" Lynx or any other UA? I'll repeat what

A site who's content linearizes
properly and who's sections are labeled properly is perfectly usable by
people using current AT AUs.

All this time I've been arguing that this practice of "helping" grossly
deficient UAs is *creating* a barrier for moving things forward.

No it's not, at least not intentionally.

You have a selective memory:

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?

I said in

Wrong quote, see above.

And I think the problem is that I interpreted your 'them' as "the
disabled" whereas reading your post again now I think you meant
"Bobby's recommendations".

No I meant "the disabled".

 

[nice.guy.nige]

While the city slept, Karl Groves ([email protected]) feverishly
typed...

Take a look at http://usabilityinfo.com/tools.php?viewonly=dtopapp

Hmmm... "HAL Screen Reader"... not sure I want to install that!

"Open the Pod Bay Doors Website, HAL."
"I'm sorry Dave. I'm afraid I can't do that."
{{{shudder}}}

Cheers,
Nige

 

[Chris Morris]

Which are?

Using headings to markup content structure, the 'navigation' isn't
really part of the document outline in my opinion. Ideally navigation
bars should be set up using <link> rather than <a> [1], but UA support
isn't going to be good enough for that to work for decades. Should I
help "grossly deficient" UAs [2] by including <a>-based navigation bars?

[1] So many advantages - standardised display across different sites,
clearly separated from the content, easier to describe link
relationships, etc.

[2] Such as IE6, which while it *is* grossly deficient is also quite
commonly used.

Who said anything about "helping" Lynx or any other UA? I'll repeat what


All this time I've been arguing that this practice of "helping" grossly
deficient UAs is *creating* a barrier for moving things forward.

Every UA is grossly deficient, though. Being able to view a website in
'outline' mode would be very helpful (I expect there's an obscure
Gecko plugin that lets you do this, but that doesn't really count) but
IBM HPR is about the only UA (AT or otherwise) I've found that lets
you.

And what *harm* does a 'skip to whichever of content or navigation is
second' link do? Apart from taking up a small amount of space?

You have a selective memory:

No, I have a writing style that doesn't match your reading style.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
No. That is *not* me questioning whether attempting to satisfy *Bobby*
will mess up a site.

No I meant "the disabled".

Fair enough. Then my question in the message you quoted (rephrased to
make it slightly clearer) stands:

Can you give an example of where following an accessibility guideline
from WAI Priority 1 or WAI Priority 2 will harm general quality? I
don't care what Bobby, A-Prompt, Access Valet, Wave, or any other
automatic checker *think* these guidelines mean [1]; what problems do you
see with the *guidelines themselves*.

[1] I rarely use them myself nowadays. I occasionally use an old
downloadable version of Bobby to quickly find missing alt attributes
across an entire site, but that's about it.

 

[Toby Inkster]

Being able to view a website in 'outline' mode would be very helpful
[...] but IBM HPR is about the only UA (AT or otherwise) I've found that
lets you.

Go out and find Amaya.

 

[Chris Morris]

Being able to view a website in 'outline' mode would be very helpful
[...] but IBM HPR is about the only UA (AT or otherwise) I've found that
lets you.

Go out and find Amaya.

I have a copy. Didn't realise it could do that. I would try it out to
see how good it was, but it's currently giving an obscure error
message and refusing to start.

 

[Isofarro]

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.

Menu bar is simply a list of links. So:

<ul>
<li><a href="url">...</a></li>
...
</ul>

 

[Spartanicus]

Ideally navigation
bars should be set up using <link> rather than <a>

That could only work if it was a format with no restrictions or
defaults, <link> navigation fails on both counts. Authors would have to
be able to rely on it. Given the absence of a mandatory UA
implementation requirement that was never an option, it was silly to
tack essential stuff like this onto a spec.

It would require a new non backward compatible specification. This would
result in creating a divide between content authored to such a standard
and legacy UAs, no trivial matter. It would require drafting the
standard, industry wide implementation in UAs, and then no-one should
use these features until the legacy UAs have practically disappeared.
That imo isn't going to happen, ever.

I agree that ideally site navigation should not be part of the content,
but we have to accept certain fundamental shortcomings in the concept
because fixing them isn't a realistic option.

Note however that even with site navigation out of the way there is
still a problem of cross page inclusion of the same content.

Every UA is grossly deficient, though.

AT UAs: yes. Current 2D visual browsers are capable of providing an
excellent user experience. Getting one and the same code to work in
other renditions is the problem.

And what *harm* does a 'skip to whichever of content or navigation is
second' link do? Apart from taking up a small amount of space?

"Small amount of space" is 2D talk, in linear mode, every kludge is a
genuine nuisance.

Can you give an example of where following an accessibility guideline
from WAI Priority 1 or WAI Priority 2 will harm general quality?

I've corrected your misrepresentation of what I wrote with the actual
quotes once, I'm not doing that again.