Is your text application accessible ? Quite difficult question. There is an accessibility applications howto on TLDP, but the best way to check accessibility of your software is to just test in real conditions.
What we propose on this page is a guide for testing by yourself how well BRLTTY will be able to read your text application and show it on a braille display.
Since braille cells are very expensive, braille devices are typicall only 20 or 40 cells only. I.e. blind users only see 20 or 40 characters at a time. In order to see the rest of the screen, they have to use buttons on the device. As you can imagine, it can be very tedious: for instance, to read a menu, you'd have to press a button to go to the top of the screen, press another button several times to skip the few lines above the menu, then press it several times to read each line of the menu, down to the end. Then you need to find out which line is currently selected, e.g. by "looking" at colors (this is a special mode of screen readers), and bring "that" to the menu item you want. You thus have to play with both the PC keyboard arrows, and the device navigation buttons. Now, if the application always puts the TTY cursor in front of the currently selected item, the screen reader will actually automatically display that part of the screen. The user thus doesn't need to use braille navigation buttons any more: just pressing the PC keyboard arrows will at the same change the currently selected item in the menu, and show the new item on the braille device. This is way more convenient.
You will need several pieces of software:
If you can get all that from your distribution then fine, go to next section.
If you don't have (a recent enough) BRLTTY:
(or /sbin/brltty in case brltty is not in /bin)
That will open a 40-cells text window. It is a representation of a braille display. If you have a UTF-8 environment and appropriate fonts, you will even get the braille representation.
If "x startup problems" appears (because you're not root, actually), just ignore the warning and click on some cell to make the message disappear.
If no window shows up, append -l debug -e to get debugging messages to be sent to the BRLTTY mailing list.
Now you can play with your application and see how well it appears on the braille display!
Braille devices have more or less navigation keys for moving around the terminal. Configure your window manager to never let the BRLTTY window get the focus and then you can use -B model=xxx to try different models:
By right-clicking on the window, a popup menu appears, letting you change on the fly the model and size of the braille device. Yes, it sometimes crashes after few changes.
You can use the curses interface of qemu to check how well it gets read:
BRLAPI_HOST=127.0.0.1:1 qemu -cdrom yourimage.iso -hda hd.img -curses -k fr
Note the -k fr option, which is needed to tell qemu that the real keyboard is e.g. a french (fr) one. See /usr/share/qemu/keymaps/ for the possibilities.
You can check for automatic USB braille device detection by using qemu's braille device emulation:
BRLAPI_HOST=127.0.0.1:1 qemu -cdrom yourimage.iso -hda hd.img -usbdevice braille
That will make qemu emulate a virtual USB braille device, and output the result on brltty's fake braille device.
We won't repeat what TLDP says in is How to Develop Accessible Linux Applications, but highlight the "Focus" paragraph.
A text terminal has a cursor. Many applications choose to just hide it and leave it in the corner of the screen. This might be fine for most people, but it is a considerable loss for screen readers: the cursor is very handy to quickly tell which portion of the screen is important (text to type/read, currently selected file/mail/button, etc.). So please make sure that you provide the user at least an "Accesibility" option which enables moving the cursor to such handy place (or better, have it the default behavior).
A rule-of-thumb could be "put cursor at the beginning of what is most useful to read now". For instance, put the cursor at the beginning of the text of the currently active button.
Note that you can actually hide the cursor (while still moving it around to give a hit to the screen reader) by using the civis and cnorm terminfo strings.
If you are not sure about the right way, just ask for advice on mailing lists like brltty@mielke.cc, debian-accessibility@debian.org, blinux@redhat.com, ... People will just tell you what they would prefer.
Improving accessibility is difficult, but it is very beneficial for a not-so-small part of your users...