W3C home > Mailing lists > Public > w3c-wai-ua@w3.org > July to September 2006

6.9 DOM access to CSS style sheets and 6.6 Programmatic notifcation of changes

From: Catherine Laws <claws@us.ibm.com>
Date: Wed, 6 Sep 2006 17:34:56 -0500
To: WAU-ua <w3c-wai-ua@w3.org>
Message-ID: <OF6C7B64C2.F91BA988-ON862571E1.0079B13A-862571E1.007C0C44@us.ibm.com>

Here is a conversation related to 6.9 DOM access to CSS style sheets and
6.6 Programmatic notification of changes:

Cathy Laws (CL): Does content in a style sheet to be rendered by the
browser, like text, an image, or a control, show up as content in the IE or
Firefox DOM just as if it were HTML content?  Also, are there programmatic
notification of changes (events) when content specified in style sheets
change? UAAG 6.6 techniques seem to require that UAs must provide
programmatic notification of changes only when the DOM changes.

Aaron Leventhal (AL): It's not in the DOM. The style sheet doesn't affect
the DOM, just the layout.

It takes a lot of work to expose text from :before and :after, or list
bullets. We (Firefox) expose it in the MSAA hierarchy but it's <not easy>.
No, it's not in the DOM, so Fire Vox (a Firefox extension) won't see it
unless they use our accessibility APIs from Javascript. This is true in IE,

Rich Schwerdtfeger (RS): There was also a CSS DOM API that was specified by
the DOM working group and which moved to the CSS working group. It allows
you to walk the CSS style sheet stack, get properties, etc. Has this ever
been implemented in Firefox?

The W3C DOM is divided into the Core DOM, Events,  and the CSS piece. The
CSS piece was supposed to represent the view. When the DOM WG dissolved the
CSS piece moved to the CSS working group.

(AL): The CSS DOM is implemented in Firefox, but the spec doesn't allow you
to just get the text for a bullet. You'd have to count through the list
items, and taking into account the many kinds of numbering including roman
etc., calculate the list bullet text. Yikes!

There's also no system for events in the CSS DOM.

Perhaps there should be DOM events created that are fired when styles
change. That would also solve the issue where something suddenly becomes
display: none or was display: none and becomes visible, and there is no DOM
event fired.

The other thing is that this doesn't just relate to events. That's less of
an issue than the fact that layout-inserted text is not exposed in the DOM
at all.

(RS):  Getting the CSS events to occur would be through the DOM events
spec. but only if this benefited applications running within the web page.

(RS): I recommend you collect a number of these for a UAAG face- to-face in
the spring. Note: there will be an abridged tech plenary. I will suggest to
the PF working group a joint session for those meetings.

 Cathy Laws

Manager - IBM Software Group (SWG) Accessibility Architecture and
11501 Burnet Road,  Bldg 902 Office 2C016, Austin, Texas 78758
Phone: (512) 838-4595  FAX: (512) 246-8502
E-mail: claws@us.ibm.com, Web: http://www.ibm.com/able

Everyday that we leave behind  goes on to tell the truth, of how we lived
in the line between the two.   Mark Harris
Received on Wednesday, 6 September 2006 22:35:08 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:49:34 UTC