Re: SVG, Style, Resizing, Etc.

Working group,
The SVG document referenced by Ian [1] does talk about scaling (zooming and 
panning) and conforming to UAAG 1.0. If we are only worried about SVG the 
scaling question seems like it is taken care of in the SVG 
specification.  The control over colors, doesn't seem to be taken care of 
in the SVG specification, so there would still be a potential hole for 
accessibility unless 4.3 and 4.4 could be slightly expanded to include 
"stylable graphics" like SVG.

The options for the group would be:
1. Consider adding the proposed checkpoints [2] or expanding the scope of 
4.3 and 4.4 to include "stylable graphics" and assume the scaling would be 
taken care of at least for SVG in the SVG document.   SVG scaling of fonts 
was raised as a PR issue[3], but not the more general issue of other 
graphic content in SVG so we have not havd a specific request from PR to 
address this issue, so process wise we would be considering a new 
requirement.  So for this to happen there would need to be strong support 
from the current working group to do this, otherwise it should be dropped 
as indicated in the next option.

2. Working group feels it doesn't have time to address the issue carefully 
or the issue is not important enough to consider before last call and the 
issue will be dropped.  In this case people in other working groups that 
the document has a dependency or from external reviewers could raise the 
issue during last call as part of their review if they feel strongly about 
it. The group then could respond to their concerns.

I urge people to comment to the list to these proposals, so that we can get 
a sense of what direction the group wants to take before 10 October 
meeting.  Let's try to use the list to help resolve these issues!

Jon

[1] http://www.w3.org/TR/2000/CR-SVG-20000802/conform.html#ConformingSVGViewers
[2] http://lists.w3.org/Archives/Public/w3c-wai-ua/2000OctDec/0006.html
[3] http://server.rehab.uiuc.edu/ua-issues/issues-linear.html#254

At 04:51 AM 10/5/2000 -0400, Ian Jacobs wrote:
>Hi Jon,
>
>My comments preceded by IJ: below.
>
>jon gunderson wrote:
> >
> > 1. I think that it is not worth pursuing navigation checkpoints based on
> > only style now that important elemets in 7.6 are informative.  If
> > developers want to use style they can do it to identify important
> > elements.
> >
> > 2. SVG text issue has been raised before and the response was that 4.1 and
> > 4.2 covers resizing and font face for scalable vector graphics.
> >
> > 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.
>
>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

Jon Gunderson, Ph.D., ATP
Coordinator of Assistive Communication and Information Technology
Division of Rehabilitation - Education Services
MC-574
College of Applied Life Studies
University of Illinois at Urbana/Champaign
1207 S. Oak Street, Champaign, IL  61820

Voice: (217) 244-5870
Fax: (217) 333-0248

E-mail: jongund@uiuc.edu

WWW: http://www.staff.uiuc.edu/~jongund
WWW: http://www.w3.org/wai/ua

Received on Thursday, 5 October 2000 12:11:53 UTC