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