- 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