[orca-list] What Orca will do was Re: What's standard? was: Re: date and time keybindings



Hi all.

Please accept my apologies in advance for the lengthy email. But I'm
feeling the need to draw a couple of threads/themes to a close.

On Mon, 2010-05-03 at 16:39 +0530, hackingKK wrote:
Sorry, I did not mean standards as in "ISO" or some other standard.
ment some concept for example when you press ctrl + b in openoffice orca 
responds "Bold on " this also happens in other free and proprietory 
screen readers.

I think this is another example of doing the thing that makes sense. It
turns out that other screen reader developers also recognize that this
makes sense, so they do it too. :-)

In other words, given a user who has just toggled bold on in your screen
reader, what should you speak in response? (As hard as it is, pretend
that no other screen reader has implemented such a feature yet.) Your
goals are:

* Communicate accurate information
* Do so in an efficient matter (i.e. as few words as possible)

What's relevant here? the format (bold) and its new state (on). Ergo,
"bold on." To me it is a natural (and one could argue, the only) choice.

With this in mind, let's now to proceed to the following question, which
we've been discussing largely to no avail on this list, namely: Given a
user who wants to know the time (again, imagining that no other screen
reader has implemented such a feature yet), what is the logical choice?
Your goals for this command -- and all commands -- are:

* easy to discover and to remember
* easy to perform (i.e. physically)

When you want a heading you go with h, when you want a heading at level
2 you go with 2, when you want a list you go with l, when you want a
list item you go with i, when you want an entry you go with e, when you
want a radio button you go with r, ... I'm a user who wants to know the
time. I think I'll guess.... Oh I dunno.... F12. Yeah, right. Anyone who
said F12 (keeping in mind the rule here: Pretend no other screen reader
has implemented such a feature yet), deserves to be voted off the
island. <smile>

Mind you, I sympathize with those of you who are JAWS users and/or who
work with JAWS users and who find JAWS commands more familiar. And I
encourage you to rebind any Orca commands you'd like to whatever you'd
like -- on your local system(s) -- to make Orca easier for you
personally. HOWEVER: For the umpteenth -- and hopefully the last --
time:

* Orca is not JAWS. Orca will never be a JAWS clone. There will always 
  be differences between Orca and JAWS. I'm sorry.

* The goal of Orca is to provide compelling access to the GNOME desktop
  for GNOME users. Regardless of where the users have come from, be it
  from OS X or from Windows or from a console environment, or from KDE.
  Regardless of if they have experience with VoiceOver or JAWS or NVDA 
  or Window-Eyes or Hal or have never used a screen reader before but
  are starting to because of a change in vision, or because they are 
  children learning how to use a computer for the first time.

* Maintaining compatibility modes, layouts, whathaveyou for additional
  screen readers to try to make things "more familiar" in Orca will
  suck up time and energy that Orca developers do not have because this
  is not something you set once and forget about. There will always be
  a danger of a change in Orca's native behavior breaking some 
  compatibility mode.

* We don't have things in Orca like a virtual viewer and a virtual 
  buffer and an off-screen model and video intercepts, etc. But we
  do have flat review mode (which JAWS doesn't have; perhaps they need 
  to clone us), and we present web content as it appears on the screen
  so that you can see the same thing that your sighted peers do 
  (perhaps JAWS should do that instead of totally recreating and re-
  rendering what's on the screen into a format that is very different
  from what your sighted peers see). As a result of these differences,
  even if we could reasonably maintain a compatibility mode, there will
  always be differences significant enough to cause compatibility mode
  users to get confused and frustrated when Orca doesn't behave like
  JAWS (or whatever screen reader their mode is attempting to emulate).

Because of these things, all proposed new keybindings will have to pass
the following test:

"Imagining that no other screen reader has this command, what keybinding
would make the most sense because it is discoverable, memorable, and
physically easy to execute?" Alternatively, a candidate keybinding which
has overwhelming community support will almost certainly be fine by me.
<smile> Proposed keybindings which fail the "makes sense" test and which
lack overwhelming support will not be accepted.

Which brings us back to Orca+F12 for the time/date.

* Is it discoverable and memorable, keeping in mind we're imagining that
  no other screen reader has such a feature? No it is not. FAIL.

* Is it physically easy to execute? Not for Desktop layout users  
  because it will require anyone without super long fingers to move
  their left hand over to the right side of the keyboard. FAIL.

* Does it nonetheless have overwhelming community support? Based on all
  the discussion I've seen this past week, it is clear that it does not.
  FAIL.

As a result of these failures, Orca+F12 will *not* be the
default/shipping/upstream binding for causing the time to be presented.
Those who just can't live without it being Orca+F12, please let us know
if you need help learning how to rebind commands on your local system.

Orca+T seems to lack overwhelming community support (largely due to JAWS
compatibility mode advocates). But Orca+T to speak the Time is
discoverable and memorable. It's definitely physically easy on the
Desktop layout. It's a tad less natural-feeling on the laptop, but I can
very easily use my left had to press CAPS_LOCK+T. So I'd say it's fine
ergonomically. Therefore, I would be happy to accept Orca+T as the time
keybinding -- assuming the community feels that the time command should
be bound to something by default.

--joanie





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