W3C home > Mailing lists > Public > wai-tech-comments@w3.org > March 2002

Comments on XForms 1.0 pertaining to UAAG 1.0

From: Ian B. Jacobs <ij@w3.org>
Date: Mon, 04 Mar 2002 10:19:27 -0500
Message-Id: <200203041519.KAA535765@smtp2.mail.iamworld.net>
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

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

Thank you for considering these comments. Please let me know
if you have any questions. Feel free to make these comments

     - 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

       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

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

       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

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

12) 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

16) 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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:24:32 UTC