Re: ACTION-402: Re: WAI last call comments on CDF, WICD, WICD Full, WICD Mobile, WICD Core from Al Gilman on 2006-06-14 (public-cdf@w3.org from June 2006)

From: Al Gilman <Alfred.S.Gilman@IEEE.org>
Date: Wed, 14 Jun 2006 12:46:55 -0400
To: Kevin E Kelly <kekelly@us.ibm.com>, public-cdf@w3.org
Cc: member-cdf@w3.org, wai-liaison@w3.org
Message-Id: <p06110406c0b5e77ff597@[10.0.1.5]>

>At 12:04 PM -0600 5/2/06, Kevin E Kelly wrote:

Please thank the WAI WG for these comments. Responses below inline,
marked with <CDFWG>.

Thanks,
Kevin

On behalf of the CDF WG
If this does not satisfy your comments, please respond within 2 weeks.

</quote>

Sorry not to make the requested two week turnaround.

Below please find our responses to your dispositions of these comments.

CDF 1.0 review

Sounds like are requiring DOM 3 through the use of ReferencedDocument
- Document.Write() is gone - yes?

Are you going to get the browser manufacturers to implement this as
none of the support DOM 3 today? DOM 3 has accessibility features.

<CDFWG> The Compound Document by Reference Framework (CDRF) is not
requiring all of DOM3 to
be implemented, but instead specifies specific parts of DOM3 or DOM3
compatible
behavior that is required for CDRF profile conformance.
<CDFWG> In order to be Compound Document by Reference profile conformant,
(<http://www.w3.org/2004/CDF/Group/specs/CDR/wp1/cdf.xml#conformance>http://www.w3.org/2004/CDF/Group/specs/CDR/wp1/cdf.xml#conformance)
then:

<CDFWG> Profile Conformance

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

2. Compound Document profiles which leverage the Compound
Document
Framework and which support events and interactivity must
have
event interfaces and an event processing model that are
compatible
with the DOM Level 3 Events Specification.

3. For each event construct within supported languages,
the profile must define the event's namespace and local
name,
whether it supports the bubble phase,
and whether it is cancellable,
as well as the name of the DOM interface for its event
structure
(e.g., events.dom.w3c.org::UIEvent).

4. Any events that are defined to be equivalent to a
corresponding event from DOM3 Events must have compatible

behavior, such as the phases supported, cancellability
and propagation across parent/child Compound Document
boundaries. For example, for a "click" event from
language A to be equivalent to the DOM3 "click" event,
it also must be cancellable since DOM3 "click" is
cancellable.

5. The profile must define how to map language features for
event listeners, event handlers, and event targets into
corresponding DOM3 Events facilities.

<CDFWG> No change was made based on this comment.

<WAI-PF RESPONSE>

OK. Thank you.

</WAI-PF RESPONSE>

Section 2.2. You indicate that a child document may allow for event
propogation up. You may want for selective propogation. Implementing
Dynamic XHTML accessibility solutions usually involves placing a
keyboard handler on the root document to capture all the keyboard
commands and driving navigation. You would like to have this drive
navigation of all child documents as well instead of having this in
multiple interception points. The group should consider that
DocumentEventPropagation be selective. You may not want all events to
propoagate up. Your interface, below, indicates a boolean decision
for all events:

interface DocumentEventPropagation {
attribute boolean propagate;
};

<CDFWG> Yes, event propogation has been changed to:
<http://www.w3.org/2004/CDF/specs/CDR/wp-1/cdf.xhtml#event-propagation>http://www.w3.org/2004/CDF/specs/CDR/wp-1/cdf.xhtml#event-propagation

<WAI-PF RESPONSE>
OK. Thank you.
</WAI-PF RESPONSE>

<CDFWG> 2.2.1 Event Propagation

Using the various methods and attributes described in
[WINDOW],
[DOM3EVENTS] and [DOM3CORE] it is possible for web authors to
attach an
event listener to a child document and then upon catching it

dispatching it in the parent document on the referencing
element. The
following piece of script would create an event and dispatch
it upon
the referencing element:

var x =
document.createEvent("CustomEvent");
x.initCustomEventNS("
<http://example.org/test>http://example.org/test", "test", true, false, null);
window.frameElement.dispatchEvent(x);

<CDFWG> This suggested change has been made.

<WAI-PF RESPONSE>
OK. Thank you.
</WAI-PF RESPONSE>

How do you deal with tab sequencing? Each document may have a
different tabbing mechanism such as XHTML 1.X using TABINDEX and
XHTML 2.0 using nextFocus.

<CDFWG> Tab sequencing is addressed extensively in:
Latest working draft
<http://www.w3.org/2004/CDF/specs/CDR/wp-1/wicd.xhtml#focus-navigation>http://www.w3.org/2004/CDF/specs/CDR/wp-1/wicd.xhtml#focus-navigation
Dec192005 document you reviewed
<http://www.w3.org/TR/2005/WD-WICD-20051219/#focus-navigation>http://www.w3.org/TR/2005/WD-WICD-20051219/#focus-navigation
These sections have not changed between these two versions.

<CDFWG> No change was made based on this comment.

<WAI-PF RESPONSE -- affects 6.1>
This clarifies things a great deal. A problem still exists however. You
made a comment about the use of focusable as a means of determine what is
focusable.

Since you are advocating the use of script to allow for a compound document
supporting Rich Internet Applications and you are assembling a profile when
defining your compound document you need to address the problem of users
being able to focus content with a pointing device or mouse. In XHTML and HTML
DIVs, TDs, SPANs, etc. are used to create custom widgets. These must
be made accessible
via the keyboard. This can be addressed by three mechanisms:

We are impressing on you the importance of this because you are, we believe,
creating the foundation on which to build our web applications. At some point,
the web application group will hit this problem and go back to you as
well. We would like
this addressed now rather than later. Here are our suggestions:

1. Adding to the schema to support TABINDEX on these attributes.

TABINDEX should also support values of 0, and -1 to allow script
authors to make them focusable without
effecting the actual tab order. This makes them focusable but not
tabbable. This capability is supported
for authors in both Firefox and IE and other manufacturers are
looking to adopt. This is supported in
both XHTML and HTML in these browsers which is consistent with your
plan to support HTML. For more information,
go to the Dynamice Web Accessibility Roadmap at
<http://www.w3.org/wai/pf/roadmap>http://www.w3.org/wai/pf/roadmap and
go to section 4.1.3.

2. Add a focusable attribute to the profile applicable to all xhtml elements.

3. Requiring the HTML working group to add either 1 or 2 to their
specifications.

Work with the WebAPI group to make element.focus() on all elements to
direct focus to the element if it is focusable.

This brings up the second issue. It would be helpful to define not
only focus but also focus-traversable.
Focus-traversable addresses the tab order. In XHTML2 all elements are
"focusable" but may not be focus
traversable.

</WAI-PF RESPONSE>

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.

<CDFWG> We are making every effort to combine existing markup "as is".
Adding an attribute to the object tag for language should be taken up with
the working group
responsible for that element.

<CDFWG> No change was made based on this comment.

<WAI-PF RESPONSE>
Accept: On the advice of the i18n Core WG, we accept this. This is in
fact an accessibility
problem encounter because of the importance of TTS in accessibility.
You may refer
to WCAG 2 guideline 3.1.

http://lists.w3.org/Archives/Public/public-i18n-core/2006AprJun/0077.html

In defining XHTML2 we thought about this problem as we realized as XHTML 2
could be used as a main document of one that is compound and made the
lang attribute required in the header.
</WAI-PF RESPONSE>

Section 2.3.1

Why do you refer to HTML4 in this spec. No HTML 4 implementation
supports DOM 3. Also it is non-extensible which is problematic for
adding accessibility semantics targeted for XML markup.This ius a
step backward. It would seem that supporting an non-XML based infoset
document format is a mistake.

<CDFWG> The CDFR is not requiring that only XML infoset based markups
shall be used in defining in a compound document profile. Therefore the
CDRF will
support compound document profiles constructed with non XML Infoset based
markup.
However, the Working Group has not defined a Core document or profiles
that call for
non XML infoset based markup, but allow the framework to support it should
anyone want
to define a profile composed of non XML infoset based markup.

<CDFWG> No change was made based on this comment.

<WAI-PF RESPONSE>
OK. Thank you.
</WAI-PF RESPONSE>

2.1.4 SecurityException
<http://www.w3.org/TR/2005/WD-CDR-20051219/#security-exception>http://www.w3.org/TR/2005/WD-CDR-20051219/#security-exception

Accessing parent or child documents through the DOM as described in
sections
2.1.2 and 2.1.3 can be disabled for security reasons. In such cases user
agents should throw a SecurityException

<UAWG> User agents should inform the user that access has been blocked for
security reasons.
</UAWG>

<CDFWG> Section 2.1.4 Security Exception has been removed.
<http://www.w3.org/2004/CDF/specs/CDR/wp-1/cdf.xhtml#dom>http://www.w3.org/2004/CDF/specs/CDR/wp-1/cdf.xhtml#dom

<CDFWG> This suggested change has been made.

<WAI-PF RESPONSE>
OK. Thank you.
</WAI-PF RESPONSE>

2.3 Link Activation
<http://www.w3.org/TR/2005/WD-CDR-20051219/#link-activation>http://www.w3.org/TR/2005/WD-CDR-20051219/#link-activation
<snip>

Nested hyperlinks are more complicated. The following illustrates nested
hyperlinks. Suppose the parent document is XHTML as follows:

<html:a href="LargeMap.html">
<html:object type="image/svg+xml" data="child.svg"/>
</html:a>

And the child SVG document contains the following:

<svg:a xlink:href="DetailedCountyMap.html">
<svg:text>county map</svg:text>
</svg:a>

<snip>

The implication is that the behavior of nested hyperlinks depends on how
the
hyperlink is activated. Here are some examples which illustrate common
possibilities:

* Suppose the user gives focus to an <html:a> within the parent XHTML
document above and then hits the "Enter" key to activate that link. In the
example above, the <html:a> element is the event target. This would cause
execution of the hyperlink to "LargeMap.html".

* Suppose the user gives focus to an <svg:a> within the child SVG document
and then hits the "Enter" key to activate that link. In the example above,
the <svg:a> element is the event target. This would cause execution of the
hyperlink to "DetailedCountyMap.html".

* Suppose the user uses a mouse or other pointer device to click on the
work
"county map" in the above example. Because this pointing device event
occurs
over geometry controlled by both the parent XHTML and child SVG documents,
and because the SVG document is the most deeply nested, then the target
element will be chosen according to the rules in the SVG specification. In
the example above, this will cause the <svg:text> element to be the event
target. The <svg:a> element will receive the event after bubbling from the
<svg:text> element, which will cause a hyperlink to
"DetailedCountyMap.html".

<UAWG>The above scenario provides some intriguing accessibility problems.
At
each stage the user must be given a choice 1) activate the anchor, 2)
enter
the nested container. The user agent must inform the user of the available
paths, so the user is able to give focus to the required element.

