Repair Text, Definitions, Etc.

To: UA List
Re: Repair Text, Definitions, Etc.

Suggestion 1: Add note to checkpoint 2.3.

Old (29 September 2000):

"2.3 Provide easy access to each equivalent and each equivalency target 
through at least one of the following mechanisms: (1) allowing configuration 
to render the equivalent instead of the equivalency target; (2) allowing 
configuration to render the equivalent in addition to the equivalency 
target; (3) allowing the user to select the equivalency target and then 
inspect its equivalents; (4) providing a direct link to the equivalent in 
content, just before or after the equivalency target in document order. 
[Priority 1]"
"Note: For example, if an image in an HTML document has text equivalents, 
provide access to them (1) by replacing the image with the rendered 
equivalents, (2) by rendering the equivalents near the image, (3) by 
allowing select the image and then inspect its equivalents, or (4) by 
allowing the user to follow readily available links to the equivalents."
"Techniques for checkpoint 2.3"

New:

"2.3 Provide easy access to each equivalent and each equivalency target 
through at least one of the following mechanisms: (1) allowing configuration 
to render the equivalent instead of the equivalency target; (2) allowing 
configuration to render the equivalent in addition to the equivalency 
target; (3) allowing the user to select the equivalency target and then 
inspect its equivalents; (4) providing a direct link to the equivalent in 
content, just before or after the equivalency target in document order. 
[Priority 1]"
Note 1: For example, if an image in an HTML document has text equivalents 
and we assume that the user agent is able to present both images and text 
and is configured to do so, then user agent could provide access to them (1) 
by replacing the image with the rendered equivalents, (2) by rendering the 
equivalents near the image, (3) by allowing select the image and then 
inspect its equivalents, or (4) by allowing the user to follow readily 
available links to the equivalents."
"Note 2: Which mechanisms will be most appropriate will depend on whether 
the user agent supports the 'default' manner of presenting the content types 
for the equivalents and their equivalency targets. How a mechanism appears 
will depend on factors such as whether the user agent is configured to 
present the content itself or a 'placeholder' for various media objects (see 
checkpoint 3.2).
"Techniques for checkpoint 2.3"

====

Suggestion 2: Fix checkpoint 1.5.

There are several problems with checkpoint 1.5.

