Re: SVG, Style, Resizing, Etc.

Hello,

My comments preceded by "IJ:"

"Hansen, Eric" wrote:
> 
> This memo tries to address the:
> 
> 1. the resizing problem cited by Al Gilman
> 2. the style issues raised by Jon Gunderson
> 3. the need for refinements to the definition of "Non-text content..."
> 
> plus several other issues.

Eric, thanks for synthesizing!

> Background
> 
> I have been thinking about three interrelated issues that have appeared on
> the UA list recently. I am trying to think of how they are connected. I
> think that this document makes
> 
> 1. Al Gilman's suggestion for object resizing capabilities.
> 
> [1] http://lists.w3.org/Archives/Public/w3c-wai-ua/2000JulSep/0497.html
> 
> 2. Charles McCathieNevile's response to Len Kasday's memo regarding "Are
> Small Text buttons level 2 compliant".
> 
> [2] http://lists.w3.org/Archives/Public/w3c-wai-ua/2000JulSep/0430.html
> 
> 3. Jon Gunderson's 20 September suggestion "Proposed revision of checkpoint
> 7.6". The proposal included two Priority 3 checkpoints -- one to address
> navigation via style information (particularly as it might indicate the
> document structure intended by the author) and one to control and
> configuration capabilities governing "options for class, font size, font
> color, font face, font style (basically CSS font properties)[Priority 3]"
> 
> [3] http://lists.w3.org/Archives/Public/w3c-wai-ua/2000JulSep/0405.html
> 
> I am wondering if we can make progress toward solutions with a few small
> changes. Some progress might be provided by what is written below.
> 
> Suggestion 1: Clarify the relationship of the SVG standard to the concepts
> of text content and non-text content.
> 
> In Al Gilman's messages regarding Scalable Vector Graphics (SVG) ("user
> resize SVG objects?"), he pointed out that we are lacking requirements for
> the scaling of various objects.
> 
> I have a few questions about SVG:
> 
> a. Is it possible for an SVG to be considered a text element or are they
> always non-text elements?

IJ: I think the answer depends on how well the content is authored. You
can
create non-text elements in SVG or you can provide nested text
equivalents or
more.
 
 b. If an SVG graphic is a non-text element, does SVG support than one
> fragment for the text equivalent?

IJ: Yes.
 
> c. Would SVT graphics ever be affected by having a general P1 requirement to
> be able to resize text content?
> 
> d. Are any SVG graphics affected by UAAG checkpoints 4.1 and 4.2?

IJ: Yes. 

> ====
> 
> Suggestion 2: Include a Priority 1 requirement for resizing text content.
> 
> "Checkpoint X. Allow the user to configure and control the resizing of
> recognized text elements and make the information available through API
> [Priority 1]"
> "This includes SVG graphics that are recognized as text elements." [Is there
> such thing as an SVG graphic that is a text element?]
> 
> Comment 1:
> 
> This checkpoint covers text elements, including text equivalents, regardless
> of origin.
> 
> Comment 2:
> 
> For HTML and related specifications, this should presumably be fulfilled by
> UAAG checkpoints 4.1 (and 4.2), provided below"
> "4.1 Allow the user to configure and control the reference size of rendered
> text with an option to override author-specified and user agent default
> sizes of rendered text. Make available the range of system font sizes.
> [Priority 1]"
> "Note: The reference size of rendered text corresponds to the default value
> of the CSS2 'font-size' property, which is 'medium' (refer to CSS2 [CSS2],
> section 15.2.4). The default reference size of rendered text may vary among
> user agents. User agents may offer different mechanisms to allow the user to
> control the size of rendered text, for example by allowing the user to
> change the font size or by allowing the user to zoom or magnify content."
> 
> Comment 3:
> 
> This checkpoint obviously assumes that an SVG graphic may be a text element.
> As noted at the head of this memo, I am not sure that this is the case.
> 
> Comment 4:
> 
> I am less sure of the value of this suggested checkpoint than I am about the
> next one.
> 
> ====
> 
> Suggestion 3: Include a Priority 2 requirement for resizing non-text content
> that is presented visually.
> 
> "Checkpoint X. Allow the user to configure and control the resizing the
> visual presentation of recognized non-text elements and make the information
> available through API  [Priority 2]"
> "This includes SVG graphics that are recognized as non-text elements."
> 
> Comment 1:
> 
> This checkpoint covers non-text elements, including text equivalents,
> regardless of origin. This would cover images, movie screens, etc.
> 
> Comment 2:
> 
> This checkpoint seems to fill a gap in the current guidelines.

