Re: [orca-list] Thoughts on a "list of elements" feature for Orca in Firefox

["Krishnakant Mane" <hackingkk gmail com>]

hi michael, willi.



On 22/05/2008, Michael Whapples <mwhapples aim com> wrote:
> Hello,
> I have to agree with Willie on this, I think the correct place for such
> a feature would be as a plugin for firefox. In saying this, I am not
> saying that such a feature would be useless, just suggesting that there
> may be better places than orca for it.
I second that thought.  infact, wili, you seam to have taken words
from my mouth.
I was actually going to suggest the same thing.
it not just speeds up the things as you rightly suggested but afterall
free software culture implies that all parties work in an eco system
so if this becomes an extention then no matter what screen reader is
used it will still work the same way and user need not learn different
set of keystrokes for different screen readers.
I would suggest the forms element list more important than the links
one because some forms are pritty complex to handel with or without
forms mode.
further more since we don't involve a forms mode fortunately, it will
not require the user to first select an edit field from a list by
hitting enter on it and again hit enter for activating the forms mode.
however buttons need the hit of the return key and that is their
default and obviously safe behaviour.
we already have a way to use u and shift u and v and shift v for links
but I think providing the url in the second column and the available
lable in the first one is wonderful idea.
happy hacking.
kk
> On Thu, 2008-05-22 at 10:37 -0400, Willie Walker wrote:
> > Hi All:
> >
> > I'm curious if anyone has tried Jon Gunderson's Firefox Accessibility
> > Extension: https://addons.mozilla.org/en-US/firefox/addon/5809
> >
> > The reason I ask is that an extension living/running inside Firefox is
> > most likely going to provide faster analysis of the web content than
> > Orca can.  The reason for this is that the extension lives in the
> > Firefox process and doesn't have to do numerous roundtrips to build up
> > the data structures necessary to present the list of links.
> >
> > Will
> >
> > Marco Zehe wrote:
> > > Hi all,
> > >
> > > I've given the possible list of elements (for example list of links)
> > > feature some thought and would like to share it with you all to see what
> > > you think.
> > >
> > > First off, let me clarify that I think Orca could really benefit from at
> > > least a list of links. Others that are offered by other screen readers,
> > > such as a list of headings, are not so imminently necessary IMO because
> > > Orca provides access to these already with structural navigation, both
> > > by any heading and by certain heading levels. However, a list of links
> > > has no real equivalent in Orca's structural navigation, and I personally
> > > find the Firefox search not as effective as I find a list of links when
> > > I'm on Windows.
> > >
> > > So now for the look of the actual list: I would think it makes sense to
> > > put this into a kind of dialog box that contains a tree table which
> > > contains the name of the link (screen name, alt or title, whatever
> > > Firefox provides) in the first column, and the URL in the second column.
> > > The reason I think an URL should be presented in an easily accessible
> > > fashion is because there are still enough pages that don't properly mark
> > > up links, and sometimes the URL is the only reliable way to find out
> > > what the link is about.
> > >
> > > The left and right arrows should move between cells in any given row as
> > > usual (e. g. in Nautilus' file list view).
> > >
> > > When typing in letters, like is usual in Gnome tree tables, a search
> > > should be performed. When typing and a match is found, Orca should speak
> > > the result that would be activated. If using braille, Orca should show
> > > the full link's name (contents of the first column) to the right of the
> > > cursor  where one types the search. That way, even when only using
> > > braille, one can read immediately whether the desired link has already
> > > been found.
> > >
> > > ENTER should activate an "Activate link" button, close the dialog, focus
> > > and activate the link, and thereby let the user navigate to the desired
> > > destination page.
> > >
> > > In addition, a second control, possibly labelled "Focus link", should be
> > > provided, which allows the user to focus, but not activate, the link
> > > (for example in order to pull up its context menu). We could also think
> > > of a keystroke like SHIFT+ENTER or something else that would activate
> > > this button without having the user to tab to it. Or we could just make
> > > sure it has an easily rememberable access key.
> > >
> > > ESCAPE should close the dialog obviously, without causing any change.
> > >
> > > I am not sure we'd need radio buttons to filter by visited, unvisited,
> > > or all links, or to sort in alphabetical or tab order, as offered by
> > > other screen readers. I find myself never using these at all. If I want
> > > to explore the page, I usually do it by reading the page in whole, not
> > > by simply arrowing through its links. I personally use the links list
> > > ron pages I know well and know that I want to go to link 150 quickly and
> > > activate it.
> > >
> > > Any thoughts?
> > >
> > > Marco
> > > _______________________________________________
> > > Orca-list mailing list
> > > Orca-list gnome org
> > > http://mail.gnome.org/mailman/listinfo/orca-list
> > > Visit http://live.gnome.org/Orca for more information on Orca
>
> _______________________________________________
> Orca-list mailing list
> Orca-list gnome org
> http://mail.gnome.org/mailman/listinfo/orca-list
> Visit http://live.gnome.org/Orca for more information on Orca