Ryan,
This is good to see the reach-out from a vendor before release of a updated
or new feature. My wish list and I have not reviewed the other responses. My
responses are based for a CLI (Command Line Interface) terminal with a
screen reader. The comments are really quick notes.
1. Correct cursor tracking with all screen readers. I can navigate the
command line by char, word, beginning and end of line, delete from cursor to
end of line, etc. The screen reader announces all this information
correctly. Speakup on Linux does this brillently. Thus if in Emacs for
example. A shortcut command is used to open a search edit area. Then the
cursor moves to this edit area and reads out the labels (name) or prompt,
plus follows the cursor.
2. Ability of scrolling back the buffer for text which has scrolled off the
page. This should be a shortcut key which places the terminal in a history
mode. Then the screen reader can use the normal navigation commands like
moving by character (left/right arrows), by word (ctrl left and ctrl right
arrow), line, etc. selecting and Copying text out of the history is a must.
The current information on the screen must be able to reviewed by the screen
reader by the methods available. Under the Mac and Linux, the screen reader
does this without the need of a special history buffer. But I cannot think
of a generic way to do this under windows due to multiple screen readers
that are available.
3. Being able to correctly scroll forward and back the command history.
Being able to perform reverse search as well. Similar to how Linux works.
4. If a text menu UI appears as you are using another OS ;via ssh or telnet.
Being able to correctly follow the focus indicator. Reading out the content
when the page is updated. Filtering out decorative characters used in such a
menu UI construct. This touches upon VI, Emacs and similar text console
apps.
5. Full vt100 and higher support. The issue here with screen readers is when
new information is received such as the colour changes from phrase 1 to
phrase 2. Most screen readers I have used read both phrases. This links back
to the prior point.
6. Titles of tabs which work with screen readers. So you can jump between
the tabs and know which terminal session is open. Shortcut keys must be
available to support quick jumping.
7. Status bar, being able to move focus to the status bar and interrogate
the information. Also the screen reader must be able to detect the status
bar and read out the information by using screen reader commands. The status
bar should not interfere with normal behaviour.
8. Report of system errors related to the terminal session. Such as the
session has disconnected.
9 Support of custom colours for users with low vision.
10 being able to paste, copy and cut information from the command line.
11. All the UI's which are available within the terminal app are accessible.
Menus, dialogs, etc.This is outside the CLI console screen.
12. supporting magnification technology.
13. If the size of the window is changed, does not impact the screen reader
in any fashion.
14. Using Windows CLI, supporting the option of opening files using the
default app would be nice.
15. Launching web pages from the CLI.
16. Being able to open sub-shells like Bash when you are within the windows
CLI. This might be outside your scope.
17. Handling multiple column text. That is, if you are in a router like
Cisco's iOS-Xe. Some commands list the information in columns. Being able to
navigate this effectively would be great. Currently you have to remember the
columns and headings.
18. Stopping duplicate text being spoken when information is updated.
19. Supporting Linux Cursers in Windows CLI. So when I write python or other
scripting languages. I can use this library. Now I am not sure if this is a
limitation of Python or the CLI.
20. Handling full screen text based apps such as VI Emacs is the area of
challenge as I see it. As screen readers come in all sizes. How is this done
is the challenge area as some screen readers might not have the capability
to handle multiple focuses, track text updates, etc.
As I understand terminal programs that uses vt100 or other similar terminal
protocols. There are codes which are sent with the text to perform specific
actions on the screen. Such as changing colours, moving cursor, etc. If the
terminal could understand these codes and convert them into a meaningful way
to a screen reader if is important. This would be great. Such as the current
colour, cursor location, reading out a panel of text, etc.
-----Original Message-----
From: Billy Irwin