Given the first 2 bullets in the scenario, the user agent will display the
text "county map" with html anchor designation (blue and underlined,
assuming no style sheet). When the user gives focus to the anchor "county
map", the user agent should inform the user that a hyperlink may be
activated or a child container may be entered. The user now has the option
of viewing "LargeMap.htm" or entering the "child.svg" container. After
entering the "child.svg" container can the user be informed that an
additional anchor (svg:a) is available to be given focus and execution to
display "DetailedCountyMap.htm" (the second bullet). At any point in the
tree the user (with information available from the user agent) should be
able to orient themselves (determine where they are) within the
document(s)
tree (parent document - html:a - child.svg - svg:a) and navigate back up
or
down the tree.

The 3rd bullet "* Suppose the user uses a mouse or other pointer device to
click on the work "county map" in the above example. Because this pointing
device event occurs over geometry controlled by both the parent XHTML and
child SVG documents, and because the SVG document is the most deeply
nested,
then the target element will be chosen according to the rules in the SVG
specification. In the example above, this will cause the <svg:text>
element
to be the event target. The <svg:a> element will receive the event after
bubbling from the <svg:text> element, which will cause a hyperlink to
"DetailedCountyMap.html".

Question: How will a pointing device user able to activate the html:a
"LargeMap.html"? or Where in the geometry does one point to activate the
html:a "LargeMap.html"? How is the user agent to inform the user that two
(or possibly more) paths are available from a single (visually apparent)
anchor?
</UAWG>

