WebForms 2.0 assessment (March 9 working draft)

While this is not a W3C specification, I reviewed the WebForms spec. on my
flight back from New York for my own edification. ... pretty easy read. The
specification refers to a tie in with XForms on the server with Web Forms
on the client as a possible implementation of forms. WebForms is focused at
HTML and XHTML 1.0 content. XForms is applicable to a broader set of XML-
based UI frameworks.

Al, if you think this needs to be copied to wai-xtech please feel free to
send it out.

link: http://www.hixie.ch/specs/html/forms/web-forms-3

Executive summary:

Although not as fully functional, WebForms is a much simpler implementation
than XForms and in actual fact will be easier for assistive technologies to
provide support for if some holes are addressed. WebForms introduces input
field typing and declared functions for validate reducing the need for
JavaScript. It also introduces input types to help with validation while
avoiding the use of XML Schema as a means for strong data typing. That
said, there are a number of features which will need to be added to support
accessibility. Some of these features they should have borrowed from
XForms. In short, WebForms does not provide for full accessible but could
with some work.

1. Include hint, description from XForms. The use of hints from XForms
would greatly help with things like input patterns. For example, a custom
input pattern may require a sequence of for numeric numbers followed by for
alphanumerics. This information could be easily described to the assistive
technology without the need for creating a custom parser.

2. WebForms introduces an output form element used to render things like
formulas as the user types into an input form. Assistive technologies are
designed to operate on elements with focus (input elements) and need to be
notified if another elements value is being changed. WebForms needs to add
a value change event for output elements and also provide a semantic
relationship indicating that one or more input elements controls an output
element. This information is often readily understandable by a sited user.

3. WebForms introduces an input upload capability by referencing a file.
There should be a tie in to UAAG which requires the user agent to generate
an accessible dialog box for content uploads that fail and why. This is
fairly obvious but I thought it worth mentioning as part of their spec.

4. Need an invalid attribute set on form elements whose values are invalid
as a result of a validation. This should be set by the user agent upon
validation and the information should be made available through the UAAG
guidelines to the assistive technology as part of the properties or states
set on an form element. The reason for this is that impaired users may not
be able to see all invalid content. This would allow an assistive
technology to route the user to each invalid UI component. I would also
consider this feature (jumping to invalid form elements) being a standard
feature for UAAG. Since Form elements are free form (not necessarily
enclosed in form tags like XForms) the user will have to select which form
they are processing to handle the navigation through the appropriate
invalid elements.

5. Consider having spans and DIVs associated with form elements through
DHTML roadmap. ... simply trigger off state information. The alternative
will be for these custom widget's event handlers to set hidden data in a
form for submittal.

6. Consider using the Group tag from XForms. This is like FieldSet, but
they need to be explicit.  ... If not group what is the alternative? ... It
is not clear in the document.

7. WebForms introduces a template attribute and a repeat tag for the
purposes of defining things like duplicate table row templates. Templates
should have a description associated with them. Repeats should be reflected
in the DOM as the actual instantiates of the templates for purposes of
interoperability with assistive technologies.

8. WebForms introduces add, remove, moveup, and movedown input types. The
purpose of these are to dynamically change the number of instantiated
templates or move the number of instantiated templates. The execution of
these input types should result in a change in the DOM to reflect the
instantiated DOM elements to support interoperability. Additionally, the
user should be notified of these changes. Notification should be include
the action (add, remove, moveup, and movedown) and include the templates
description. Reason, like the output field change, these operations occur
outside the focused element the user is working on. A sited user can have
access to this information by a user with limited vision, or a learning
impairment would be assisted by having audio feedback accompanying the
change. For those with hearing impairments and low vision we should
consider a user agent requirement to flash the information on a user agent
status line.

9. Form elements should have a labelled by and memberof (for groups)
methods for those form elements that apply. While the page author may set
the id on the label for the input element it is labeling, users who are
blind operate on the elements which receive focus or to which events are
generate. These elements are largely static and do not generate events.
Therefore a screen reader technology will read the information related to
an events target and at that point might additionally include the label or
group information to the user. I will note that this capability *should
have* been in the original forms specification for HTML as well as the
XForms specification. The Java Accessibility API provides this information
through relationship enumeration, so there is precedence for this.

Cheers,

Rich


Rich Schwerdtfeger
STSM, Software Group Accessibility Strategist/Master Inventor
Emerging Internet Technologies
Chair, IBM Accessibility Architecture Review  Board
schwer@us.ibm.com, Phone: 512-838-4593,T/L: 678-4593

"Two roads diverged in a wood, and I -
I took the one less traveled by, and that has made all the difference.",
Frost