IJ: I recognize the value in adding a generic "magnification"
requirement. 
By adding this requirement to the spec, we move a functionality we
assumed (up to
now) was covered by screen magnifiers or by a spec itself (such as SVG).
This relates to your comment 5.

I think I would object to adding this checkpoint at this time.
 
> Comment 3:
> 
> The idea behind the lower priority (Priority 2) is that the message in
> non-text elements is also available via text equivalent (provided the
> content in WCAG 1.0 single-A conformant); therefore it ought not be a
> Priority 1 checkpoint. I can think of rationales for Priority 1 level or
> Priority 3 level but I think that I belongs at Priority 2.
> 
> Comment 4:
> 
> We probably need to provide a minimum requirement too.
> 
> Comment 5:
> 
> This functionality could be filled by an assistive technology, but this will
> bring the capability clearly _within the subject of the claim_.
 
> =====
> 
> Suggestion 4: When referring to content in the DOM, use the term "DOM
> content" rather than just "content".

IJ: I'm not sure, but I think this is editorial.

Pros:

 - Will help people understand that we mean "bits" and not "information"

Cons:

 - Longer.
 
> This will help disambiguate various uses of the term "content".
> 
> Old (29 September 2000):
> "2.1 Make all content available through the user interface. [Priority 1]"
> "Note: Users must have access to the entire document object through the user
> interface, including recognized equivalents, attributes, style sheets, etc.
> This checkpoint does not require that all content be available in every
> viewport. A document source view is an important part of a solution for
> providing access to content, but is not a sufficient solution on its own for
> all content. Refer to guideline 5 for more information about programmatic
> access to content."
> 
> New:
> "2.1 Make all DOM content available through the user interface. [Priority
> 1]"
> "Note: Users must have access to the all DOM content through the user
> interface, including recognized equivalents, attributes, style sheets, etc.
> This checkpoint does not require that all DOM content be available in every
> viewport. A document source view is an important part of a solution for
> providing access to content, but is not a sufficient solution on its own for
> all content. Refer to guideline 5 for more information about programmatic
> access to content."
> 
> ====
> 
> Suggestion 5: Fix the definition of equivalent.
> 
> The current definition has few minor problems. I have attempted to fix them
> below.
> 
> Old (UAAG 29 September 2000):
> 
> "Non-text content, text content, non-text element, text element, text
> equivalent
> 
> "In this document, the term "non-text content" refers to content that is
> composed of one or more non-text elements. Per checkpoint 1.1 of "Web
> Content Accessibility Guidelines 1.0 [WCAG10], authors must ensure that
> there is a "text equivalent" for each author-supplied non-text element.
> Similarly, user agent developers must ensure that a text equivalent is
> available for any non-text element produced by the user agent for the user
> (refer to checkpoint 1.5). In this document, the term "text content" refers
> to content that is composed of one or more text elements."
> 
> "A "text element" is content that, when rendered, is understandable in each
> of the three modes:"
> 
> 1. visually-displayed text (e.g., for a user who is deaf and adept in
> reading visually-displayed text);
> 2. synthesized speech (e.g., for a user who is blind and adept in use of
> synthesized speech);
> 3. braille (e.g., for a user who is deaf-blind and adept at reading
> braille)."
> 
> "A text element may contain markup for structure (e.g., heading levels), and
> style (e.g., font size or color), and so on. However, the essential function
> of the text element should be retained even if style information happens to
> be lost in rendering. A "non-text element" is an element that fails to be
> understandable when rendered in any of three modes to their respective
> disability audiences. Note: In these definitions, the term "understandable"
> means understandable by representatives of the reference disability groups
> (deaf, blind, deaf-blind) who are operating under reasonable conditions
> (i.e., they have the appropriate available hardware and software), who able
> to understand the natural language of the content, who are not experts in
> computer science, etc."
> 
> "A "text equivalent" is a text element that, when rendered, serves
> essentially the same function as some other content (i.e., an equivalency
> target) does for a person without any disability (see definition of
> equivalents)."
> 
> "Note that the terms "text element" and "non-text element" are defined by
> the characteristics of their output (rendering) rather than those of their
> input. For example, in principle, a text equivalent can be generated or
> encoded in any fashion as long as it has the proper output characteristics.
> In general, text elements are composed of text (i.e., a sequence of
> characters). A text equivalent may be understood as "pre-rendering" content
> in contrast to the "post-rendering" content that it produces
> (visually-displayed text, synthesized speech, braille)."
> 
> New:
> 
> The major changes are within double pairs of angle brackets and asterisks,
> <<**changed text**>>.
> 
> "Non-text content, text content, non-text element, text element, text
> equivalent"
> 
> "In this document, the term "non-text content" refers to content that is
> composed of one or more non-text elements. Per checkpoint 1.1 of "Web
> Content Accessibility Guidelines 1.0 [WCAG10], authors must ensure that
> there is a "text equivalent" for each author-supplied non-text element.
> Similarly, user agent developers must ensure that a text equivalent is
> available for any non-text element produced by the user agent for the user
> (refer to checkpoint 1.5). In this document, the term "text content" refers
> to content that is composed of one or more text elements."
> 
> <<**A "text element" **REVISED: "has output (consisting of text
> characters)"** "that, when rendered, makes its message understandable in
> each of the three modes **>><<**ADDED : "to its respective reference
> disability group"**>>[NOTE BY E HANSEN: I inserted the word "message" to
> make clear that all three modes need to convey essentially the same message.
> Also, the reference disability groups are specific. The distinction between
> "output" and "rendering" is deliberate; it leaves open the door to
> additional transformations during the rendering process.]:
> 
> 1. visually-displayed text (<<**DELETED E.G., SINCE IT IS I.E.)**>>for a
> user who is deaf and adept in reading visually-displayed text);
> 2. synthesized speech (<<**DELETED E.G., SINCE IT IS I.E.)**>>for a user who
> is blind and adept in use of synthesized speech);
> 3. braille (<<**DELETED E.G., SINCE IT IS I.E.)**>>for a user who is
> deaf-blind and adept at reading braille)."
> 
> <<**NEW:>>"Thus, a text element may be understood as "pre-rendering" content
> in contrast to the "post-rendering" content that it produces
> (visually-displayed text, synthesized speech, braille)."
> 
> "A text element may contain markup for structure (e.g., heading levels), and
> style (e.g., font size or color), and so on. However, the essential function
> of the text element should be retained even if style information happens to
> be lost in rendering. <<**NEW"A rendered text element should not contain
> excessive amounts of irrelevant information or clutter."**>> 

