Re: Minority Opinion: Priority Level of UAAG 5.7

Hello again,

To close this thread: during today's teleconference, I
called Arnaud to find out (I hope definitively) whether style
information is available through other means. He responded yes,
that you can query a node to find out whether it has a style
attribute and then access the value of the attribute as text.
Therefore, the style information is available (though in an
unstructured manner) through the core interfaces. Refer to the
minutes of today's meeting [1] for further discussion.

 - Ian

[1] http://lists.w3.org/Archives/Public/w3c-wai-ua/2000OctDec/0125.html


Ian Jacobs wrote:
> 
> Hello,
> 
> Since I'm not a DOM expert, I asked Arnaud LeHors
> (former Team contact for DOM WG and present DOM WG participant
> and resident DOM guru...) whether the entire DOM Level 2 Style
> Specification (chapters 1 and 2) would be required to provide
> access to style sheets in an HTML or XML document. He answered
> "Yes, with the exception of CSS2 Extended Interface (section 2.3)
> as specified." So:
> 
> 1) It looks like checkpoint 5.7 must be P1 to ensure that
>    ATs have access to style content.
> 
> 2) As far as requiring conformance to section 2.3, the
>    DOM 2 Style Module says: "The interface found within this
>    section are not mandatory." Therefore, if we say "conform
>    to the spec", that should suffice.
> 
> Summary: I propose that we raise the Priority of checkpoint 5.7
> to P1 since without it, ATs will not have access to style
> content through the DOM. I think that otherwise there will
> be a bug in our spec.
> 
>  - Ian
> 
> Ian Jacobs wrote:
> >
> > "Gregory J. Rosmaita" wrote:
> > >
> > > OBJECTION:
> > > The priority level of Checkpoint 5.7 (support for the DOM2 Style Module for
> > > UAs that support CSS) should be raised from Priority 3 to at least Priority
> > > 2, if not to Priority 1.
> > >
> > > RATIONALE:
> > >
> > > 1. Inline style information attached to elements is exposed through the
> > >     style attribute of the DOM2 Style Module.
> >
> > Gregory,
> >
> > Good catch. Here are some comments:
> >
> > 1) For XML applications, style and all other information will be
> >    available through the Core module. This means that assistive
> > technologies
> >    can calculate anything they want given the same document object as
> > the
> >    communicating user agent.
> >
> > 2) For HTML, the "style" attribute is *not* available through the
> >    HTML module. From section 1.5.4 of the DOM Proposed Recommendation
> > [1]:
> >
> >     "Note: The style attribute of an HTML element is accessible through
> >      the ElementCSSInlineStyle interface which is defined in the CSS
> > module
> >      [DOM Level 2 Style Sheets and CSS]."
> >
> >    This means that unless the CSS module (or part of it) is implemented,
> >    ATs will not have access to inline style information (i.e., some part
> > of
> >    content).
> >
> >    [1]
> > http://www.w3.org/TR/2000/PR-DOM-Level-2-HTML-20000927/html.html#ID-011100101
> >
> > 3) The Style Sheets module consists of two parts: an abstract style
> >    sheets part (which gives access to style defined via the
> >   "style" attribute) and a CSS-specific part.
> >
> > So:
> >
> > ========
> > PROPOSED: Split checkpoint 5.7 into two parts.
> > ========
> >
> >  a) For user agents that support style sheets, provide programmatic
> >     access to style sheet information by conforming to the W3C
> >     Document Object Model (DOM) Level 2 Specification, Chapter 1
> >     "Document Object Module Style Sheets" and exporting the
> >     interfaces it defines. [Priority 1]
> >
> >   b) For user agents that implement Cascading Style Sheets ([CSS1],
> >      [CSS2]), provide programmatic access to CSS style sheets by
> >      conforming to the W3C Document Object Model (DOM) Level 2
> >      CSS module, Chapter two "Document Object Module CSS"
> >      and exporting the interfaces it defines. [Priority 3]
> >
> > Note that the priority of the first checkpoint is P1, otherwise
> > ATs will not have access to embedded or linked styles.
> >
> > As to establishing the priority of the second checkpoint,
> > I would argue that any piece of software that implements the
> > APIs provided by that module must be almost, if not entirely,
> > a CSS user agent. The DOM CSS module provides convenience
> > interfaces to structures and values of a CSS style sheet,
> > quick access to the style attribute, the ability to insert
> > and delete rules in a style sheet, and (probably most
> > attractively) access to computed values. I would argue that
> > any AT that implements the API, in order to make use of
> > the computed value, must know enough about CSS (and implement
> > enough of it) that it could probably compute the value
> > itself (given access to the DOM and the style sheets). So
> > the question is, I think: is having access to the computed
> > value a P1 requirement, or more of a convenience? I think that
> > in the past, we have argued (and Gregory has objected) that
> > providing the computed value was not a P1 requirement.
> >
> > One reason is that CSS computed values (as defined in
> > section 6.1.2 of the CSS2 specification [2]) are a step
> > removed from "actual values", which are "computed values
> > after any approximations have been applied." In other
> > words, the user agent may not be able to use a computed
> > value and therefore make modifications to it that will
> > not be reflected through the DOM CSS module. So the goal
> > of providing information to ATs about "what's on the screen"
> > is not entirely met by the CSS DOM.
> >
> > Summarizing why I don't think that CSS DOM support should
> > be a P1 requirement (nor P2, though I feel less strongly
> > about that):
> >
> > 1) Information is available through the Style Sheets module
> >    (bug fixed thanks to Gregory).
> >
> > 2) ATs would probably have to be almost, if not entirely,
> >    CSS agents to make use of the DOM CSS API.
> >
> > 3) The DOM CSS module may not solve the problem completely
> >    anyway.
> >
> >  - Ian
> >
> > [2] http://www.w3.org/TR/REC-CSS2/cascade.html#computed-value
> >
> > >     This is extremely important,
> > >     as inline style attributes are particularly difficult (if not impossible)
> > >     for most users to either anticipate and/or change/tailor/transform into
> > >     something useable by that user by use of a client-side stylesheet. As the
> > >     Proposed Recommendation draft of the DOM2 Style Module states, quote It
> > >     represents the contents of the STYLE attribute for HTML elements (or
> > >     elements in other schemas or DTDs which use the STYLE attribute in the
> > >     same way). The expectation is that an instance of the
> > > ElementCSSInlineStyle
> > >     interface can be obtained by using binding-specific casting methods on an
> > >     instance of the Element interface when the element supports inline CSS
> > >     style informations. unquote
> > >
> > >     I believe that this alone is a most compelling reason for raising the
> > >     priority level of UAAG Checkpoint 5.7 (support for the DOM2 Style Module).
> > >     Moreover, the quote cited above is drawn from Section 2.2.3. (Element with
> > >     CSS inline style), a sub-section of Section 2.2, which is entitled, quote
> > >     CSS Fundamental Interfaces unquote of which, the Proposed Recommendation
> > >     states:
> > >
> > >          quote
> > >          The interfaces within this section are considered fundamental CSS
> > >          interfaces, and must be supported by all conforming implementations
> > >          of the CSS DOM module. These interfaces represent CSS style sheets
> > >          specifically.
> > >          unquote
> > >
> > > 2. Currently the CSS module is the only way that pseudo-elemental information
> > >     can be carried through the DOM, and thereby exposed to the user either
> > >     through the user agent's UI, or via the user's assistive technology.
> > >
> > > 3. While information about nested lists is carried through the DOM, such
> > >     essential orientational information is often unavailable to a user with a
> > >     disability, due to the use of UA-generated symbols to indicate the nesting
> > >     level of a list item. The use of pseudo-elemental text (using the
> > >     ":before" and ":after" syntax outlined in Section 12.1 of the CSS2
> > >     Recommendation) to indicate the nesting level of a list item (as well as
> > >     distinguishing one list item from another) prevents perceptual black
> > >     holes that can drastically affect a disabled user's interaction with a
> > >     document
> > >
> > > 4. Use of stylesheets to generate pseudo-elemental information (such as
> > >     "Begin Spanish text" and "End Spanish text") is not only of incalculable
> > >     assistance to users with physical disabilities, but may also facilitate
> > >     comprehension of a document's content and structure for a user with a
> > >     cognitive disability
> > >
> > > 5. Promotion of the development of more interoperable, as well as more
> > >     accessible and more usable, user agents through the promotion of more
> > >     widespread and robust support for aural and tactile environments (more
> > >     robust support for "@media" rules other than those which have currently
> > >     been implemented, and which are--implicitly or explicitly--visually-
> > >     oriented)
> > >
> > > References:
> > > 1. Document Object Model (DOM) Level 2 Style Specification, 27 September
> > >     2000 (Proposed Recommendation) Draft
> > >     <http://www.w3.org/TR/2000/PR-DOM-Level-2-Style-20000927>
> > >
> > > 2. Cascading Style Sheets, Level 2 Technical Recommendation
> > >     <http://www.w3.org/TR/REC-CSS2/>
> > >
> > > 3. The :before and :after pseudo-elements:
> > >     <http://www.w3.org/TR/CSS2/generate.html#before-after-content>
> > > ------------------------------------------------
> > > The optimist thinks that this is the best of all
> > > possible worlds; the pessimist knows it is.
> > > ------------------------------------------------
> > > Gregory J. Rosmaita     <unagi69@concentric.net>
> > >        Webmaster & Minister of Propaganda
> > > The Visually Impaired Computer Users' Group of
> > > the New York City Metropolitan Area (VICUG NYC)
> > >       <http://www.hicom.net/~oedipus/vicug/>
> > > ------------------------------------------------
> >
> > --
> > 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

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

Received on Thursday, 19 October 2000 15:56:30 UTC