W3C home > Mailing lists > Public > w3c-wai-ua@w3.org > October to December 2000

RE: SVG, Style, Resizing, Etc.

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
Message-id: <B49B36B1086DD41187DC000077893CFB8B43F1@rosnt46.ets.org>
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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 27 October 2009 06:50:22 GMT