<CDFWG> The hyperlink/link activiation section has undergone a significant
amount
of change that I beleive addresses some of your comments. However, some
of the
comments should to be directed at the working groups that own the markup
you
are citing. Please review the new text below and resubmit new comments if
CDF related
issues have not been addressed/clarified.

<CDFWG>
<http://www.w3.org/2004/CDF/specs/CDR/wp-1/wicd.xhtml#hyperlinking>http://www.w3.org/2004/CDF/specs/CDR/wp-1/wicd.xhtml#hyperlinking

<CDFWG> 5 Hyperlinking

If it is possible to link from XHTML to Format-X, it should also
be possible to link from any other supported format to Format-X.

WICD compliant agents should support seamless hyperlinking between
any of the supported formats.

If linking from XHTML to Format-X will invoke content type specific

treatment on arrival, then linking from any Scalable Child Element
to Format-X should result in the same treatment.
(Examples for this are special content handlers for RSS, Java,
content download.)

Any content type supported by the user agent, when linked-to
originating from
XHTML, should also be supported by linking-to originating from any
other
supported format.

If a WICD compliant agent supports linking from XHTML to URI
schemes
other than http:// (for examples wtai:// and pcast://), then these
URI
schemes should also be supported, when linked-to from any other
supported format.

All URI schemes, supported for hyperlinking and the related
functionality,
should be supported, independent of the content format.