IJ: I don't like the last added sentence.

> A "non-text
> element" is an element that fails to be understandable when rendered in any
> of three modes to their respective disability audiences. Note: In these
> definitions, the term "understandable" means understandable by
> representatives of the reference disability groups (deaf, blind, deaf-blind)
> who are operating under reasonable conditions (i.e., they have the
> appropriate available hardware and software) and who <<**are able to
> understand the natural language of the content. These individuals are not
> expected to understand computer science (e.g., markup languages) unless, of
> course, the topic of the text is computer science."**>>

IJ: I don't think that that the last phrase is necessary.
 
> "Note that a text element is defined by the characteristics of its output
> (rendering) rather than by its input. <<**REVISED: "For example, a text
> element can be produced or encoded in any fashion as long as it has the
> proper output characteristics."**>>  <<**NEW (to emphasize how they are
> typically implemented: "Generally, the easiest way to implement a text
> element is to encode it as simple natural language text, with or without
> markup. Of course, like all author-specified Web content, text elements are
> subject to the Web Content Accessibility Guidelines (WCAG) 1.0 at the
> targeted conformance level."
> 
> "A "text equivalent" is a text element that, when rendered, serves
> essentially the same function as some other <<**element**>> (i.e., an
> equivalency target) does for a person without any disability (see definition
> of equivalents)." [NOTE BY E. HANSEN: I changed the word "content" to
> "element". I think that this makes sense, as long as we agree that an
> element can contain other elements. I puzzle over this use of "element"
> versus the overused word "content". Both element and content seem doomed to
> overuse.]

IJ: I think I'm ok with the proposed changes.
 
> Comment 1:
> 
> I switched order of last paragraphs to put related material together.
> 
 ====
> 
> Suggestion 6: Add style related checkpoints along the line Jon suggested.
> 
> When Jon mentioned during the last telecon that he had made this proposal
> regarding style I had trouble recalling this proposal. However, after
> looking at it again I did recall thinking that they were very good
> suggestions.
> 
> I strongly agree with Jon's concern for using style information for clues
> about author-intended structure. See [3].
> 
> Furthermore, I think that until (and unless) W3C specifically forbids the
> use of style for conveying _important_ information, the UAAG document needs
> to have one or more checkpoints that will facilitate extraction of important
> meaning from style information. I know of no specification that forbids the
> use of style for conveying important information.

IJ: I would object (strongly) to the addition of requirements to allow
navigation
according to style. I think that this is ok to tell developers in the 
Techniques document (but not great to tell them). 

