Re: [orca-list] Mate: Annuncing editable text field on the desktop

Hi Raphaël.

I just installed MATE in Fedora 25 and did some tests without Orca
running. Consider the following test steps:

1. Type "kt". Result: Nothing is selected, because nothing on my
   desktop starts with "kt".
2. Press left arrow. Result: Selection doesn't change because focus
   is not on the desktop because I'm in the text field.
3. Press backspace. Result: The "Trash" icon becomes selected because
   pressing left arrow in the previous step moved the caret one letter
   to the left. As a result, pressing backspace resulted in the
   previous character "k" being deleted, leaving only the "t" in the
   entry, and the "Trash" icon starts with "t" so the selection changes.

As a sighted user, I find the above behavior confusing. It would be far
less confusing if the entry were on screen because focus is in that
entry. Having said that, if the Caja developers want to lie to Orca in
this particular case, then Orca users can be equally confused. And I am
100% in favor of equal access. <smile> But that's strictly for the
Desktop -- and I have a concern which I'll come back to momentarily.

In contrast, if I open a Caja window and perform similar steps in the
icon view, the typeahead search entry is visible. So I can see when I
mistakenly type a "k" before a "t". It's obvious that I can fix such a
mistake by pressing left arrow and then backspace. It's equally obvious
that pressing left arrow will not change selection in the icon view
because I am obviously not in the icon view; I'm in the entry. So when
the entry is visible, I think it would be bad if the Caja developers
lied to Orca in this case because doing so would mean users who are
blind are being denied information that sighted users have immediate
access to.

As for the concern I mentioned earlier: On the one hand, lying to Orca
would mean that everyone is denied access to the same information
regarding where focus really is. So one could make the case that the
user experience is fair and equal, as I snarkily did above. But is it
really fair and equal? As a sighted user who is able to use the mouse, I
do not need to use the keyboard to select and open desktop items. And if
I don't clutter up my desktop, I use vision rather than typeahead search
to quickly locate what I wish to activate/open. The fact that focus goes
into a typeahead entry directly impacts what keys work and what they do.
In other words, the primary tool you use to interact with a device stops
working the way you expect it to. Is it really a good idea to deny you
of that information?

Another thing to consider: If you have two icons on your desktop which
start with "t", what do you expect to happen if you press "t" twice in a
row? I would expect the selection to change from, say "Trash" to "Test
Folder." It doesn't. Selection is removed from all icons on the desktop
-- unless, of course, you have an icon which starts with two t's.

Typeahead search should be thought of as the text field in a "find"
toolbar because that is how it behaves. If you pressed Ctrl+F and wound
up in an application's search field, should Orca not tell you that?
Should the application developer lie to Orca so that Orca has no clue
you are there??


On 12/13/2016 04:50 AM, Raphaël POITEVIN wrote:

Today, in Mate, on the desktop, when reaching an icon by typing the
first letters, Orca annunce a text field is focused, and the desktop
comeback. For my team and me, and users we know, thi behavior is very
heavy. In Windows, when typing the first letters, it annunce simply the

Technically, in Caja, there is aan invisible text field when typing text
on the desktop.

We managed to disable focusing this text field, but, it seems it could
involve others problem for the languages which contain special
characters. The idea would consinst in lying to Orca to hide this text

It could be discussed. Is there a sense to tell to the user we are in a
text field when typing characters on the desktop?


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]