Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

js2306a #172

Merged
merged 20 commits into from Jul 25, 2023
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
20 commits
Select commit Hold shift + click to select a range
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Jump to
Jump to file
Failed to load files.
Diff view
Diff view
Expand Up @@ -4,30 +4,34 @@ Background on Text / Command-line / Terminal Applications and Interfaces
How text interfaces are realized
--------------------------------

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.
The interface of a text application is realized through a server application directing which characters should be placed on the screen, along with either a hardware terminal or a terminal application that displays the characters. The client terminal application for text applications is analogous to a web user agent for web pages. Also like web applications, text applications may execute primarily on a remote server or execute locally.

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).

Historically, input to the text application itself is provided exclusively through a keyboard interface, though Automatic Speech Recognition (ASR) based voice input is sometimes now an alternative option - especially on mobile devices.

How text applications have been made accessible via assistive technology
------------------------------------------------------------------------

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.
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 detect screen updates and attempt to discern structural elements.

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).
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). A text application screen reader might also attempt to 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 by scanning for the use of inverse video, for text appearing in brackets, or for 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 tool).

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).
Similarly, a text application screen magnifier would gain access to the matrix of character cells to magnify them or re-display them in a larger font. It would scan for screen refreshes and updates and then 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).

Applying WCAG 2.2 to text applications
--------------------------------------

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.
To apply WCAG to text applications, it is necessary to apply the glossary terms [accessibility supported](#dfn-accessibility-supported) and [programmatically determined](#dfn-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](http://www.w3.org/TR/WCAG22/#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](http://www.w3.org/WAI/WCAG22/Techniques/general/G142)). Many web pages and web applications use this approach to meet success criterion [1.4.4 Resize Text](http://www.w3.org/TR/WCAG22/#resize-text) through no explicit action of their own.
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. As an example, for success criterion [1.4.4 Resize Text](http://www.w3.org/TR/WCAG22/#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](http://www.w3.org/WAI/WCAG22/Techniques/general/G142)). Many web pages and web applications use this approach to meet success criterion [1.4.4 Resize Text](http://www.w3.org/TR/WCAG22/#resize-text) through no explicit action of their own.

A similar approach could also be used for success criterion [1.4.3 Contrast (minimum)](http://www.w3.org/TR/WCAG22/#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](http://www.w3.org/WAI/WCAG22/Techniques/general/G148)): 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.
A similar approach could also be used for success criterion [1.4.3 Contrast (minimum)](http://www.w3.org/TR/WCAG22/#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](http://www.w3.org/WAI/WCAG22/Techniques/general/G148)): 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 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.

<div class="note">It is outside of the scope of this document to define WCAG techniques for non-web ICT. These examples are simply raised here to illustrate how WCAG 2.2 success criteria can be applied to this older class of applications that pre-date the Web.</div>
<div class="note">It is outside of the scope of this document to define WCAG techniques for non-web ICT. These examples are simply illustrations of how WCAG 2.2 success criteria can be applied to this class of non-web software applications.</div>

The way to think about “[accessibility supported](http://w3c.github.io/wcag2ict/#wcag2ict-def_accessibility-supported)” and “[programmatically determined](http://w3c.github.io/wcag2ict/#wcag2ict-def_programmaticallydetermined)” 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.
The way to think about "accessibility supported" and "programmatically determined" may seem a little different for text applications, but the definitions are unchanged. Unlike the semantic objects of graphical user interfaces and web pages, the output of text-based applications consists of plain text. A terminal emulator acts as the user agent for text-based applications; it might render some content such as escape codes as semantic elements, but otherwise exposes only lines of text to assistive technology. Where assistive technology is able to interpret the text and any semantic objects accurately, the content is "programmatically determinable"—even though no explicit markup was necessarily used to make it so.

<div class="note">The terminal application itself is “traditional” non-web software ICT. It is only for the text application that there is a need to take this approach with these glossary terms.</div>
11 changes: 8 additions & 3 deletions text-command-line-terminal-applications-and-interfaces.md
@@ -1,8 +1,13 @@
Text / Command-line / Terminal Applications and Interfaces
----------------------------------------------------------

Text applications are a class of software ICT that appeared decades ago, prior to the emergence of the graphical user interface (GUI) and the Web. The interface of a text application is generated using only text characters, and either a hardware terminal or a software terminal application handles the rendering of the text application—similar to how a web user agent handles the rendering of a web application. Text applications only accept text input (though some terminal applications which render text applications in the GUI may utilize a mouse or other input devices). Command-line applications are a subset of text applications with further specific properties.
Text applications are a class of software ICT that appeared decades ago, prior to the emergence of the graphical user interface (GUI) and the Web. The interface of a text application is generated using only text characters, and either a hardware terminal or a software terminal application handles the rendering of the text application—similar to how a web user agent handles the rendering of a web application. Text applications only accept text input, though some may also support the use of a mouse or other input devices. More recently, terminal applications which render text applications in the GUI may utilize spoken input through Automated Speech Recognition (ASR). Both GUI and native text environment interfaces also now commonly support word-completion prediction technologies. Command-line applications are a subset of text applications with further specific properties.

Historically, assistive technologies developed alongside text applications, and several of these use a variety of analysis and scripting techniques to make text applications accessible. Although there are far fewer new text applications being developed compared to new GUI or web applications, text applications remain in use today, and both text applications and the assistive technologies designed for text applications are in active development.
Historically, assistive technologies developed alongside text applications, making it possible for text applications to be accessible. Although there are far fewer new text applications being developed compared to new GUI or web applications, text applications remain in use today. In fact, command-line interfaces have seen a resurgence in recent years, especially in popular programming and revision tracking environments with continued development and greater functionality. In some cases this has precipitated renewed developments in assistive technology support for text applications.

Though this class of applications predates the Web, WCAG can be applied to them. As noted in [Appendix B. Background on Text / Command-line / Terminal Applications and Interfaces](#background-on-text-command-line-terminal-applications-and-interfaces), applying WCAG to text / command-line applications involves understanding how text applications are rendered, how text applications have been made accessible via assistive technologies, and how to apply the concepts of “accessibility supported” and “programmatically determined” to text applications.
Assistive technology support continues to evolve in today's text applications. Key examples include:

maryjom marked this conversation as resolved.
Show resolved Hide resolved
* In command line interfaces (CLI), support often includes context-sensitive help, so that help output following one command argument is different from the help provided following two arguments, and different still after three arguments. This helps users be more efficient and places no new requirements on assistive technologies.
* Output options generally include machine-readable structured text formats (such as JSON), in addition to the still powerful and widely used options of input/output redirection and piping. In these scenarios the assistive technology user can make use of the same range of output options as anyone else who finds the CLI environment compelling.

As noted in [Appendix B. Background on Text / Command-line / Terminal Applications and Interfaces](#background-on-text-command-line-terminal-applications-and-interfaces), applying WCAG to text / command-line applications involves understanding how text applications are rendered, how text applications have been made accessible via assistive technologies, and how to apply the concepts of “accessibility supported” and “programmatically determined” to text applications.