Style may be used to convey important information (in fact, I expect it
to
be used as much as natural language alone to convey important
information).
However, style should not be the ONLY way in which that information is
identified. Style sheets are meant to allow authors to tailor the
rendering
of important information to a particular output mode. 

By requiring such a capability of browsers, we will only encourage
authors to put semantics in style first, rather than in device-
or output-independent markup and then styling that markup. 
I think that it's important to:

 - Encourage proper authoring practices. Refer to Guideline 3 of WCAG
(the
   prose) as well as checkpoint 2.1 for example for requirements to not
rely
   on style alone to convey information.
 - Discourage bad authoring practices (and encoding semantics in style
alone
   is a bad authoring practice, refer also to ATAG 1.0 checkpoint 4.5).
 - Promote the proper implementation of specifications rather than the
   implementation of features that support bad authoring. Developers
have limited
   resources - let's help them use their resources to create conforming
   user agents.

I would object to a "repair checkpoint" that requires navigation
capabilities according to style patterns.
 
> Jon's suggestions:
> 
> [NEW 2]
> 7.b Allow the user to easily navigate implicitly defined important
> structural elements identified by the author. Authors may use rendering
> style to implicitly indicate the important structural elements of a
> document.  Allow forward and backward sequential navigation to elements with
> same style as the current element.  [Priority 3]
> 
> Note: Could be considered a repair checkpoint for poor authoring practices
> [/NEW 2]
> 
> [NEW 3]
> 7.c Allow the user to configure and control the set of run time attributes
> used to determine the same style for navigation in checkpoint 7.b . Include
> options for class, font size, font color, font face, font style (basically
> CSS font properties)[Priority 3]
> 
> Note: This checkpoint is an important feature of checkpoint 7.b and is
> similar to the current 7.7
> [/NEW 3]
> 
> Old (29 September 2000):
> 
> "7.6 Allow the user to navigate efficiently to and among important
> structural elements identified by the author. Allow forward and backward
> sequential navigation to important structural elements. [Priority 2]
> 
> "Note: This specification intentionally does not identify the set of
> "important elements" that must be navigable; refer to the Techniques
> document [UAAG10-TECHS] for information about identifying important
> elements. Structured navigation of headings, tables, forms, lists, etc., is
> most effective in conjunction with a configurable view. (refer to
> configuration requirements of checkpoint 8.4 and checkpoint 7.7). User
> agents should follow operating system conventions for indicating navigation
> progress (e.g., selection or content focus)."
> 
> "Techniques for checkpoint 7.6"
> 
> 7.7 Allow the user to configure and control the set of important elements
> required by checkpoint 7.6 and checkpoint 8.4. Allow the user to include and
> exclude element types in the set of elements. [Priority 3]
> Note: For example, allow the user to navigate only paragraphs, or only
> headings and paragraphs, etc. Refer also to checkpoint 5.4..
> Techniques for checkpoint 7.7
> 
> New:
> 
> Allow forward and backward sequential navigation to elements with same style
> as the current element.
> 
> "7.8 Allow the user to navigate efficiently to and among important style
> elements identified by the author. Allow forward and backward sequential
> navigation to important style elements. [Priority 3]
> 
> "Note 1: This specification is intended largely as a 'repair' functionality.
> The WAI/W3C strongly discourages the use of style information to convey
> document structure or to convey substantive content. The functionality in
> this checkpoint is expected to be most helpful in dealing with content that
> does not conform well the WCAG 1.0."
> 
> "Note 2: This specification intentionally does not identify the set of
> "important elements" that must be navigable; refer to the Techniques
> document [UAAG10-TECHS] for information about identifying important
> elements. [ETC.] User agents should follow operating system conventions for
> indicating navigation progress (e.g., selection or content focus)."
> 
> "Technique for checkpoint 7.8: Allow forward and backward sequential
> navigation to elements with same style as the current element."
> 
> "7.9 Allow the user to configure and control the set of important elements
> required by checkpoint 7.8. Allow the user to include and exclude element
> types in the set of elements. [Priority 3]
> Note: For example, allow the user to navigate only [ETC.]
> 
> <END OF MEMO>
> =
> ===========================
> Eric G. Hansen, Ph.D.
> Development Scientist
> Educational Testing Service
> ETS 12-R
> Princeton, NJ 08541
> 609-734-5615 (Voice)
> E-mail: ehansen@ets.org
> (W) 609-734-5615 (Voice)
> FAX 609-734-1090

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

Received on Wednesday, 4 October 2000 10:19:49 UTC