- From: Ian B. Jacobs <ij@w3.org>
- Date: Mon, 04 Mar 2002 10:19:27 -0500
- To: wai-tech-comments@w3.org
[copy to file in public view. -Al] Al, Steven, I have some comments on the 18 Jan 2002 last call Working Draft of XForms 1.0 [1]. I realize that these comments have come in after the 22 Feb 2002 deadline. I read the specification with UAAG 1.0 requirements in mind, applying those requirements to XForms user agents. It would also be useful to conduct the inverse review: evaluate an XForms 1.0 user agent against the requirements of UAAG 1.0, many of which apply. This is the type of application of WAI Guidelines (here UAAG 1.0 only) that I hope all Working Groups will do as a natural part of building a Recommendation. This is a great time to get accessibility features into XForms user agents as they are not widely deployed. I don't expect XForms 1.0 to require that all XForms user agents conform to UAAG 1.0. However, it is possible for the XForms WG to import UAAG 1.0 requirements and make them part of XForms conformance. I have listed requirements below that jumped out at me, but there are other global requirements to consider (e.g., the user must be able to operate the user agent entirely via the keyboard, the user agent must provide an outline view, etc.). At the end of this email there are a couple of other comments about the specification, unrelated to accessibility. I have sent these comments to the PF WG rather than directly to the XForms WG as some of them may have already been made by the PF WG. Thank you for considering these comments. Please let me know if you have any questions. Feel free to make these comments public. - Ian [1] http://www.w3.org/TR/2002/WD-xforms-20020118 ================ The order of these comments is more or less in the order of XForms 1.0 sections 1) The following applies to any XForms user agent that implements a focus, i.e., where interaction is expected. Applications that print XForms would be exempt, for example. A conforming XForms 1.0 user agent must allow the user to move the (content) focus to every enabled and rendered form control. [The definition of "enabled" is that the control is capable of interaction in the current session.] (UAAG 9.3) A conforming XForms 1.0 user agent must allow the user to move focus in the order specified in section 4.3.2, both forward and reverse. (UAAG 9.3) A conforming XForms 1.0 user agent must allow the user to move the focus through the keyboard (UAAG 1.1). A conforming XForms 1.0 user agent must provide a focus highlight mechanism that: a) Doesn't rely on color alone. b) Is configurable. (UAAG 10.2) 2) Section 4.3.2, navigation point 3. There are times when XForms does distinguish clearly enough rendering and navigation. For instance, in section 6.1.4: "When false, associated form controls should be made unavailable, removed from the navigation order, and not allowed focus." I presume that: a) "Made unavailable" means "not rendered", and b) "And not allowed focus" should be deleted. In the UAAG 1.0, "navigation" only means "move the focus among a set of elements." That set can be one of: - The set of enabled elements only (checkpoint 9.7), or - The set of enabled elements, and possible some disabled elements (checkpoint 9.3). I believe that XForms 1.0 forbids the latter ("Those form controls that are disabled ... do not participate as navigable controls"). In UAAG 1.0, an "enabled element" is one where user interaction is possible in the current session. A "disabled element" is an element that could be enabled in some session, but is currently not enabled. Developers have told us that in some cases, navigation should include disabled as well as enabled elements, as this helps orient the user (e.g., when navigating links "A" to "Z", if some letters are not active, it is still useful to render the intermediate letters for orientation, and to allow focus on those letters with some indication that activation is not possible since those links are currently disabled. Summary: If we suppose that the set of navigable elements is the set of enabled elements only, then I suggest rewriting the above XForms sentence as: "When false, associated form controls should not be rendered, and should be disabled." If it's at all possible, I'd like XForms 1.0 to share the same meanings of "enabled element", "disabled element", and "focus" as UAAG 1.0. Also, though lower priority: Allow since user agents are likely to *render* disabled elements (for orientation purposes, like greying out menu items), allow them (but do not require them) to include these elements in the navigation order as well (i.e., allow the user to move focus to them). 3) 4.3.2 Navigation order point 4. If an XForms user agent allows navigation past the last or first enabled control, to conform the user agent must allow configuration to prompt the user that the end/beginning of the form has been reached. (UAAG 9.8, applied to this navigation mechanism). 4) 4.3.5bis. I propose a new event "valueComplete", to be dispatched when the user has completed certain form controls in a manner that conforms to the relevant schema constraints. The idea is that users should be given a clue that the data they have entered is sufficient to move to the next form. This may not be absolutely necessary because they will find out soon enough if they try to leave the form control and get an invalid message. But I think it will be easier on the users if they can receive subtle messages (e.g., someone with blindness could hear a beep that they have completed a form control "correctly") that would allow them to more fluidly go through a set of controls. This is better than a sequence of "Wrong!" messages. 5) 4.3.3 xforms:focus. UAAG 1.0 (checkpoint 9.5) requires that a user agent provide a configuration so that focus changes do not trigger focus events. This is to allow users to move around content and orient themselves (e.g., when using a screen reader) without causing any events to fire (which might change the state of the document). 6) 4.3.3 xforms:focus. Checkpoint 9.6 in UAAG 1.0 states: "For the element with content focus, make available the list of input device event handlers explicitly associated with the element." We'd like users to be able to navigate around the document and learn what their potential interactions will do. It would be great if XForms user agents made available "Caption" element values (as well as hint and help information) for focused elements. One could imagine an interface where, once the user has moved focus to an enabled form control, the user can ask for the associated caption (which might be rendered as a tooltip or in the status bar or even in context). This would allow the user to learn more about potential consequences before activating a form control. Comment: I note that there are no mouse-specific events in XForms 1.0. Conforming user agents used in environments with keyboards must allow users to trigger onActivate events through the keyboard (checkpoint 1.2). 7) 4.3.11 Help/Hint information. A conforming XForms user agent *must* render (in some viewport) help and hint information. Per UAAG 1.0 checkpoint 2.3, user agents must make available (in some viewport) conditional content (that is intended for people, as help and hints clearly are). I realize that xforms:help and xforms:hint are messages, but I don't think a conforming user agent should be allowed to not render this content that may be vital to users trying to understand the form, and that the author has made available. 8) 4.3.12 Alerts. I assume that some alerts will be predefined by the user agent (e.g., invalid form data). Is it possible for there to be author-specified alerts? For each user agent-specified alert, a conforming user agent must provide a text version of the alert. If it's possible for authors to specify alerts, then WCAG should tell them to provide a text version of each one. 9) 4.4.1 xforms:submit. A conforming XForms user agent must allow configuration to prompt the user to confirm (or cancel) any form submission. (UAAG 5.5). This is to ensure that users do not accidentally perform an unwanted transaction (e.g., when a form is submitted by a script, not activation of the submit button). UAAG 1.0 says: "Configuration is preferred, but it not required if forms can only ever be submitted on explicit user request." 10) 6.1.2 readOnly. I think there's an inconsistency between these two sentences: "The ability of form controls to have focus and appear in the navigation order is unaffected by this constraint." "This specification does not define any effect on visibility, focus, or navigation order." The first sentence does define an effect. I think that the second sentence should stay, and should be rewritten as: "The user agent may change the rendering of an element or disable it based on the readOnly constraint, but is not required to." [I doubt that the actual navigation *order* would change, but the element might either be included in or excluded from the set of navigable elements.] Last comment: "When evaluating to true, ....should not allow any changes...". Shouldn't this be "must not"? If it's really should then, perhaps change the constraint name to "readOnlyHint" or something softer than "readOnly", otherwise the author might have the wrong expectations. 11) 6.1.6 "The XForms user interface may indicate the validity of a form control." A conforming XForms user agent that indicates validity through a GUI must do so in a way that does not rely on text foreground/background color alone. (UAAG 10.4 extended to XForms). See also sections such as 4.3.15, that say "All form controls show the validity state...". For rendering requirements such as these, please ensure that a conforming user agent (with a GUI) does not show state through color alone. 12) 7.4.2.5 cursor(). A conforming XForms user agent used in environments with keyboards must allow the user to position the cursor with the keyboard. Note: If XForms 1.0 states that a conforming user agent must allow the user to operate the user agent entirely with the keyboard (optional: "in environments with keyboards"), then this does not have to be repeated everywhere. (UAAG 1.1) Another comment: for GUIs, the cursor position should not be rendered in a way that relies on text foreground/background colors alone. (UAAG 10.3). I'm not sure whether this is really an issue for the usual curor (if we're talking about a text caret). 13) 8.2 secret. There is an acknowledged security issue here: "Don't render the actual value, render a substitute." However, there is also an accessibility issue: for users that rely on assistive technologies that will communicate via an API with the XForms user agent, this data must be available in original form through the API. I have recently encountered this issue with respect to UAAG 1.0's requirements, and I don't yet have a proposal on how to ensure that data can be sent through an API to a trusted assistive technology. I am likely to take this back to the UAWG. 14) 8.9, 8.10. Is is possible for authors to write forms that may be submitted without explicit user consent via scripts? It's common today for authors to write HTML forms that are script driven, so that when the user selects an option from a select box, the form is submitted automatically. For users that navigate serially through selection options, this means that they may not be able to reach any options after the first (since the form is immediately submitted). Is this sort of behavior possible with XForms 1.0? If not, there's no problem. If so: - Please tell authors not to do this. - See point (9) above, which includes a requirement to require confirmation of any form submission. This will help, but is not perfect. The user may have to turn off scripts, but that's also a big hammer. It's perhaps worth discussing how to allow a user to continue to navigate a form, with scripts enabled (e.g., for calculations) but without automatic submission. 15) 8.5 upload. There is a general security issue here: I don't think that it should be possible to upload files using hidden controls. One idea would be to require an option in the UA to prompt the user to confirm that they want to upload the file. In this case, the prompt must include a text message. 16) 8.12.4.4 alert. Does this element allow a caption element? If so, that would allow authors to provide text versions for graphical or audio alerts (if non-text alerts are indeed possible). 17) 9.1 group. In the last sentence: "in the focus being set to the first form control in the tabbing order within that group." This may be "first enabled element" in case the first one is disabled. [Again, I'm assuming a model where there is a set of elements that may be navigated and an well-defined order for navigating them.] 18) 10.6 loadURI. The "new" value opens a new window. Per UAAG 1.0 checkpoint 5.3, a conforming XForms user agent must "allow configuration so that viewports only open on explicit user request", otherwise users with some disabilities may be disoriented. In short, checkpoint 5.3 requires manual opening (e.g., on confirmation) rather than automatic opening. Checkpoint 5.1 says "Allow configuration so that if a viewport opens without explicit user request, its content focus does not automatically become the current focus." This would also be relevant here - don't always move the focus to the new viewport. See Guideline 5 for more information. -------------------------- Other comments on the spec -------------------------- 3.8.1 "An XForms processor is not required to implement full XLink ... is sufficient." Please rewrite as: "An XForms processor must implement xlink:href. An XForms processor should/may implement the other parts of XLink." But the problem with this type of picking and choosing is that it may be difficult for an implementer to know exactly what it means to implement xlink:href only. 4.2.3 xforms:initializeDone. "Default processing for this event results in the following:" is followed by nothing. Seems like something is missing. 4.2.5: xforms:formControlInitialize "...and for each form control..." I wasn't sure where to find the definitive list of form controls. Is it only those defined in Chapter 8? Also, there is a "name" attribute in the paragraph and I don't know what it refers to: "..by using the binding expression from the user interface control as the 'name'." 4.3.2 xforms:next/xforms:previous. The term "default navigation order" is used. Please define this clearly. Or, is this "the navigation order per the algorithm below"? In point 1.b, the term "Ancestor" is used. Would "Parent" be more precise? Is it really any ancestor? 4.3.6 xforms:valueChanged What is the ordering of this event in relation to onblur? Is that order important? 4.3.17 xforms: recalculate In the second paragraph about default processing: "The XPath expression may reference or refer to another instance node..." I suggest removing one, or indicating their equality more clearly, as in "may "reference" (or, "refer to")" 6.4.2 Rules for binding expressions "Upon detecting a binding expression that violates any of the above constraints, form processing terminates with a fatal error." Please restate using "must" as: "Upon detecting a binding expression that violates any of the above constraints, a conforming XForms processor must terminate processing with a fatal error." 9.3.1 Repeat processing In point three, the term "head of the collection" is used. Is "first" more accurate than "head"? -- Ian Jacobs (ij@w3.org) http://www.w3.org/People/Jacobs Tel: +1 718 260-9447
Received on Monday, 4 March 2002 10:19:31 UTC