The interface of a text application is realized through a text application directing which characters should be placed on the screen, along with either a hardware terminal or a terminal application that displays the characters produced by the text application. Some text applications render like a TeleTYpewriter (“TTY”); their output is always appended, like an ever growing file. Such text applications are often called “command-line applications” or occasionally “TTY-applications”, and their output can optionally be redirected to a file for later review. Others explicitly place text into a matrix of fixed width character cells on a screen (sometimes with specific foreground and background colors). Similar to a web application, the text application may execute primarily on a remote server or execute locally, and a local client terminal application handles the visual display (similar to a web user agent). Input to the text application itself is provided exclusively through a keyboard interface.
Strategies for making text applications accessible through assistive technology involve two key tasks: (1) obtaining all of the text displayed in the interface, and (2) performing an analysis on that text to discern structural elements and screen updates.
For example, a text application screen reader might directly access the matrix of character cells in the interface and provide a screen review mechanism for the user to review that matrix of characters (by sending the output to synthetic speech and / or a braille display). Alternately, a text application screen reader might directly consume the output rendered (perhaps by acting as its own terminal application or by analyzing the “TTY” output). The text application screen reader would also analyze the spacing and layout of the text in the matrix to provide features such as reading columns of text in a multi-column layout, discerning headers through analysis of line spacing, indentation and capitalization, and discerning input fields or user interface components, etc. by scanning for the use of inverse video or for text appearing in brackets or text from the character graphics codepage (ASCII codes greater than ‘0x7F’). Some of this analysis might also be done through the use of filter tools that transform the output of a program (e.g. through reformatting “TTY” output rendered to a file or as direct input to a filter too).
Similarly, a text application screen magnifier would gain access to the matrix of character cells in order to magnify them or re-display them in a larger font. It would scan for screen refreshes / updates and apply heuristics to what had changed in order to decide what sub-matrix of character cells should appear in a magnified view. It would also scan for inverse video and a moving text cursor to track text being input by the user (and might combine the text matrix scanning with scanning of the keyboard input to match user input to what is appearing on the screen).
To apply WCAG to text applications, it is necessary to apply the glossary terms “accessibility supported” and “programmatically determined” in the context of how text applications are rendered and the history of assistive technologies that made them accessible.
As noted above, in a text interface the terminal application renders the characters on the screen, just as a web browser typically renders content for a web application. Thus for example, in success criterion 1.4.4 Resize Text, a text application could achieve 200 percent resizing when the terminal application client that is rendering it has this capability (cf. WCAG 2.2 Technique G142 Using a technology that has commonly-available user agents that support zoom). Many web pages and web applications use this approach to meet success criterion 1.4.4 Resize Text through no explicit action of their own.
A similar approach could also be used for success criterion 1.4.3 Contrast (minimum) (cf. WCAG 2.2 Technique G148: Not specifying background color, not specifying text color, and not using technology features that change those defaults): relying on the terminal application client to render the text with sufficient contrast against the background. In fact, many terminal applications allow the user to force all text to share a single user-chosen foreground color (and a single user-chosen background color), overriding the text application's specified colors in order to meet the user's desires or needs.
Since many assistive technology analysis techniques depend upon discerning the location of the text input cursor, terminal application use of “soft cursors” and “highlight bars” may bypass those analysis techniques and cause failures of success criteria.
The way to think about “accessibility supported” and “programmatically determined” may seem a little different for text applications, but the definitions are unchanged. Because assistive technologies developed analysis techniques to recognize many forms of tabular layout, column headers, and section headings, such recognized layouts are by definition “accessibility supported”. Where assistive technology is able to extract and present that information, it is “programmatically determinable”—even though no explicit markup or API was used to make it so. While such assistive technology analysis techniques are not used for supporting newer technologies, the fact that such previous analysis work was done allows us to apply WCAG 2.2 to text / command-line applications.