Accessibility (Also: Accessible)

Within these guidelines,"accessible Web content" and "accessible authoring tool" mean that the content and tool can be used by people regardless of disability. To understand the accessibility issues relevant to authoring tool design, consider that many authors may be creating content in contexts very different from your own:

• They may not be able to see, hear, move, or may not be able to process some types of information easily or at all;
• They may have difficulty reading or comprehending text;
• They may not have or be able to use a keyboard or mouse;
• They may have a text-only display, or a small screen.

Accessible design will benefit people in these different authoring scenarios and also many people who do not have a physical disability but who have similar needs. For example, someone may be working in a noisy environment and thus require an alternative representation of audio information. Similarly, someone may be working in an eyes-busy environment and thus require an audio equivalent to information they cannot view. Users of small mobile devices (with small screens, no keyboard, and no mouse) have similar functional needs as some users with disabilities.

1 def'n
(atag-match)

In our def'n, we mix up the two senses (tool vs. produced content). I suggest we keep them separate:

Accessible Application:

Application that has an increased likelihood of being easier to use by people with disabilities or people who are using the application under circumstances that impair their sensory or motor performance. For more information, see checkpoints 1.1 to 1.6.

This entails some changes:

• Guideline 1: Ensure that the tool is an *accessible application*
• Checkpoint 1.1: Ensure that the authoring interface follows all operating environment conventions for an *accessible application*
• Checkpoint 1.2: Ensure that the authoring interface enables editing of all element and object properties as required for an *accessible application*.
• Checkpoint 1.5: Ensure that the authoring interface enables keyboard navigation of editing views via the document structure.

Accessible Web Content:

Web content that conforms with *WCAG*. This Web content has an increased likelihood of being easier to use by people with disabilities or people who are using the application under circumstances that impair their sensory or motor performance. For more information, see *WCAG*.

This entails some changes:

• Guideline 2: Ensure that the tool is designed to produce *accessible Web content*
• Checkpoint: 2.3: Ensure that the author can produce *accessible Web content* in the markup language(s) supported by the tool.
• Checkpoint: 2.4: Ensure that the tool preserves *accessible Web content* during transformations and conversions.
• Checkpoint: 2.5: Ensure that any Web content automatically generates by the tool is *accessible Web content*
• Checkpoint: 2.6: Ensure that all pre-authored Web content for the tool is *accessible Web content*.
• Guideline 3: Support the author in the production of *accessible Web content*
• Checkpoint 3.7: Document all features of the tool that promote the production of *accessible Web content*.
• Checkpoint 3.8: Document the process of using the tool to produce *accessible Web content*.
• Checkpoint 4.4: Ensure that creating *accessible Web content* is a naturally integrated part of the documentation, including examples.

Accessibility Information

"Accessibility information" is content, including information and markup, that is used to improve the accessibility of a document. Accessibility information includes, but is not limited to, equivalent alternative information.

Accessibility Problem (Also: Inaccessible Markup)

Inaccessible Web content or authoring tools cannot be used by some people with disabilities. The Web Content Accessibility Guidelines 2.0 [WCAG20] describes how to create accessible Web content.

Outdated - I suggest:

Accessibility Problem

Instance of Web content that is not *accessible Web content*.

This entails a change:

• Checkpoint 3.6: Provide the author with a summary of the degree to which *accessibility problems* are present.

Accessible Authoring Practice

"Accessible authoring practices" improve the accessibility of Web content. Both authors and tools engage in accessible authoring practices. For example, authors write clearly, structure their content, and provide navigation aids. Tools automatically generate valid markup and assist authors in providing and managing appropriate equivalent alternatives.

Outdated - I suggest:

Accessible Authoring Practice

An authoring practice (e.g. creating a stylesheet, creating a document structure, writing clearly, etc.) that contributes to the production *accessible Web content*.

This entails a change:

• Guideline 4: Integrate *accessible authoring practices* into the overall "look and feel"

Alert

An "alert" draws the author's attention to an event or situation. It may require a response from the author.

Alternative Information (Also: Equivalent Alternative)

Content is "equivalent" to other content when both fulfill essentially the same function or purpose upon presentation to the user. Equivalent alternatives play an important role in accessible authoring practices since certain types of content may not be accessible to all users (e.g., video, images, audio, etc.). Authors are encouraged to provide text equivalents for non-text content since text may be rendered as synthesized speech for individuals who have visual or learning disabilities, as Braille for individuals who are blind, or as graphical text for individuals who are deaf or do not have a disability. For more information about equivalent alternatives, please refer to the Web Content Accessibility Guidelines WCAG 2.0 [WCAG20].

I suggest we use the edited first part of the WCAG def'n instead:

Equivalent