<CDFWG> This section was rewritten and should be reviewed again.

<WAI-PF RESPONSE>
This is indeed a complicated area. We don't beleive CDFWG addressed the
issue represented by UAAG. You did not state your rules for what gets
activated.
When documents are embedded within
anchors who in themselves have a link, the CDFWG should state the rules
for the user agent in how to handle embedding. One suggestion might be to
say that the parent hyperlink is activated in the containing anchor until
the embedded document has focus. Alternatively, the activation could go to
the lowest embedded child document (parent child hierarchy) which has a link.
This is not clearly stated. This should be coordinated with the web
application working group since the W3C does not have a "user agent" working
group.
</WAI-PF RESPONSE>

Web Integration Compound Documents (WICD Core) review

Commenting on
<http://www.w3.org/TR/2005/WD-WICD-20051219/>http://www.w3.org/TR/2005/WD-WICD-20051219/

3.2.1 Why would you not allow for a link to be activated on a static
rendering. Image maps allow for links on static elements? They in
themselves are not dynamic but they tell the browser where to go.
When you traverse the content within an static svg document, will
there still be a DOM for the SVG document? Is the DOM gone such that
you cannot walk the children. You are not explicit here. Remember,
script writers may want to walk it. The difference is that the DOM
elements in the SVG will have handlers that do not work.

Whether static or frozen, why would you not want the links to be
activatable. AT vendors would walk the DOM and want to activate the
link. Is the memory reclamation for links that valuable. If you are
going to do this then more work to address state changes of frozen
and static so that AT vendors can monitor when links become active or
disabled.

<CDFWG> The basic idea is to have a set of
icons, or thumbnails, of different SVG documents, and those icons are
rendered statically - i.e., no animations (or maybe there are), but no
activatable links. This means that the amount of resources
required to render these icons is significantly reduced as they don't
need to be live - an image can be rendered once and then just displayed.
These SVG icons would likely be rendered inside some HTML content that
linked to some sort of larger representation of the content - either the
standalone SVG document or the SVG document within some XHTML, where the
SVG content is rendered in its full glory - animations, interactions,
links, etc.

<CDFWG> No change was made based on this comment.

<WAI-PF RESPONSE>
That is fine. Please clarify this in your document to state your
intent.
</WAI-PF RESPONSE>

3.2.2 Scalable Background Image

This document should state that background images MUST not convey any
useful information. In other words they must only be eye candy. They
must always be fixed. Low vision users, in particular seniors, will
want to remove these images as they will not be able to read text in
a document. Others will want to programatically disable the animation.

<CDFWG> The use case here is something like a background image of the
word "draft" on every page of a draft document. In this use case the
background image does convey useful information.

<CDFWG> No change was made based on this comment.

<WAI-PF RESPONSE>
If that is the case then there must then be a mechanism to state the
alt text for the background image. Now, draft could be easily
indicated in the title of a document but draft is a simple case. If
more information than just "draft" in the background then you need to
provide alternative text. Please refer to the WCAG 1.0 checkpoint 1.1.
</WAI-PF RESPONSE>

3.2.3 Scalable Overlay Objects (Sprites)

This is a potential accessibility problem. If the Overlay is an SVG
document, the user needs to be able to navigate it. How, through the
DOM does a scripting application or user agent traverse the overlay
and come back? What semantics in the DOM indicate an overlay or a
real active document?

<CDFWG> The WICD profiles need to support transparent overlay objects
that are non navigable IAW HTML, CSS, and SVG. Issues with this
functionality should be addressed with one of those WGs.

<CDFWG> No change was made based on this comment.

<WAI-PF RESPONSE>
Please explain the use for non-navigable overlay that the user can't
get to. This
should also be addressed in CSS, SVG, and Web Application working
groups. It is important
to specify how you navigate in the Z-index.
</WAI-PF RESPONSE>

3.3.3 Transparency

This is potentially an accessibility problem. If something is an
overlay it must be possible to give something in the overlay focus.
For example, you could have an xhtml menu and then launch a sub menu
in SVG. Now, when it comes to these issues it tells me you also need
to accomodate the work we are doing in WAI PF to address
accessibility for roles, properties, and states. Associations need to
be made between related objects once you put them outside the
confines of a boxed area on the page.

<CDFWG> No change was made based on this comment.

