- From: Hansen, Eric <ehansen@ets.org>
- Date: Thu, 05 Oct 2000 12:48:10 -0400
- To: "'Jon Gunderson'" <jongund@ux1.cso.uiuc.edu>, "UA List (E-mail)" <w3c-wai-ua@w3.org>
- Cc: "Hansen, Eric" <ehansen@ets.org>, ij@w3.org, asgilman@iamdigex.net
My comments below labeled with "EH:".
> -----Original Message-----
> From: Jon Gunderson [mailto:jongund@ux1.cso.uiuc.edu]
> Sent: Thursday, October 05, 2000 12:12 PM
> To: UA List (E-mail)
> Cc: Hansen, Eric; ij@w3.org; asgilman@iamdigex.net
> Subject: 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.
EH: I am not sure that I understand SVG well enough to have really strong
opinions, but following are a few thoughts. I have already stated my liking
for a requirement for scaling of graphics (not necessarily Priority 1).
(""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."")[1].
Expanding the scope of 4.3 and 4.4 to include scalable graphics seems
reasonable, although I think the Priority 1 rating is most warranted in
those cases in which the scalable graphics constitute text elements
(remember I mean understandable when rendered in each of the three modes!).
The expansion does seem warranted and the SVG seems to make such a
requirement quite feasible to implement. Nevertheless, I do emphasize with
the ideas that we want to avoid rash changes at a point when we are trying
to stabilize the document. Are there experts with whom we could confer in
evaluating the potential problems with such expansions?
[1] http://lists.w3.org/Archives/Public/w3c-wai-ua/2000OctDec/0004.html
>
> 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#Conform
> ingSVGViewers
> [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#Confor
> mingSVGViewers
> >
> > > 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:48:18 UTC