Posts Tagged ‘accessibility’

Impressions of Hal from Dolphin

December 19, 2009

These are my impressions of the Hal screen reader from Dolphin in no particular order, as I

continue to test it. I’ll update this as I continue evaluating it and in response to

comments.

The installation process went fine, but I had to press the setup button inside a WinZip self

extractor in order to get the talking setup to run.

If another screen reader’s mirror driver is enabled, Hal will break (mainly by not reading

certain list views and combo boxes).

Upon rebooting, Hal came up with Realspeak and walked me through its startup wizard, asking

me to set various options such as speech rate and character echo settings. It also asked me

to update its map files, which I allowed and had no trouble with.

It comes with Realspeak, Orpheus and Eloquence. Orpheus is the most responsive and has the

fewest problems. Realspeak sometimes will start speaking the next phrase while the current

one is ending, while Eloquence isn’t too responsive and pauses in strange places in addition

to the default annoying Eloquence pauses that haven’t been suppressed.

SAM (Synthesizer Access manager) loads every driver it has as separate processes into memory

at the same time, even for devices I don’t have, cluttering up the task manager.

Standard WinForms (.net) apps don’t work. I tested with EdSharp, and got very disappointing

results. The edit field was just read as “control”, while the menus didn’t speak at all.

While browsing the web, the standard control+enter keystroke for opening links in new tabs

doesn’t work. In order to do this, I have to press delete to right click, then go to the

menu item to open in new tab.

Mozilla Thunderbird (either 2.x or 3.0) is not supported at all, and gives no useful

information when tabbing around the interface.

While selecting by lines in notepad, the lines I’m selecting aren’t automaticly read.

List view fields are read in terms of screen text, so anything that doesn’t fit on the

screen gets cut off.

Capital letters aren’t announced by default. If turned on, Hal will announce “capital”

before any word that is capitalized, and mixed before a mixed-case word. There is an option

buried in the menus to change this to beep, but it’s either all or nothing; it can’t be set

to only announce when reading by character.

A distinction is made between the left and right modifier keys when talking about hotkeys.

For example, mute speech is set to left control. In order to use right control for this

purpose it must be added as an additional hotkey.

The hotkeys don’t repeat when held down, whereas every other key on the keyboard does.

Gathering passwords with the JAWS builtin keylogger

October 19, 2009

JAWS so helpfully contains a built-in script that logs all keys pressed on the keyboard. This method has a better chance of working on XP than the others. You must have a user account on the machine to make this work.

1. Open Keyboard manager, and open the default file. Add a key to the “ToggleKeyboardLogging” script.

2. Once done, log out of the machine. Your profile will still be loaded. Press that key. The only thing JAWS will say is “enabled”. Log into the machine, then open keystrokes.log in your jaws program directory. all keys pressed will be there, from the last time the script was enabled.

JAWS security flaw, round 2

October 19, 2009

In my First Post, I described a security vulnerability that allowed local users to gain system-level access to a machine. A quick test with JAWS 11.0.729, the release build of JAWS 11, reveals that it is fixed. Here is a slightly different set of instructions that will do the same thing.

1. From the login screen, press insert+j, and navigate to utilities/configuration manager.
2. When configuration manager opens, press control+o.

3. press the Import button. The open dialog will appear.

4. On my Windows 7 test machine, I got an error box that can safely be dismissed. Once done, type %windir%\system32\*.exe into the open dialog.

5. find cmd in the list, and press the applications key on it. Select Run as administrator if it appears. If not, keep following these steps.

6. From cmd’s context menu, pick select. answer no to the question asking you to overwrite settings files, if it comes up.

7. press import, and pick cmd from the list again. Activate the context menu, and select Run as administrator.

If done correctly, you should have an administrative command prompt.

Critical security flaw in JAWS

October 16, 2009

I have found a critical security flaw in the JAWS Screen reader that allows an attacker to gain full system-level access to

the machine. I have tested this on 32-bit Windows Vista
with JAWS 10.0.1154 and 32-bit Windows 7 with JAWS 11.0.611 Beta.

Instructions:

1. From the Windows logon screen with JAWS running, press insert+f2. Run JAWS Manager will appear.
2. Select Settings Packager, and press ok. Settings Packager will open.
3. From Settings Packager, go to File menu > Open, or press ctrl+o.
4. In the open dialog, type “%windir%\system32\*.exe” into the file name field (without the quotes) and press enter.
5. In the list of files, find cmd. Right click on it, or press the applications key and select Run as Administrator.
A system-level command prompt should open. To get out of it, type exit and press enter, then close the Settings Packager.