Content is "equivalent" to other content when both fulfill essentially the same function or purpose upon to the user. In the context of this WC document, the equivalent must fulfill essentially the same function for the person with a disability (at least insofar as is feasible, given the nature of the disability and the state of technology), as the primary content does for the person without any disability (e.g. the text "The Full Moon" might convey the same information as an image of a full moon when presented to users.).Note: that equivalent information focuses on fulfilling the same function. If the image is part of a link and understanding the image is crucial to guessing the link target, an equivalent must also give users an idea of the link target. Providing equivalent information for inaccessible content is one of the primary ways authors can make their documents accessible to people with disabilities.

This entails some changes:

• Checkpoint 3.4: Do not automatically generate *equivalents* or reuse previously authored *equivalents* without author confirmation, except when the context in which the original object is being used is known with certainty.
• Checkpoint 3.5: Provide functionality for managing, editing, and reusing *equivalents* for multimedia objects.

Attribute

This document uses the term "attribute" as used in SGML and XML [XML]: Element types may be defined as having any number of attributes. Some attributes are integral to the accessibility of content (e.g., the "alt", "title", and "longdesc" attributes in HTML).

2 def'ns
(atag-no match)
(uaag-closer match)

Recommend we follow UAAG def'n:

Attribute

This document uses the term "attribute" in the XML sense: an element may have a set of attribute specifications (refer to the XML 1.0 specification [XML] section 3).

Auditory Description

An "auditory description" provides information about actions, body language, graphics, and scene changes in a video. Auditory descriptions are commonly used by people who are blind or have low vision, although they may also be used as a low-bandwidth equivalent on the Web. An auditory description is either a pre-recorded human voice or a synthesized voice (recorded or automatically generated in real time). The auditory description must be synchronized with the auditory track of a video presentation, usually during natural pauses in the auditory track.

Recommend we follow UAAG def'n:

Auditory Description

An auditory description is either a prerecorded human voice or a synthesized voice (recorded or generated dynamically) describing the key visual elements of a movie or other animation. The audio description is synchronized with (and possibly included as part of) the audio track of the presentation, usually during natural pauses in the audio track. Audio descriptions include information about actions, body language, graphics, and scene changes.

Authored "by hand"

When the author specifies the precise text string, as by typing into a text editor.

Authoring Tool

An "authoring tool" is any software that is used to produce content for publishing on the Web. Authoring tools include:

• Editing tools specifically designed to produce Web content (e.g., WYSIWYG HTML and XML editors);
• Tools that offer the option of saving material in a Web format (e.g., word processors or desktop publishing packages);
• Tools that transform documents into Web formats (e.g., filters to transform desktop publishing formats to HTML);
• Tools that produce multimedia, especially where it is intended for use on the Web (e.g., video production and editing suites, SMIL authoring packages);
• Tools for site management or site publication, including tools that automatically generate Web sites dynamically from a database, on-the-fly conversion and Web site publishing tools;
• Tools for management of layout (e.g., CSS formatting tools).

Captions

"Captions" are essential text equivalents for movie audio. Captions consist of a text transcript of the auditory track of the movie (or other video presentation) that is synchronized with the video and auditory tracks. Captions are generally rendered graphically and benefit people who can see but are deaf, hard-of-hearing, or cannot hear the audio.

Check for

As used in checkpoint 4.1,"check for" can refer to three types of checking:

1. In some instances, an authoring tool will be able to check for accessibility problems automatically. For example, checking for validity (checkpoint 2.2) or testing whether an image is the only content of a link.
2. In some cases, the tool will be able to "suspect" or "guess" that there is a problem, but will need confirmation from the author. For example, in making sure that a sensible reading order is preserved a tool can present a linearized version of a page to the author.
3. In some cases, a tool must rely mostly on the author, and can only ask the author to check. For example, the tool may prompt the author to verify that equivalent alternatives for multimedia are appropriate. This is the minimal standard to be satisfied. Subtle, rather than extensive, prompting is more likely to be effective in encouraging the author to verify accessibility where it cannot be done automatically.

Conversion Tool

A "conversion tool" is any application or application feature (e.g.,"Save as HTML") that transforms convert in one format to another format (such as a markup language).

Document

A "document" is a series of elements that are defined by a markup language (e.g., HTML 4 or an XML application).

Editing View

An "editing view" is a view provided by the authoring tool that allows editing.

Element

An "element" is any identifiable object within a document, for example, a character, word, image, paragraph or spreadsheet cell. In [HTML4] and [ XML], an element refers to a pair of tags and their content, or an "empty" tag - one that requires no closing tag or content.

5 def'ns
(atag-match)
(uaag)
(wcag)
(css)
(xml)

Perhaps we can use the XML def'n:

Element

An element is a document structuring unit declared in the DTD. The element's content model is defined in the DTD, and additional semantics may be defined in the prose description of the element. The proper name for XML tags and the content they contain.
Example: <tag>content</tag>

Inform

To "inform" is to make the author aware of an event or situation through alert, prompt, sound, flash, or other means.

I suggest:

Inform

To make the author aware of an event or state. The tool may inform the author immediately or following an appropriate delay.

Markup Language

Authors encode information using a "markup language" such as HTML [HTML4], SVG [ SVG], or MathML [MATHML].