<WAI-PF RESPONSE>
We have the same comment as 3.2.3.We should we address this
with both address this with the web application working group.
</WAI-PF RESPONSE>

6 Focus Support

This is inadequate.

- How does one navigate in and out of a child document when TABINDEX
is applied in the XHTML root and the embedded object is SVG? How does
this impact the tab sequence when the embedded document uses
something other than TABINDEX?
- When someone is tabbing in a document, what is the navigation
scheme for going into and out of an embedded document. Do you tab
into the document, tab out, what? Does the user agent have to provide
additional keys.

There is more here than just being able to give an object focus. You
need to decide for the author how navigation will work in and out of
a compound document. This is a problem today for plug-ins where often
there is no mechanism to use the keyboard to step into a plug-in and
out. This document adds an additional level of extraction because
documents are linked together in that you can navigate up to and into
referenced DOMs. If this is the case, then how is navigation
addressed consistently.

<CDFWG> The CDF WG came to resoulution, that no single, binding method
for
navigation can be mandated by the WICD specification. Implementors
were pointing out, that navigation is highly device specific and that
it cannot be specified in generic ways. This is why the WICD
specification describes focus navigation only in an informative section.

Two things to note about the flat / two-dimensional focus navigation
method:
- mainly, it describes a role model behavior for standard handsets
with 4-way joystick navigation
- it is not based on TABINDEX

<CDFWG> No change was made based on this comment.

<WAI-PF RESPONSE>
OK. Please include a comment that if you are able to navigate into an
embedded document you need to be able to navigate out of it.
</WAI-PF RESPONSE>

6.1 Focusable Child Elements

Comments here are not CDF issues but the inconsistency in document
focus support. The focusable property, while available in SVG, is
incosistent with XHTML. I would like to see the addition of TABINDEX,
as implemented in IE, addressed for DIVs and SPANs. Note: this could
be an added module.

This means that there needs to be a capabiltiy for any renderable
element in the compound document focusable. The referencing alone is
not a valid reason. In the Dynamic Web Access work
(www.w3.org/wai/pf/adaptable) we can make DIVS and SPANS be focusable
but we do this by placing a TABINDEX on these. TABINDEX can have a
value of 0 (focusable but in document order) or -1 (focusable but
never in the tab order). This is consistent with IE and Firefox.

Note: Progrmatically speaking, an XHTML anchor element has no
property I am aware of that says it has an inherent "focusable"
property. What happens with MathML?

<CDFWG> We will replace the sentence

"Which elements qualify as focusable elements must be defined by this
specification or by the profiles that are built upon this specification."

with the text

"The language specifications that are used with this framework should
define what elements are focusable."

In addition, we will include the following informative note
right after the previous sentence

"The current XHTML specifications do not clearly define what elements
are focusable. It is common industry
practice that all elements, which have tabindex attribute are focusable,
e.g., a, input, select, textarea, object, button, area."

<CDFWG> This change was accepted and implemented as above.

<WAI-PF RESPONSE>
Same response as we provided to 6.1 earlier.
</WAI-PF RESPONSE>

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:

It would be good to pull this in.

<CDFWG> No change was made based on this comment.

<WAI-PF RESPONSE>
Same response as we provided for 6.1.
</WAI-PF RESPONSE>

6.3.1 Two Dimensional Focus Navigation (Flat, Graphical, Joystick)

Accessibility requires logical navigation. You need solid rules for
determining navigation. Viscinity navigation seems silly and in fact
it looks like you skip elements that should be traversable. Although
this section is informative, what if I have a declarative tabindex
solution - would this take precedence?

To point out applicable parts of your this section:
The focus navigation algorithm consists of three phases: finding
candidates for focus movements, calculating and adjusting movement
based on a distance function, and moving the current focus point with
possibly changing focusable element.

- Navigation should be logical determined by document structure, or
specified by the author
- Requiring the user to follow navigation to all elements in a series
without a consistent mechanism to compartmetalize and skip sections
(like menus in a GUI) is a usability problem.

This viscinity navigation approach should go away over time.

<CDFWG> No change was made based on this comment.

<WAI-PF RESPONSE>
OK.
</WAI-PF RESPONSE>

6.3.2 One Dimensional Focus Navigation (Linear, Focus Ring, Tab)

This is frought with usability problems. New DHTML work will allow
you to skip to content without of semantic interest without tabbing
through every element. (DHTML work). XHTML can skip this standard
navigation by using Keyboard handlers and JavaScript. Got to this
URL:
<<http://www.mozilla.org/access/dhtml/spreadsheet>http://www.mozilla.org/access/dhtml/spreadsheet
><http://www.mozilla.org/access/dhtml/spreadsheet>http://www.mozilla.org/access/dhtml/spreadsheet

