Re: SVG, Style, Resizing, Etc.

At 04:51 AM 2000-10-05 -0400, Ian Jacobs wrote:
>> 
>> 3. The resizing of vector graphics like SVG I do not think are addressed
>> in the guidelines.  I think the group should discuss this. I will add it
>> to the issue list for discussion on 10 October.
>
>IJ: Please help me understand the issue at hand. 
>
>1) For the case of SVG, the requirement in question (the ability to
>   recsize content) is part of conformance (and thus covered by 
>   UAAG 1.0 checkpoint 6.2). Refer to section G.7 [1]:
>
>   "For interactive user environments, facilities must exist for 
>    zooming and panning of standalone SVG documents or
>    SVG document fragments embedded within parent XML documents."
>
>   There are other relevant conformance requirements in that section.
>

AG::

[There's nothing to keep us from clarifying the issue by mail prior to the
telecon.]

This is good.

Do the "other ... conformance requirements" determine what happens about
the boundary in the layout canvas between the SVG content of an embedded
SVG object and the other content of the parent XML document?  Turning a
navigation button into a scroll region because the user asked for it larger
would not exactly be swift.

Al

>2) For other cases, any user agent that implements a scalable data
>format that doesn't allow the user to scale the data is a worthless
>tool. The accessibility of a worthless tool should not be our primary
>concern.
>
>I think that the proposed requirements (below) 
>for vector graphics control are thus unnecessary.
>
> - Ian
>
>[1]
>http://www.w3.org/TR/2000/CR-SVG-20000802/conform.html#ConformingSVGViewers
> 
>> I think the issue that the group would need to discuss is adding a section
>> in guidelines line 4 for graphics:
>> 
>> Three prossible checkpoints:
>> 4.x Allow the user to configure and control the reference size of rendered
>> vector graphics with an option to override author specified reference
>> sizes and default user agent sizes. [Priority 1 or 2]
>> 
>> 4.y Allow the user to configure the foreground color of vector graphics,
>> including the use of gray scale for mapping colors. [Priority 1 or 2]
>> 
>> 4,z Allow the user to configure the background color of vector graghics.
>> [Priority 1 or 2]
>> 
>> Jon
>> 
>> On Wed, 4 Oct 2000, Ian Jacobs wrote:
>> 
>> > 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

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

Received on Thursday, 5 October 2000 08:20:31 UTC