WCAG looking for a def'n of "markup"- according to Glossary

"markup format"?

Presentation Markup

"Presentation markup" is markup language that encodes information about the desired presentation or layout of the content. For example, Cascading Style Sheets [CSS1], [CSS2] can be used to control fonts, colors, aural rendering, and graphical positioning. Presentation markup should not be used in place of structural markup to convey structure. For example, authors should mark up lists in HTML with proper list markup and style them with CSS (e.g., to control spacing, bullets, numbering, etc.). Authors should not use other CSS or HTML incorrectly to lay out content graphically so that it resembles a list.

Not used in ATAG2.0.. Also - we are too pushy in this def'n - perhaps we can edit WCAG's def'n:

Presentation markup

Markup that achieves a stylistic (rather than structuring) effect. For example, the B, I or FONT elements in HTML.

Prompt

In this document prompt does not refer to the narrow software sense of a "prompt," rather it is used as a verb meaning to urge, suggest and encourage. The form and timing that this prompting takes can be user configurable. "Prompting" does not depend upon the author to seek out the support but is initiated by the tool. "Prompting" is more than checking, correcting, and providing help and documentation as encompassed in guidelines 4, 5, 6. The goal of prompting the author is to encourage, urge and support the author in creating meaningful equivalent text without causing frustration that may cause the author to avoid access options. Prompting should be implemented in such a way that it causes a positive disposition and awareness on the part of the author toward accessible authoring practices.

Outdated - I suggest the following from my proposal for techniques for checkpoint 3.1:

Prompt

"Prompt" should not be confused with the narrow software sense of the term. Instead, ATAG 2.0 uses "prompt" in a wider sense, to mean the process of eliciting author input. This process should be:
(1) initiated by the tool rather than the user.
(2) user configurable in form and timing.
(3) implemented in a way that invites authors to develop a positive disposition and awareness towards accessible authoring practices

Property

A "property" is a piece of information about an element, for example structural information (e.g., it is item number 7 in a list, or plain text) or presentation information (e.g., that it is marked as bold, its font size is 14). In XML and HTML, properties of an element include the type of the element (e.g., IMG or DL), the values of its attributes, and information associated by means of a style sheet. In a database, properties of a particular element may include values of the entry, and acceptable data types for that entry.

I suggest an update:

Property

A "property" is a piece of information about an element. This might be the the element type or the value of one of its attributes or some styling information. In a database, properties of a particular element may include values of the entry, and acceptable data types for that entry.

Structural Markup

"Structural markup" is markup language that encodes information about the structural role of elements of the content. For example, headings, sections, members of a list, and components of a complex diagram can be identified using structural markup. Structural markup should not be used incorrectly to control presentation or layout. For example, authors should not use the BLOCKQUOTE element in HTML [HTML4]to achieve an indentation visual layout effect. Structural markup should be used correctly to communicate the roles of the elements of the content and presentation markup should be used separately to control the presentation and layout.

Transcript

A "transcript" is a text representation of sounds in an audio clip or an auditory track of a multimedia presentation. A "collated text transcript" for a video combines (collates) caption text with text descriptions of video information (descriptions of the actions, body language, graphics, and scene changes of the visual track). Collated text transcripts are essential for individuals who are deaf-blind and rely on Braille for access to movies and other content.

Transformation

A "transformation" is a process that changes a document or object into another, equivalent, object according to a discrete set of rules. This includes conversion tools, software that allows the author to change the DTD defined for the original document to another DTD, and the ability to change the markup of lists and convert them into tables.

Unclear how this differentiates from conversion - suggest placeholder.

User Agent

A "user agent" is software that retrieves and renders Web content. User agents include browsers, plug-ins for a particular media type, and some assistive technologies.

Suggest we expand our def'n to an edited version of UAAG's def'n:

"A user agent is software that retrieves and renders Web content, including text, graphics, sounds, video, images, and other content types. A user agent may require additional user agents that handle some types of content. For instance, a browser may run a separate program or plug-in to render sound or video. User agents include graphical desktop browsers, multimedia players, text browsers, voice browsers, and assistive technologies such as screen readers, screen magnifiers, speech synthesizers, onscreen keyboards, and voice input software."

View

Authoring tools may render the same content in a variety of ways; each rendering is called a "view". Some authoring tools will have several different types of view, and some allow views of several documents at once. For instance, one view may show raw markup, a second may show a structured tree, a third may show markup with rendered objects while a final view shows an example of how the document may appear if it were to be rendered by a particular browser. A typical way to distinguish views in a graphic environment is to place each in a separate window.

Orphaned ATAG terms in WAI Glossary:

• Accessibility Awareness
• Accessible
• Appropriate
• Automated markup insertion function
• Available
• Content
• Current user selection
• Description link
• Documentation
• Equivalent Alternative
• Focus
• Generation Tool
• Haptic
• Inaccessible markup
• Publishing Tool
• Rendered Content
• Rendered View
• Selection
• Site Management Tool
• User-Configurable Schedule
• Whiteboard
• Wizard