thoughts on your WICD comments

<note
class="inTransmittal"

Thank you Ann for your discussion of our comments. These replies are
informal, as your response was informal. But they do reflect
discussion and a rough consensus in the PF group.

As always, we welcome opportunities to explain and learn leading to
better win-win resolutions of what appear to be issues.

Thanks again,

Al
/chair, PFWG

with input from
Rich Schwerdtfeger, a participant in both PFWG and HTML WG

</note>

Responding to this link:

<http://lists.w3.org/Archives/Public/public-cdf/2006Jan/0071.html>http://lists.w3.org/Archives/Public/public-cdf/2006Jan/0071.html

>document.write() is still in DOM Level 2 HTML, why would it be gone?  
>(There is no subsequent version of DOM Level 2 HTML (like DOM Level 3  
>HTML) either.)

Elsewhere in the specification, it is indicated that implementations
supporting a script interface must support DOM3. There is a
corrollary to this support. Where the DOM is available, mutations of
the document must be managed in DOM terms and not as XML text
injected by using the document.write method.

Determining the DOM mutation when a perturbation is defined at the
XML text level is problematical. This has been discussed in the HTML
Working Group and the restriction to avoid document.write is the
logical fix. The CDF specification(s) should impose this restriction
so that authors understand that they should follow it.

>>  What is the default language per embedded document? For example, what  
>>  happens when you have a lang attribute in a block, specified in XHTML,  
>>  set to Spanish, and within it you have an object tag referencing an  
>>  embedded SVG document or some other document? XHTML 2.0 requires a lang  
>>  attribute on the document. It would be nice if we stressed consistency  
>>  across other XML markups - or we require this on the object tag.
>
>"lang" or "xml:lang" only inherit within a document, they don't inherit  
>their way into child documents. The same as with CSS and other things.

Correct. So this is a serious problem. If the parent document 
specifies a lang attribute of english and the embedded document is in 
French we have a problem. XHTML 2 addressed this by requiring the 
lang attribute in the header. Screen Reader vendors will not know to 
switch languages. This is a general problem.

>>  Why do you refer to HTML4 in this spec. No HTML 4 implementation  
>>  supports DOM 3.

>No XHTML implementation supports it either. In fact, I'm not aware of any  
>implementation that has full DOM Level 3 support. (And then some parts of  
>DOM Level 3 are still a note and not yet a recommendation.

This is from Section 3.1 of the CDF specification. This is much more 
than a note. This says that script supporting CDF profiles *must* 
support DOM Level 3:

2.1 Document Object Model

Compound document profiles which leverage the Compound Document 
Framework and which support scripting must have scripting interfaces 
that are compatible with the DOM Level 3 Core Specification.

>The whole web uses HTML. You would think that solutions for accessibility  
>would also target the web as it is. Adding semantics in HTML is possible  
>using the "profile" attribute and "class" attribute values. Extending  
>allowed values for "rel", et cetera.

At first blush, this is true. One could define the sense of @class
and @rel values in an RDF gloss and not extend HTML syntax. On the
other hand, in making scripted widgets accessible we need states that
control changes in the view to appear somewhere the Access API can
get at them. Is the flyout menu visible now or not? This is essential
information for a screen reader. The direct answer is for the
stylesheet to use a selector keyed to a field appearing in the DOM so
that the Access API can listen for mutations of that field to notify
AT when there are changes and the state can be shared.

There are sneaky ways to get the necessary states and properties
[adaptable] in the DOM with factory methods in the header that are
applied in an onLoad script and elaborate the DOM structure to
provide the DOM fields we need. This we fear would be unmaintainable
and double the text bloat of the pages.

In addition, although 'class' was put in HTML4 with the intent that it
be used for semantic, content-oriented classification, by custom it
is now understood by a large slice of the large population of web authors
as "style key ad_lib."  @role comes with a definition from its introduction,
thereby avoiding a need to bring about a culture change in the use
of @class.

For a variety of reasons including these, we have homed in on using
Modularization in HTML with XHTML 1.1 as the base and a small module
to add in what we are missing. If CDF can come up with an approach
that meets the accessibility functional requirements with even less
of a disruption to the authoring community, we are still ready to
learn.

[adaptable] http://www.w3.org/WAI/PF/adaptable/


>>  6.2 Focus Event triggered Child Element Animations
>>
>>  In our new DHTML spec you do not need to use anchors - you may also use  
>>  divs and spans:
>>
>>  <div TABINDEX= "-1">
>>     <object type="image/svg+xml" data="foo1.svg">
>>      <param name="animation" value="onfocusevent" />    </object>
>>  </div>
>>
>>  It would be good to pull this in.
>
>The attribute "TABINDEX" is not allowed on all elements. While I agree  
>that such an extension of HTML 4 (and specifications that build on HTML 4,  
>like XHTML 1 and the XHTML Modularization) would be quite useful for  
>accessibility purposes I haven't seen any proposed errata from the HTML WG  
>covering this change.
>
>Also, in the above example, why not directly put it on the <object>  
>element...

In our specifications for dymanic web access we allow tabindex to be 
valid on divs and spans.
Script writers use divs and spans to create widgets and they must be
capable of receiving focus. The HTML working group has decided not
to modify their spec. for XHTML 1.X. XHTML 2 has a different model
where all elements may recieve focus. What we have done in our
profile is to add TABINDEX to these elements. I do not see why
setting focus on an <object> tag addresses this problem.

>>  WICD Full 1.0 review
>>
>>  So, why does full only support XHTML 1.1 when your document specifies  
>>  the use of XHTML 2 or other markups? Is it because the browser does not  
>>  support XHTML 2?

>Which document specifies the use of XHTML 2?

I was reviewing the list of specs and I thought I read a note which 
referenced that XHTML 2 could possibly include XHTML 2.  This was 
simply to ask why do you limit WICD Full to XHTML 1.1 and not also 
XHTML 2. I could not find this again in the specs. so please ignore 
it.

>>  What is most concerning is these specs. address the use of ECMAScript  
>>  whose implementation on HTML or XHTML is frought with accessibility  
>>  problems due to gaps in HTML.

>Has the WAI WG raised issues with the HTML WG on this? If there are indeed  
>serious accessibility problems with HTML I suggest the WAI WG makes sure  
>they get resolved given that HTML is about the only language really used  
>on the web. The other 0.01% percent uses XHTML 1 which is based on HTML  
>and has the same semantics.

Yes, we have discussed this with them repeatedly and have an ongoing
cooperative relationship as they develop a to-be solution in XHTML
2.0 and we back-fill a down-level [relative to XHTML 2.0] stepping
stone.  The HTML WG is not currently chartered to be maintaining
HTML 4 as it is developing XHTML 2 so we are working with the XHTML
1.1 capabilities that they have already produced for modularly extensible
HTML.


CDF is developing a profile which allows for behavior added by
scripting. In our work in PFWG we have been learning what it takes to
make web content with scripted behavior accessible. This is
concurrent work in progress, but some basic architectural principles
are pretty clear. For example the comments above to support the DOM
and don't break the DOM tracking of document mutations by using
document.write.

Much of what we have found appears to be general good practice for
XML formats that touch the user interface, applicable across the
broad range of interaction-domain formats. So we believe that CDF
should incorporate these rules in their specifications or wind up
contributing materially to the proliferation of inaccessible web
applications if they are left out.

Received on Wednesday, 22 February 2006 16:24:32 UTC