Re: [orca-list] Internet accessibility was: Re: form field structural

["krishnakant Mane" <researchbase gmail com>]

hi kris,

On 26/04/07, Krister Ekstrom <krister kristersplace ws> wrote:
> Hi,
> I agree with Krishnakant in what he's saying. There's only one aspect
> that has me wondering, but maybe this discussion is best taken off-list.
bingo!

> The thing i wondered about was if the screen reader or the web browser
> should provide the links list. There are pros and cons with both
> strategies. Krishnakant, what would you think would be the advantages
> with screen readers providing the links list and frame list as oposed to
> the browser doing that?
If you are modestly trying to oppose what I said then you are actually
right.  if you are trying to hint me that browsers should do that job,
the one biggest advantage I can see is that any screen reader will be
able to work well with the concept of quick navigation.
to support this point I will give one example.
in gnome desktop, pressing alt-ctrl-d takes the focus to the desktop
no matter which screen reader you use or don't use.
if browsers can provide certain ctutial features like links list and
frames list then firstly, the job of the screen reader developers will
be at least some what relaxed because it is a very donting task
indeed.  secondly all screen readers will be able to take advantage of
that feature.
and as such one more advantage of not having vertual buffers is that
if browser provides links list, we get the screen reader work out of
the box for that feature, because the page is displayed as-is.
the only disadvantage I see is "who will do it and when?"
it will need some amount of pestering the developers of ff for
example.  but again I had a discussion with my research team today
after I wrote the previous email and some one indeed raised the same
point.  bottom line is that if we get the developers of firefox to do
this for example, it will be wonderful.




> Other than that, i totally agree with you on the non-forms mode
> approach. I think Orca works very, very well and isn't overbloated,

yes I really missed that point.  some times jaws gets bloted for
example with sites which have a lot of content on a single web pate.
I remember the documentation ofMySQL database used to take about 2
mins on my computer because the entire document was about 550 kb and
you can imagine the amount of buffering the screen reader needed to do
to process the html and put it in the buffer.  the biggest joke about
that document was that it was a simple html page with a lot of
headings and "this page link" which jaws calls it (again a good thing
to learn and copy ).

> let's make things stay that way, please. And yes, website design is of
> course a matter of knowhow, but if a screen reader prevents you from
> seeing things that potentially could be wrong, then no php, css, html
> and so on knowledge is ever enough.
right, that's the whole point.  look, a musical consert can't go well
without one speaker pointing towards the performers on the stage.  if
they can't hear what they are playing and if it comes back to them as
in echo, they often may miss the patern of the beets etc.
so it is very very important to mimik the design which we have in
mind.  if you try to study this issue very carefully, orca with its
given short comings is still doing its job pritty well.
talking about sites which are not accessible with orca to find which
radio program comes on air at what time, then I will give many
examples like,
www.gnowlege.org, where jaws can't do any thing and orca rocks.  so
this is more like a cock fight which we should not indulge into.
regards,
Krishnakant.