This is very stressful for people with mobility impairements and
people who are blind. The user is being made to traverse all elements
whether needed or not. Although this section is informative, what if
I have a declarative tabindex solution - would this take precedence.

<CDFWG> No change was made based on this comment.

<WAI-PF RESPONSE>
OK.
</WAI-PF RESPONSE>

7.1 System Fonts

System fonts must be supported by the operating system such that when
their sizes are changed by the user they are reflected on the
document. This impacts Font Sharing - I believe but that is not clear.

This is not a CDF issue but it is important that this be stated.

<CDFWG> No change was made based on this comment.

<WAI-PF RESPONSE>
Accept (not CDF issue).
</WAI-PF RESPONSE>

9.2.1 Interaction with the 'render' param

User agents must allow others to change the rendering speed. High
rendering rates (flashing) can cause seizures for people with
epilepsy.
<<http://www.w3.org/TR/2005/WD-WCAG20-20051123/guidelines.html#seizure>http://www.w3.org/TR/2005/WD-WCAG20-20051123/guidelines.html#seizure
><http://www.w3.org/TR/2005/WD-WCAG20-20051123/guidelines.html#seizure>http://www.w3.org/TR/2005/WD-WCAG20-20051123/guidelines.html#seizure

CDF should require the user agent who is implementing this to
configure the rate of animation.

<CDFWG> Since WICD Core uses SVG and SMIL Timing and Synchtonization
module
to control animation rendering, this comment should be redirected to
those working groups.

<CDFWG> No change was made based on this comment.

<WAI-PF RESPONSE>
OK. Thank you.
</WAI-PF RESPONSE>

9.3 Play Animations while Document is loading

There is a problem when network latency and bit-heavy sub-objects
cause the onLoad event
to fire after the user has started to interact with widgets in the page.

<http://hades.mn.aptest.com/cgi-bin/xhtml2-issues/HyperAttrs?id=7792>http://hades.mn.aptest.com/cgi-bin/xhtml2-issues/HyperAttrs?id=7792

PFWG would like to confirm that this is a serious and common problem.

The current suggested remedy from PFWG to the HTML WG is that

an onload script handler attempting to set focus after focus has
already been set should cause the user agent to generate an exception
to the script being executed and not move focus.

</quote>
Please continue to track this issue to its resolution.

<CDFWG> No change was made based on this comment.

<WAI-PF RESPONSE>
Accept (format by format, not CDR): This needs to apply to each of the
root language formats as we did for XHTML 2.
</WAI-PF RESPONSE>

1.1 Scope -
<http://www.w3.org/TR/2005/WD-WICD-20051219/#scope>http://www.w3.org/TR/2005/WD-WICD-20051219/#scope
In the description of the profiles the following items are listed:
1 Content author/provider has exact control of the presentation, including
fonts, layout, color, etc.
2 Layout adaptation: layout can be based upon device characteristics -
screen size, color depth, resolution, orientation.
3 Presentation can be customized to reflect a brand or user's personality.
<uawg> first bullet: this can be overridden by the user through system
settings, browser controls, and user css overrides. Correct?
<CDFWG> yes
Second bullet: this includes user system settings. Correct?
<CDFWG> yes
Third bullet: would like to add ?and needs? after ?personality?
<CDFWG> This suggested change has been made.
</uawg>

<WAI-PF RESPONSE>
ok, Thanks.
</WAI-PF RESPONSE>

3. Scalable Child Elements
<http://www.w3.org/TR/2005/WD-WICD-20051219/#scalable-child-formats>http://www.w3.org/TR/2005/WD-WICD-20051219/#scalable-child-formats
<uawg>
We agree with the requirements for functions user agents must support.
On reading this section, we hoped to find something about the user being
able to scale the destination box.
For example: a user has default font size set to 18 points. An svg element
with fixed size (100x100) is referenced in a document. The default font
size
causes the information to expand behind the bounding edge of the svg
element. The user must now focus on the svg and scroll within the svg.
</uawg>

<CDFWG> The CDF WG suggests this issue be taken up with the HTML group
that owns the <obj> element.

<CDFWG> No change was made based on this comment.

<WAI-PF RESPONSE>
OK. We will coordinate UAWG.
</WAI-PF RESPONSE>

6.1 Focusable Child Elements
<http://www.w3.org/TR/2005/WD-WICD-20051219/#focus-management>http://www.w3.org/TR/2005/WD-WICD-20051219/#focus-management
<uawg> We agree with the requirements user agents.

