thoughts on your WICD comments

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

thoughts on your WICD comments

Al Gilman


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



Reply | Threaded
Open this post in threaded view
|

Re: thoughts on your WICD comments

Anne van Kesteren-2

Hi Al, your response is much appreciated!

On Wed, 22 Feb 2006 17:18:07 +0100, Al Gilman <[hidden email]>  
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/>