Update: audio demonstration available here.
 

Contact information:
tyler Spivey
Email: tspivey@pcdesk.net, PGP key: 0x048C58A4
Twitter: tspivey

My Thoughts on the Current State of Command Line Accessibility

November 14, 2007

I am a heavy user of the command line, and command
line oriented operating systems such as Linux and
OpenSolaris. I am blind,
and use a screen reader to access my computer. This means that
various things are inaccessible to me, such as captchas that have no
audio alternative. The command line,
being mostly text based, is almost perfect. I say
almost perfect, because the screen reading technology isn’t really geared
towards certain types of text. Consider that as new
text arrives, the screen reader will attempt to read it, from
top to bottom, left to right. This works perfectly
in programs such as ed, because I can type a command and get a response on the next line.
However, this all falls apart when certain classes of programs are invoked,
such as screen editors (vim, emacs), some parts of
mailers (pine, mutt), and tabular output
utilities (df, vmstat, prstat). These programs are in different classes and have
their own problems, so I’ll discuss them below.

Full screen applications

The problem with these is that a screen reader
doesn’t know that, for example, j will move
the cursor to the next line in Vim. Nor does it know that l
will move to the next character. if I type
j in vim, or ^n in emacs, the screen
reader will attempt to read what has changed on the
screen, which is usually nothing – just
the position of the cursor. At this point,
the screen reader isn’t sure if I typed a j because I wanted to insert a j, or
if I typed a j because I wanted to move to the next line. I can
attach, at least in the windows screen readers, a script to the j key, but that wouldn’t always be accurate due
to network delays and such – I have no way of knowing when the cursor
has successfully moved in order to read. This isn’t
a stop-all for screen programs, but personally, I would rather focus on
my work rather than hitting j, and then whatever
command my screen reader uses to read the current line. This gets
progressively more annoying when I attempt to move by character – character right, read
current character. There are scripts tied to the arrow keys, but those sometimes don’t work, and conflict with
the automatic echoing of newly written screen text. Ed is great,
but it’s not so good for writing emails that are
expected to be word wrapped, nor is the lack of an edit current
line function beyond ^u and ^w – if I realize that
I’ve made a typo at the beginning of the line, I have to either kill
the line and retype it, or hit enter, fix the typo and keep writing.

Tabular Output Programs

Tabular output programs produce output in a columnized table format,
for example:

Filesystem             size   used  avail capacity  Mounted on
fs/home/tyler          109G    86G   4.1G    96%    /export/home/tyler

This is a rather simple table, and mostly self explanatory. I’ve used
the df command so many times, and it doesn’t have too many columns, so I can find out where
I am relatively easily. But in contrast, take this vmstat output:

 kthr      memory            page            disk          faults      cpu
 r b w   swap  free  re  mf pi po fr de sr dd dd f0 --   in   sy   cs us sy id
 0 0 43 428760 14456  1   4  3  1  1  0 51  6  0 -0  0  426  106  109  1  3 97
 0 0 52 416600 21632  1  23 105 0  0  0  0  0  0  0  0  851  490  276  1  7 93
 0 0 52 416600 21632  7   7  0  0  0  0  0  0  1  0  0  801  489  263  1  6 93
 0 0 52 416600 21632  7   7  0  0  0  0  0 19  0  0  0  942  410  451  0 26 74
 0 0 52 416600 21632  7   7  0  0  0  0  0  0  0  0  0  813  475  246  1  6 93

This table has approximately 22 columns, with different sized numbers. I can bring my
screen reader’s cursor to, say, the SR column, and go read down by words, but if a 100 suddenly
changes to a 0, the number will move and the screen reader will get confused on which way to go –
left or right – to find it again. I can find myself
reading some other column that I don’t intend to read, but might not notice. Of course,
reading this from top to bottom, left to right is impossible.

I propose a solution to all this. A screen reader, in userspace, that will
wrap the shell and provide commands for moving around. While such
things exist, for example
YASR,
I feel that there should be an easily modifyable,
extendable screen reader, perhaps written,
as the Orca project for gnome,
in Python. Orca is all
well and good for the Gnome desktop, but it’s terminal support feels like it was
added on as an afterthought, at least to my view of
working. I want something that is
stable, reliable and customizable. In-kernel
screen readers are great if you want to view the boot messages, and are even nessisary for certain
types of recovery operations where a serial console is unavailable, but this adds the complexity of
kernel development and restricts the languages that they can be written in.