Re: [orca-list] Structural HTML navigation by lists

[Michael Whapples <mwhapples aim com>]

Hello,
You say you don't get the number of keypresses argument. Here goes: As I 
have stated in previous messages your list idea is certainly optional in 
use, I gave myself as an example of someone who never needs to use it 
and others also have said so, we can get around web pages perfectly fine 
with the previous/next element keys already existing. You mentioned flat 
review, which I have shown is needed, and so possibly deserves the space 
of the numpad as it currently occupies. Optional features generally I 
don't think should dominate the keyboard so much unless they have a 
strong reason.

So you may ask why do the previous/next element keys in firefox dominate 
so much of the keyboard? While I don't know if this was the original 
reason, I would make the following argument, lets consider the impact on 
use if these were to be made second level keypresses (IE. two keypresses 
to get to the feature). If the previous/next element keys were made 
second level each navigation would go from one keypress to two, 
therefore doubling the keypresses!

Now what is the impact of making list of headings, list of links, etc 
second level (eg. through a menu with submenus)? I would guess the aim 
of the list idea is to get you where you want in one go, therefore it is 
an action you would do once for a given navigation. Now how many 
keypresses might a navigation of this sort take on average, may be half 
a dozen, one to get the list, average of four to find the item and one 
to press enter on the item (correct me if you find from experience 
otherwise). So adding in one more keypress to make it second level, this 
impacts on the user with an increase of keypresses by one sixth. I think 
we can agree the impact on these users is significantly much less than 
in the previous/next element navigation.

While you have made the case that the keyboard has many keys and we are 
unlikely to run out of combinations, I think you need to be reminded 
that keypresses should make some sort of sense and some combinations may 
just be difficult to do. We have already had an example where we have 
run out of keys which make sense, in the previous/next element 
navigation the keys generally mapped to the first letter of the element 
type, but combo box and check box both begin with c so check box had to 
become something else.

Now to my comment that we are dealing with orca in gnome. My point here 
is that it doesn't matter what other screen reader users do, those 
screen readers have their own history for why certain things went 
certain ways and possibly have different target audiences. As an example 
to this, users of windows screen readers are more likely to include 
those users who just want to buy a computer and for things to work, 
where as Linux users are more likely to want to explore/modify/tweak 
there computer systems. I think a strong proposal for features for orca 
should be strong independent of what other screen readers do, so should 
not need reference to what other screen readers do and should deal with 
such questions like: Why might an orca user want it? How does it improve 
on what orca does at the moment?

Michael Whapples