Re: Repair Text, Definitions, Etc.

Hello,

Ian's comments preceded by IJ:

 - Ian

>Jon Gunderson wrote:
> 
> >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"
> 
> JRG: Basically you just want to add the second note.  I didn't see any
> other changes in 2.3.  I don't think we need the second note, we could use
> the second note for almost every checkpoint.

IJ: I agree with Jon. I think we might move to the techniques or just
drop it.
 
> >====
> >
> >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
> 
> JRG: This option is unacceptable to me, we what the text as part of the
> interface for people who may not be able to see images or hear sounds.  An
> API is insufficient.
> 
> >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"
> 
> JRG: This is more acceptable to me and seems to make it clearer the text
> needs to be part of the user interface and not just an API.

IJ: I propose a minor reordering but am ok with the terminology:

   1.5.A. Ensure that every message in the user agent user interface
         (e.g., prompt, alert, notification, etc.) 
         that is a non-text element has a text equivalent. [Priority 1]"
 
> >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.
> 
> JRG: I don't beleive 3.2 and 8.4 are considered repair checkpoints.  3.2 is
> about user choices of what content they want rendered and 8.4 is about
> creating an outline view of the document.  These are not repair functions
> in my mind.  I beleive the only repair checkpoint is 2.5.

IJ: You can consider 2.7 repair as well (due to lack of resources for
displaying content in a particular natural language).
 
> >a. Define which repair functions are within the scope of the document and
> >which ones are outside. 

IJ: I'm ok with saying the following in the document:

 a) This document assumes WCAG conformant content
 b) This document deals mostly with scenarios that are not error
scenarios
 c) This document includes a couple of repair requirements, but in
general
    leaves that work to the Evaluation and Repair Working Group. (I
think
    that this document should promote conformance to specs).

I don't think we should talk about what repair techniques we don't cover
since (a) that's a very large realm and (b) we don't do a lot of stuff,
so why focus on the repair techniques that we don't do?

> 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?

IJ: Now I see where you're going with this. I would prefer to say as
little
as possible.

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

IJ: I agree. Since nothing is stated about this, there is no requirement
to
place the repair text in the DOM. I propose pushing any discussion of
how the document object gets constructed to its definition (currently
the
case). 

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

IJ: I think that's my preference also, but when we discussed it, there
was
no consensus. I don't know whether that's my definitive preference,
either.
This is currently discussed in the techniques document, and I'm not sure
we should say much more.

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

IJ: You are right, there is no guarantee. But the resolution of the 
21 September teleconf [1] was not to add any explciit requirements
for this.

[1] http://lists.w3.org/Archives/Public/w3c-wai-ua/2000JulSep/0415.html

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

IJ: Yes.

> >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 (??)
> 
> JRG:
> 
> 1. Point a is an implementation detail for the developer to decide.  From
> an accessibility stand point what difference does it make if it is done
> during load or a post load?
> 
> 2. Point b: We already discussed this and the group found advantages and
> disadvantages to this approach.  Ian took an action item to add the
> discussion to the techniques document.  The group is not going to take any
> stand at this time.

IJ: Yes. I would be ok to add some text to the definition of "document
object"
that repair content may not appear in the document object, and thus will
not
be available to ATs. And a link to the techniques discussion.
 
> 3. Author supplied content is required to be made available through the
> DOM.  In this case there is no content available from the author.  Repair
> information from the user agent needs to be made available through APIs
> and/or the DOM if the developer sees it to their advantage for accessibility.

IJ: Yes.

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

IJ: Right.

> >c. Info available through other standard API? Not required(??)

IJ: Right.

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


IJ: No, I think that this one requires writing to the DOM. I think that
the outline view needs to be available to ATs.

> >c. Info available through other standard API? Not required (??)

IJ: 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.

IJ: I agree.

> >c. Info available through other standard API? Not required(??)
> 
> JRG:
> Point a: From a accessibility point of view what difference does it make to
> the user with a disability?
> Point b: Again see previous comments, but in this case I would say no,
> since an AT may support the language and should have access to the authors
> content.
> Point c: Yes anythig rendered to the user must be available through an API.
> 
> >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"
> 
> JRG: This is not a repair checkpoint.  This was part of a WCAG requirement
> for image maps and other collections of images that result in a composite
> image.  The author intentionally using a null or "" equivalent to indicate
> that an image is part of a larger image.  One of the images in the set of
> images has equivalents describing the composite image.

IJ: I agree with Eric's wording since he is saying "do not (erroneously)
generate
repair text in place of what the author has explicitly stated".

 - Ian
 
> >========
> >
> >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.

IJ: I would change to "Support means to be programmed (to recognize)
general
classes of objects or devices (e.g., images, the keyboard, French)."
There
is not necessarily a specification.

> >"Implement" means to follow a specification, with a greater or lesser
> >degree of completeness.

IJ: Yes.

> >"Conform to" means to follow a specification with completeness.

IJ: I would say instead: "Conform to means to satisfy the conformance
requirements of a specification." I prefer this because it's not
up to the developer to determine how much lesser or greater the
implementation may be. 

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

IJ: Yes.

> >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]
> >
> >====

Thanks Eric,

 - Ian

-- 
Ian Jacobs (jacobs@w3.org)   http://www.w3.org/People/Jacobs
Tel:                         +1 831 457-2842
Cell:                        +1 917 450-8783

Received on Tuesday, 10 October 2000 11:33:23 UTC