?Child-specific functionality should be restricted to preserve the
author's
intent. Should element specific functionality be desired, the element must
advertise itself as being focusable or implicitly made focusable by a user
agent.?

There seems to be a conflict here. First you say child-specific
functionality should be restricted. Then, you say ?should functionality be
desired, the element must advertise itself as being focusable or
implicitly
made focusable by a user agent.? By default the user agent should make all
child elements focusable, so when the user desires specific functionality
it
is available. From an accessibility perspective, while the user agent
should
respect the author?s intent, the user should be able to override that
intent.
</uawg>

<CDFWG> The CDF WG does not agree with the rule that "By default the user
agent should make all child elements focusable". Instead, all non-
interactive child elements (e.g. SVG elements) should be treated like
jpg, gif or png child elements are treated today. Only interactive
child elements (and those with embedded links, etc.) may require
focus. Thus, it is the child element, that must advertise itself as
being focusable.

<WAI-PF RESPONSE>
Refer to earlier response to 6.1.
</WAI-PF RESPONSE>

6.3.2 One Dimensional Focus Navigation (Linear, Focus Ring, Tab)
<http://www.w3.org/TR/2005/WD-WICD-20051219/#focus-nav-one-dim-linear>http://www.w3.org/TR/2005/WD-WICD-20051219/#focus-nav-one-dim-linear

<snip>
XHTML and SVG have methods for linear one dimensional focus traversal.
XHTML
provides a default traversal order, and allows it to be changed with the
use
of tabindex attribute within one XHTML document. SVG's provides the
focusNext and focusPrev elements which may be used to provide similar
functionality within an SVG document. However, neither of these methods
can
be used when XHTML and SVG are combined. Therefore in the case of a WICD
document by reference, combining XHTML with SVG, some alternate form of
navigation is required.

<uawg> This is indeed a problem. Perhaps, in a ?WICD document by
reference,
combining XHTML with SVG?, the user agent should default to
one-dimensional
focus transversal based on source code order.

Tabindex and focusNext/focusPrev each have inherent accessibility
problems,
mostly confusing the user as to the next/previous element that will
receive
focus. Tabindex may take the user on an author defined path through
focusable content and then through the remainder of the focusable content
that was not part of the author defined path. The user can traverse this
in
reverse order also, so in this respect it is consistent.
focusNext/focusPrev allows the author to define 2 distinct paths, separate
from the source code order. For example, the content has 6 focusable
elements. Each can have a unique focusNext and a unique focusPrev. In the
list below the first element is the focusable element in source code
order,
the second item preceded with an ?n? designates the focusNext order, the
third item preceded with a ?p? designates the focusPrev order

1 ? n2 p6
2 ? n4 p3
3 ? n1 p5
4 ? n3 p2
5 ? n6 p1
6 ? n5 p4

so following the source path the user would proceed 1-2-3-4-5-6
if the author set focusNext, starting at element 1, the path would be
1-2-4-3-1 and loop from there.
If author set focusPrev, starting at element 1, the path would be
1-6-4-2-3-5-1.

</uawg>

<CDFWG> See response to 6.1 Focusable Child Elements above changes.

<WAI-PF RESPONSE>
Refer to our earlier response to 6.1.
</WAI-PF RESPONSE>

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?

<CDFWG> The framework and core documents do not reference a specific
version
of XHTML, it is the purpose of the profile document to reference the
specific versions of the markups being combined.

<CDFWG> No change was made based on this comment.

<WAI-PF RESPONSE>
OK.
</WAI-PF RESPONSE>

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. We cannot afford to see this repeated.

<CDFWG> Accessibility issues with ECMAScript should be addressed with
the responsible working group for ECMAScript.

<CDFWG> No change was made based on this comment.

<WAI-PF RESPONSE>
We disagree. Setting focus has to do with the underlying markup problems and
the API specified by the DOM. What script can do is based on these two areas.
Since you are focusing on building a foundation for web applications, you have
to address the fact that XHTML was not designed to address scripting and the
focus issues that result. See our response to 6.1.
</WAI-PF RESPONSE>

This specification misses picking up critical XHTML accessibility
extensions found in XHTML 2 for the role attribute. This WAI PF
working group is also developing (add-ons to XHTML 1.1) to address
dynamic web accessibility (using JavaScript) and they are not being
included here or in the roadmap. This is a big omission. Our changes
can be added onto XHTML 2 so we would like these to be considered for
adding on - otherwise you end up with another scripting accessibility
problem. I would like to see these XHTML 1.1 extensions be
incorporated into these specifications or have a clear migration path
to incorporate them:
<<http://www.w3.org/2004/CDF/Group/roadmap.html>http://www.w3.org/2004/CDF/Group/roadmap.html
><http://www.w3.org/2004/CDF/Group/roadmap.html>http://www.w3.org/2004/CDF/Group/roadmap.html.