1. Current checkpoint 1.5 incorrectly deals with at least three distinct 
issues and it is not certain whether all issues should be handled in the 
same checkpoint. One issues regards the need for a text equivalent. Another 
issue deals with the requirement for the text equivalent being available 
through an API. The third issue deals with how the text equivalent is 
rendered (the note refers to a status bar, but does that assume a visual 
rendering?).
2. The checkpoint uses the term "non-text message", which is an undefined 
term and I think that it needs to be eliminated or defined. One problem with 
the current phrasing is that it seems to imply that prompts, alerts, and 
notifications are necessarily non-textual in nature. If we do use the term, 
we should define it.
3. There is not a clear connection between the note in checkpoint 1.5 and 
checkpoint 5.4. The note for checkpoint 1.5 refers to checkpoint 5.4  saying 
that "Per checkpoint 5.4, a text equivalent for a non-text message must be 
available through an API. Refer also to checkpoint 5.5." Does "read and 
write access to user agent interface controls" definitely mean that a text 
equivalent intended for user will be available through a standard API? If 
so, then revision "New 2" is OK, but some clarification should probably be 
added.
4. The note in checkpoint 1.5 has a couple of problems ("Note: For example, 
if the user is alerted of an event by an audio cue, a text equivalent in the 
status bar would satisfy this checkpoint."). It seems to make an unstated 
assumption that this is a multimedia user agent and that it can render 
information via both audio and visual display. I think that the checkpoint 
should be more general that the note should go somewhere else, perhaps in a 
technique.

For reference, here is checkpoint 5.4 (UAAG 29 September 2000):

"5.4 Provide programmatic read and write access to user agent user interface 
controls using standard APIs (e.g., platform-independent APIs such as the 
W3C DOM, standard APIs for the operating system, and conventions for 
programming languages, plug-ins, virtual machine environments, etc.) 
[Priority 1]
Note: For example, provide access to information about the user agent's 
current input configuration so that assistive technologies can trigger 
functionalities through keyboard events, mouse events, etc.
Techniques for checkpoint 5.4

Old (29 September 2000):

"1.5 Ensure every non-text message (e.g., prompt, alert, notification, etc.) 
that is part of the user agent's user interface also has a text equivalent. 
[Priority 1]"
"Note: For example, if the user is alerted of an event by an audio cue, a 
text equivalent in the status bar would satisfy this checkpoint. Per 
checkpoint 5.4, a text equivalent for a non-text message must be available 
through an API. Refer also to checkpoint 5.5."
"Techniques for checkpoint 1.5"

New 1 (checkpoint 1.5.A.):

"1.5.A. Ensure that every message (e.g., prompt, alert, notification, etc.) 
that is a non-text element and is part of the user agent's user interface 
has a text equivalent that is available through an API. [Priority 1]"
"Techniques for checkpoint 1.5"

OR

New 2 (checkpoint 1.5.A.):

"1.5.A. Ensure that every message (e.g., prompt, alert, notification, etc.) 
that is a non-text element and is part of the user agent's user interface 
has a text equivalent. [Priority 1]"
"Note: Per checkpoint 5.4, a text equivalent for each such message must be 
available through a standard API. Refer also to checkpoint 5.5."
"Techniques for checkpoint 1.5"

Comment 1:

The second option assumes that checkpoint 5.4 does indeed imply that such 
text equivalents must be available through an API, or more specifically, a 
"standard API".

Comment 2:

I think that if we use the term "non-text message" then we should put it in 
the glossary.

Comment 3:

As noted earlier if we want such messages displayed in a certain way, such 
as via a status bar (when there is a visual status bar), then that should be 
in a separate checkpoint. Otherwise, the more general checkpoint 2.3 about 
the rendering of rendering of equivalents and equivalency targets would kick 
in.

========

Suggestion 3: Define the documents basic policy and assumptions with regard 
to repair functions such as in checkpoints 2.5, 3.2, and 8.4.

a. Define which repair functions are within the scope of the document and 
which ones are outside. I think that a recent telecon that we decided that 
we would not specify which repair functions that user agents could or should 
do at load-time but that we would only be concerned with repairs made after 
that point.  This raises a basic question, "Are all the repair-related 
functions of UAAG intended as post-loading functions?" Whatever our position 
is, I think that is good to that state in the document (perhaps as an 
Assumption).

Such questions come in relation to checkpoint 2.5:

"2.5 For non-text content that has no recognized text equivalent, allow 
configuration to generate repair text. If the non-text content is included 
by URI reference, base the repair text on the URI reference and content type 
of the Web resource. Otherwise, base the repair text on the name of the 
element that includes the non-text content. [Priority 2]"
"Note: Some markup languages (such as HTML 4 [HTML4] and SMIL 1.0 [SMIL] 
require the author to provide text equivalents for some content. When they 
don't, the user agent is required to repair the invalid content by 
generating a text equivalent. Refer also to checkpoint 2.6."

Question arises regarding the note regarding HTML 4.0 and SMIL. For example, 
even though the specs may refer to them as generated text equivalents, are 
they not simple repair text strings and if so, should we not refer to them 
as such rather? Also, what should be our policy regarding whether such 
repairs should take place during load or after load?

Unless I receive further information on this subject, my own preference for 
this kind of repair is that it be done as late as possible so that one is 
able to preserve as long as possible the understanding that the text that 
appears within a container normally reserved for a text equivalent is 
perhaps at best a mere fragment of a text equivalent and does not 
necessarily reflect the intent of the content author. I may be wrong, but it 
seems that my approach would allow an assistive technology to know (and 
thereby inform the user, if necessary) that certain content was not 
author-specified.

So, in the case of checkpoint 2.5, does the configuration capability pertain 
to during-load repairs, post-load repairs, or both?

b. Make sure that we are consistent and explicit in our requirements for 
modifying the DOM.

Based on a recent telecon, I presume that during-load repairs are to be 
simply reflected in the DOM.

I also presume that if writing to the DOM is not mentioned in a checkpoint, 
there is no requirement to place the repair text in the DOM. This, I assume, 
is the case in checkpoint 2.5.

My own preference is that the repair text required in checkpoint 2.5 _not_ 
be written to the DOM, but rather that the repair text be treated as an 
ephemeral part of the rendering process itself (rather than as a change to 
DOM content). I could be persuaded otherwise perhaps.

c. Make sure that we are consistent and explicit in our requirements for 
making data available through other standard APIs.

It is not entirely clear to me if the requirement in checkpoint 2.5 to 
generate repair text necessarily means that the text will be available 
through a standard API. If the text is not written to the DOM and is part of 
the rendering process, then is their any checkpoint that ensures that it 
will be available through an API? I suppose that it has to be available (or 
does it?). If it is required, I am not positive about which checkpoint 
requires it. Does checkpoint 5.4 make that requirement for such repair text?

It seems to me that if such repair text must be available via a standard 
API, there should be a note to that effect.

The bottom line is that I think that the document needs to make clearer what 
our position is on the questions that I have raised.

Here are my guesses for answers to some key questions regarding 'repair 
text' in checkpoint 2.5:

a. Generated during-load or post-load? Post-load (????)
b. Info written to DOM? Not required.
c. Info available through other standard API? Not required (??)

====

I think that basically the same questions posed regarding checkpoints 3.2, 
8.4, and 2.7, which are shown below.

Checkpoint 3.2: "placeholder" and "substitute placeholder":

"3.2 Allow the user to configure the user agent not to render audio, video, 
or animated images except on explicit request from the user. In this 
configuration, provide an option to render a substitute placeholder in 
context for each unrendered source of audio, video, or animated image. When 
placeholders are rendered, allow the user to activate each placeholder 
individually and replace it with the original author-supplied content. 
[Priority 1]"
"Note: This checkpoint requires configuration for content rendered without 
any user interaction (including content rendered on load or as the result of 
a script) as well as content rendered as the result of user interaction that 
is not an explicit request (e.g., when the user activates a link). 
Activation of a placeholder is considered an explicit user request to render 
the original content. When configured not to render content except on 
explicit user request, user agents may render the content "invisibly" or 
"silently" (i.e., in a manner that doesn't appear through the viewport). 
They may choose not to retrieve the audio, video, or animated image from the 
Web until requested by the user. Refer also checkpoint 4.6, checkpoint 4.10 
and checkpoint 4.11."
"Techniques for checkpoint 3.2"

Here are my guesses for answers to some key questions regarding 
'placeholders' in checkpoint 3.2:

a. Generated during-load or post-load? Post-load
b. Info written to DOM? Not required.
c. Info available through other standard API? Not required(??)

====

Checkpoint 8.4: "brief text label"

"8.4 Make available to the user an "outline" view of content, composed of 
labels for important structural elements (e.g., heading text, table titles, 
form titles, etc.). The set of important structural elements is the same 
required by checkpoint 7.6. [Priority 2]"
"Note: This checkpoint is meant to allow the user to simplify the view of 
content by hiding some content selectively. For example, for each frame in a 
frameset, provide a table of contents composed of headings (e.g., the H1 - 
H6 elements in HTML) where each entry in the table of contents links to the 
heading in the document. This checkpoint does not require that the outline 
view be navigable, but this is recommended; refer to checkpoint 7.6. For 
those elements that do not have associated text titles or labels, the user 
agent should use generate a brief text label (e.g., from content, the 
element type, etc.). Refer also to checkpoint 7.7."

Here are my guesses for answers to some key questions regarding 'brief label 
text' in checkpoint 8.4:

a. Generated during-load or post-load? Post-load
b. Info written to DOM? Not required.
c. Info available through other standard API? Not required (??)

====

Checkpoint 2.7: "text substitute or with a graphical icon that has a text 
equivalent"

"2.7 Allow the user to configure the user agent not to render content marked 
up in a recognized but unsupported natural language. Indicate to the user in 
context that author-supplied content has not been rendered. [Priority 3]"
"Note: For example, indicate that content in a particular language has not 
been rendered with a text substitute or with a graphical icon that has a 
text equivalent."
"Techniques for checkpoint 2.7"

Here are my guesses for answers to some key questions regarding 
'placeholders' in checkpoint 2.7:

a. Generated during-load or post-load? Post-load
b. Info written to DOM? Not required.
c. Info available through other standard API? Not required(??)

I presume that the text equivalent referred to in the checkpoint is a text 
equivalent of the graphic and includes the substitute text.

In conclusion, I think that we need to give clearer guidance regarding our 
basic expectations regarding different facets of handling of repair text.

========

Suggestion 4: Fix checkpoint 2.6 regarding "empty text equivalent[s]".

The current phrasing begs the question, "do not generate [what]"? I will 
suggest other language. I think that the change bring it more into line with 
checkpoint 2.5 by referring to 'repair text'.

Old (29 September 2000):

"2.6 When the author has specified an empty text equivalent for non-text 
content, do not generate one. [Priority 3]"
"Note: There are a number of scenarios where an author might provide an 
empty text equivalent (e.g., alt="") that is required by specification. For 
instance, the non-text content has no other function than pure decoration, 
or an image is part of a "mosaic" of several images and doesn't make sense 
out of context. "Please refer to the Web Content Accessibility Guidelines 
1.0 [WCAG10] for more details. Refer also to checkpoint 2.5."
"Techniques for checkpoint 2.6"

New:

"2.6 When the author has specified an empty text equivalent for non-text 
content, do not generate repair text. [Priority 3]"
"Note: There are a number of scenarios where an author might provide an 
empty text equivalent (e.g., alt="") that is required by specification. For 
instance, the non-text content has no other function than pure decoration, 
or an image is part of a "mosaic" of several images and doesn't make sense 
out of context. "Please refer to the Web Content Accessibility Guidelines 
1.0 [WCAG10] for more details. Refer also to checkpoint 2.5."
"Techniques for checkpoint 2.6"

========

Suggestion 5: Add the terms "support", "implement", and "conform" to the 
glossary.

As I recall from discussions with Ian (excuse me for my poor recollection) 
it goes something like this.

"Support" means to follow a specification for a general class of thing, such 
as a feature or a device type.
"Implement" means to follow a specification, with a greater or lesser degree 
of completeness.
"Conform to" means to follow a specification with completeness.

Perhaps even all the terms could be put in the same entry.

For example, one can support the image content type and implement the PNG 
form

Examples: "Implementation"

"Note: Some of the labels above require implementation of at least one 
format (e.g., for images). This document does not require implementation of 
specific formats, (e.g., PNG [PNG] versus SVG [SVG] for images). However, 
refer to the requirements of checkpoint 6.2."

6.1 Implement the accessibility features of all supported specifications 
(markup languages, style sheet languages, metadata languages, graphics 
formats, etc.). The accessibility features of a specification are those 
identified as such and those that support all of the requirements of the 
"Web Content Accessibility Guidelines 1.0" [WCAG10]. [Priority 1]
Note: This checkpoint includes non-W3C specifications. The Techniques 
document [UAAG10-TECHS] provides information about the accessibility 
features of some specifications, including W3C specifications.
Techniques for checkpoint 6.1

Example: "Conform to"

6.2 Use and conform to W3C Recommendations when they are available and 
appropriate for a task. [Priority 2]
Note: For instance, for markup, implement HTML 4.01 [HTML4], XHTML 1.0 
[XHTML10], or XML 1.0 [XML]. For style sheets, implement CSS ([CSS1], 
[CSS2]). For mathematics, implement MathML [MATHML]. For synchronized 
multimedia, implement SMIL 1.0 [SMIL]. For information about programmatic 
access to HTML and XML content, refer to guideline 5. User agents may 
implement other specifications in addition to those required by this 
checkpoint. For reasons of backward compatibility, user agents should 
continue to implement deprecated features of specifications. The current 
guidelines refer to some deprecated language features that do not 
necessarily promote accessibility but are widely deployed. Information about 
deprecated language features is generally part of the language's 
specification.
Techniques for checkpoint 6.2

Example: "Support"

5.7 For user agents that support Cascading Style Sheets ([CSS1], [CSS2]), 
provide programmatic access to CSS style sheets by conforming to the W3C 
Document Object Model (DOM) Level 2 CSS module and exporting the interfaces 
it defines. [Priority 3]

====

<END OF MEMO>

_________________________________________________________________________
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com.

Share information about yourself, create your own public profile at 
http://profiles.msn.com.

Received on Monday, 9 October 2000 23:25:43 UTC