Peter,
I think this document came from this list. It might be a place to begin.
Seven simple rules for programs made friendly to blind users
>From the web page http://www.artictech.com/howprog.htm
By Artic Technologies
How to write blindness friendly programs.
How to write application programs that Screen Access programs
can read!
This section is intended for product developers and custom
programmers who would also like their efforts to qualify for
purchase by the US Federal government (which requires software
to be adaptable for use by blind people). RELAX! Most of the
work has already been done for you by Artic and a few other
companies. All you have to do is follow the few SIMPLE rules
listed below and be consistent with low level programming
techniques from version to version.
IF YOU FEEL THAT YOU MUST BREAK THESE RULES TO MAKE YOUR
PRODUCT PERFORM BETTER THEN WE HIGHLY RECOMMEND THAT YOU ALSO
INCLUDE SUPPORT FOR MICROSOFT ACTIVE ACCESSIBILITY WHICH ALLOWS
US TO GET AT THE TEXT SOURCES YOU ARE HIDING.
A SIMPLE APPROACH: CLOSE YOUR EYES AND IMAGINE HOW A BLIND
PERSON WILL READ YOUR SCREENS.
* FIRST LOOK AT YOUR SCREEN LAYOUT AND HOW THE INFORMATION IS
GROUPED
* NOW CLOSE YOUR EYES AND DESCRIBE HOW YOU WILL NAVIGATE THE
SCREEN AND ACCESS INFORMATION FROM THE KEYBOARD.
* ARE THERE ANY SECTIONS YOU CANNOT ACCESS BY DIRECTING THE
CURSOR?
* ARE THERE UNRELATED TEXT STRINGS ON THE SAME LINE THAT WILL
BE READ TOGETHER IN A LEFT TO RIGHT MANNER?
RULE 1: MAKE SURE THAT EVERY MOUSE ACTION ALSO HAS A KEYSTROKE
EQUIVALENT!!!
This should be a common sense design rule for every good
programming effort since taking your hands off the keyboard to
click a mouse is a slow down even for sighted people. It is
terribly inefficient for blind users who must first probe around
looking for the right object to click on! This sin is very
common in both professionally written and amateur programs.
RULE 2: PLACE FIELD NAMES TO THE LEFT OF THE DATA FOLLOWED BY A
COLON!
Many data bases and forms are setup by people trying to be
creative. Hence, screen layouts can become very confusing and
impossible to sort out automatically by screen access unless
some common sense rules are used. FIELD NAMES SHOULD BE READ
BEFORE THE DATA IS SPOKEN SO PLACE THE FIELD NAME TO THE LEFT OF
THE DATA. TERMINATE THE FIELD NAME WITH A COLON SO WE CAN
DISTINGUISH BETWEEN THE DATA AND THE NAME IF THE USER WANTS TO
HEAR THE DATA REPEATED.
RULE 3: AVOID SIDE BY SIDE TEXT IN COLUMNAR FORMAT.
We are pretty good at tracking most screen activity (without you
guys even knowing we are watching what you do), but we can't
read your mind trying to figure out where column breaks occur.
This makes us combine unrelated text from two columns that falls
on the same line. THINK ABOUT IT!
RULE 4: DO NOT BYPASS SYSTEM SERVICES FOR POSTING TEXT IN
OBJECTS.
If this was a perfect world and the look and feel of modern
computers would remain constant for more than 6 months at a time
then the job of screen access developers would be much easier.
What happens instead is that new techniques are always being
explored by programmers to get around the sluggishness and
constraints that an operating system imposes. This usually
forces a programmer to bypass fundamental services and go direct
to a resource to speed things up. THIS IS THE NUMERO UNO SIN!
Screen Access programs cannot speak text if you hide it!
RULE 5: USE THE PROVIDED OPERATING SYSTEM CONTROLS.
We cannot zig and zag with you if we don't understand your
proprietary mechanism?
RULE 6: DO NOT CONVERT TEXT INTO ARTISTIC BITMAPS.
How well do you think speech works with pixels?
RULE 7: DO NOT DO BIZARRE THINGS WITH KEY CODES!
Hey 3270 guys! I'm mostly referring to you. How in the heck do
you think we can speak the keyboard if you have assigned
proprietary codes?
----------
End of Document
At 03:31 PM 10/2/98 -0400, you wrote:
>I suppose most people who use screen readers have gotten used to the
>subtleties of their systems. For instance, I can tell the difference
>between a comma and a period because of the slightly longer pause after
>the period.
>
>I can't however, tell when there is a new paragraph.. When I press ALT R,
>the reader goes from the last sentence in one paragraph to the first of
>the next with the same delay as if there were no new paragraph.
>
>I suspect that if I were to listen to the cassettes that came with the
>program, I would find how to create that longer delay, or maybe how to
>have it making a clicking sound to indicate a new paragraph. But maybe the
>information isn't in those cassettes and I will spend a lot of time
>getting frustrated and searching. So, I usually don't bother and just
>don't make the change.
>
>Is this laziness? Do other people on this list doe the same thing, that
>is, you want to make a small change, but the hassle of making the change
>deters you?
>
>Anyway, my solution is to ask miscellaneous questions to this list, as the
>problems come up.
>
>Firstly, can somebody here tell me how to program Vocal eyes to pause when
>it reads two hard returns, with and without a period. For some purposes, I
>want to define a paragraph break regardless of the presence of a period.
>
>Secondly, and maybe this is related, how do I change the pronunciation of
>individual words in vocal Eyes. It currently reads Jesus as, "hey, Zeus,"
>as if I'm summoning the Greek God. Christ is also pronounced to rhyme with
>grist.
>
>Thirdly, does anybody know how to search for a hard return or a tab in
>word perfect 6.1. In version 5.1, I simply pressed F2 and then the return
>button or the tab button. With 6.1, thos keys bring me to a menu choice. I
>haven't been able to figure out how to enter the hard return code after
>pressing F2.
>
>I just got an idea. Perhaps if I delete a hard return code, I can undelete
>it when I'm asked what to search for, but maybe that won't work.
>
>If somebody knows an easy way, please let me know as soon as possible for
>this third one. I have to fix a document by tomorrow. Thank you.
>
> Peter Seymour
>
>
>
>
>
>
>
|
