Re: thoughts on your WICD comments

Hi Al, your response is much appreciated!

On Wed, 22 Feb 2006 17:18:07 +0100, Al Gilman <Alfred.S.Gilman@IEEE.org>  
wrote:
>> 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.

The write() method of the HTMLDocument interface is part of the DOM (for  
HTML). It has not been obsoleted by WG maintaining DOM Level 2 HTML  
implementation so in essence you have to support it. Now I don't know of  
any browser that supports it within XML though...


>> "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.

You mean for the <html> element? (Requiring it for the <head> element  
would not solve the problem...) Anyway, given that XHTML 2 is nowhere near  
W3C Recommendation that doesn't really solve the problem we have. Now if  
the HTML WG would have update HTML 4.01 to that effect (or issue a new  
version of HTML 4.01) and does the same for XHTML 1.0, the XHTML  
Modularization and specifications derived from the XHTML Modularization we  
might be able to solve part of this serious problem for the real world.  
Well, on the specification side of things, at least.


> Screen Reader vendors will not know to switch languages.

If some Screen Reader vendors just assume that the child document is in  
the same language as the parent document I would personally opt for  
another vendor.


>>>  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.

I was talking about DOM Level 3 Events, DOM Level 3 XPath and DOM Level 3  
Views and Formatting. These are all still a W3C Note and not a W3C  
Recommendation. There may be others.


>> 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.

So do I understand it correctly that the WAI WG is no longer concerned  
with the web as it is because it is too difficult to build something on  
top of it? I personally think that even though some of the web is hardly  
accessible at the moment research should be done in how that can be made  
accessible so everyone has access to all relevant information.

Technically not feasible is not something I'd opt for. Anyway, if there  
need to be extensions make them work in text/html (HTML 4.01 and XHTML 1.x  
or so) and quite a lot of authors will adopt those extensions to ensure  
accessibility for the screen readers that support those extensions. For  
example, a way to indicate that <ul> containing <li> containing <a> is the  
navigation menu of the site.


> 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.

And in use of namespaces, and in use of media types and in  
well-formedness, etc. Quite a lot of culture changes needed before things  
can be done "correctly." So say that XHTML 2 is ready in 2010 or so and  
the browser with the most market share ships with some buggy support for  
it in 2012 and about 90% of the internet users have upgraded to that  
browser in 2015 and then some authors might considering to start using  
XHTML 2 although they actually still want to be compatible with the other  
10% but can't because of the new namespace, etc.


> 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.

I'm not sure if CDF is the appropriate place (given that as David Baron  
once put it we're effectively doing the other part of Namespaces in XML)  
to address the hundreds of issues with HTML 4.01 and XHTML 1.x...


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


>>>  <div TABINDEX= "-1">
>>>     <object type="image/svg+xml" data="foo1.svg">
>>>      <param name="animation" value="onfocusevent" />    </object>
>>>  </div>
>
> 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.

It wouldn't. It would save you a <div> element. It's a shame the HTML WG  
does not acknowledge the usefulness of having "tabindex", albeit a bit  
hacky, on every element to cater the needs of script authors. It's  
supported by at least two "major" UAs including the market leader and it's  
one of the more useful features in making HTML accessible.


>>>  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.

I can't find in their charter http://www.w3.org/MarkUp/Activity that they  
are not allowed to do updates on HTML. It does say they can do work on  
known problems with accessibility and device independence for example.


-- 
Anne van Kesteren
<http://annevankesteren.nl/>
<http://www.opera.com/>

Received on Saturday, 25 February 2006 20:49:22 UTC