The following highlights our specificationss and our roadmap
pertaining to Dynamic Web Access.

Dynamic Web Content Accessibility Work effort:

The working group has a focused effort to fix the accessibility of
Rich Internet web Applications (RIAs). The inaccessibility of these
applications has often been categorized as "JavaScript Accessibility
Problem." These applications make use of script to re-purpose
existing markup to create new application widgets not defined by the
markup. The accessibility of today's markup, such as XHTML and HTML,
depends on the mixture of content and presentation. The accessibility
problem stems from the markup not providing the capability for the
page author to provide additional accessibility Meta data which can
be mapped by the browser to platform accessibility APIs when
re-purposing occurs. The problem surfaces in many other circumstances
ranging from when HTML uses the <table> element for layout to the SVG
usage of primitive drawing markup to create complex graphics that
imply richer semantics. Solving the problem involves the use of
cross-cutting technologies whose principles may be used for
accessibility reform across many industry content renderable markups.
Finally, these specifications are intended to support XHTML markup
rendered in today's desktop browsers. Three W3C WAI PF working drafts
involved are described here:

<<http://www.w3.org/WAI/PF/GUI/>http://www.w3.org/WAI/PF/GUI/>Role
Taxonomy for Accessible Adaptable
Applications

This specification defines an RDF taxonomy of roles which describe
custom GUI widgets and document structure which may be used to
support platform accessibility APIs. Roles encapsulate semantic
information which may be use to help: user agents support assistive
technologies; authoring tools enforce accessibility, and assistive
technologies discover new custom objects and how to interoperate with
them.
<<http://www.w3.org/WAI/PF/adaptable/>http://www.w3.org/WAI/PF/adaptable/>States
and Properties Module

This specification defines attributes that provide XML languages with
the ability to add extra information about the behavior of an
element. States and Adaptable Properties are mapped to accessibility
frameworks (such as a screen reader) that use this information to
provide alternative access solutions. Similarly state and author
properties can be used to dynamically change the rendering of content
using different style sheet properties. The result is to provide an
interoperable way for associating behaviors with document-level
markup. Additionally, this specification includes markup to fix
keyboard focus problems with today's XHTML 1.X markup.
How the fit into our roadmap:

<<http://www.w3.org/WAI/PF/roadmap/>http://www.w3.org/WAI/PF/roadmap/>Dynamic
Accessible Web Content Roadmap

This roadmap that describes the problem, what W3C specifications will
be used to correct the problem, and the timeline for the new
specifications.

Additionally, this specification does not pick up the standard role
attributes delininiating semantic sections of a document:
<<http://hades.mn.aptest.com/htmlwg/xhtml-m12n-2/mod-role.html#s_rolemodule>http://hades.mn.aptest.com/htmlwg/xhtml-m12n-2/mod-role.html#s_rolemodule
><http://hades.mn.aptest.com/htmlwg/xhtml-m12n-2/mod-role.html#s_rolemodule>http://hades.mn.aptest.com/htmlwg/xhtml-m12n-2/mod-role.html#s_rolemodule

<CDFWG> Accessibility issues with XHTML/HTML should be addressed with
the responsible working group for XHTML/HTML.

<CDFWG> No change was made based on this comment.

<WAI-PF RESPONSE>
Accept: PFWG will take this up with the individual format working groups.
</WAI-PF RESPONSE>

WICD Mobile 1.0 review

This calls out for script support and XHTML Basic. XHTML basic does
not support the script and noscript elements. Are you using
ECMAScript to generate the entire page? This is confusing.

The following is from XHTML Basic section 1.3.2. Script and Events
(of XHTML Basic)

The script and noscript elements are not supported. Usually small
devices have limited memory and CPU power. Execution of script
programs may not be supported. Contents should be readable even if
scripts are not executed.

Event handler attributes used to invoke script programs are not
supported. Events are device dependent. An incoming-call event is
unlikely to happen in a television. A generic event handling
mechanism would be more appropriate than hardwiring the event names
in the document type definition.

<CDFWG> We are asking the HTML WG to include it.
<CDFWG> This change has been accepted.

<WAI-PF RESPONSE>
Accept: OK. Thank you.
</WAI-PF RESPONSE>

Received on Wednesday, 14 June 2006 17:02:16 UTC