SVG, Style, Resizing, Etc.

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.

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?

b. If an SVG graphic is a non-text element, does SVG support than one
fragment for the text equivalent?

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?

====

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. 

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

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

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

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.

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

Received on Tuesday, 3 October 2000 17:05:28 UTC