- From: Al Gilman <Alfred.S.Gilman@IEEE.org>
- Date: Fri, 27 Jan 2006 14:18:07 -0500
- To: public-cdf@w3.org
- Cc: wai-liaison@w3.org
<note class="inTransmittal"> These comments have been collected and lightly reviewed within the User Agent Working Group and the Protocols and Formats Working Group. Where they are not clear or you feel you need to reject a comment, we would welcome the opportunity to discuss the issues for the purposes of clarification and mutual understanding. Thanks, Al /chair, PFWG </note> 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. 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; }; 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. 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. 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. 2.1.4 SecurityException 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> 2.3 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: <!-- parent.html --> <html:a href="LargeMap.html"> <html:object type="image/svg+xml" data="child.svg"/> </html:a> And the child SVG document contains the following: <!-- child.svg --> <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> Web Integration Compound Documents (WICD Core) review Commenting on http://www.w3.org/TR/2005/WD-WICD-20051219/ 3.2.1 Why would you not allow for a link to be activate 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. 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. 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 travers the overlay and come back? What semantics in the DOM indicate an overlay or a real active document? 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. 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. 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? 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. 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. 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 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. 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. 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 CDF should require the user agent who is implementing this to configure the rate of animation. 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 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 <quote cite="http://www.w3.org/2006/01/25-pf-irc#T14-43-18 "> 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. 1.1 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? Second bullet: this includes user system settings. Correct? Third bullet: would like to add “and needs” after “personality” </uawg> 3. Scalable Child Elements 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> 6.1 Focusable Child Elements 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> 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 <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> 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? 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. 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. 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/>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/>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/>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 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. Rich Schwerdtfeger Distinguished Engineer, SWG Accessibility Architect/Strategist Emerging Technologies Chair, IBM Accessibility Architecture Review Board blog: <http://www-106.ibm.com/developerworks/blogs/dw_blog.jspa?blog=441>http://www-106.ibm.com/developerworks/blogs/dw_blog.jspa?blog=441 schwer@us.ibm.com, Phone: 512-838-4593,T/L: 678-4593, mobile: 512-876-9689 "Two roads diverged in a wood, and I - I took the one less traveled by, and that has made all the difference.", Frost
Received on Friday, 27 January 2006 19:36:32 UTC