1.3 Leveraging XForms Accessibility Features

This section details how various aspects of the XForms architecture can be leveraged in meeting the accessibility design principles covered in Section  1.2.

1.3.1 XForms Creates Accessible Content

The separation of model from view that is inherent in the XForms architecture is a key enabler with respect to creating accessible content. In addition, all XForms controls and user interface constructs have been designed to encapsulate relevant metadata such as label, help and hint — see Section  ??. XForms user interface controls encourage platform-independent eventing and support consistent keyboard navigation — see Section  ?? for a description of attributes accesskey and navindex.

The XForms vocabulary has been designed to encourage intent-based authoring and provides the constructs needed to express the logical grouping of user interface elements. Constructs group and switch create user interfaces that can be easily refactored — see Section  ?? and Section  ??. In conjunction with model property relevant and the resulting ability to create conditional interaction, this enables the creation of user interfaces that reveal themselves progressively during user interaction.

1.3.2 Accessibility In Style

CSS plays a key role in creating accessible XForms user interfaces. HTML 4 failed to encapsulate key items of metadata as part of its user interface markup because visual designers relied exclusively on tables to correctly position user interface controls with respect to their labels. For the XForms design of encapsulating such metadata within each user interface control to gain wide-spread adoption, Web designers need to be assured of being able to style user interfaces created using the XForms vocabulary to the same degree as when using explicit HTML tables. A new CSS feature — CSS pseudo-elements — is a key enabler in styling XForms controls — see CSS3 UI for the complete details. Using this feature, style-sheet authors can specify that user interface controls and their labels should be displayed as if they were authored using an HTML table.

We demonstrate this use in Figure  1.3. This feature of CSS is named pseudo-elements because the style sheet author is able to refer to pseudo nodes in the markup tree. As an example, consider The markup tree for control input that collects the user’s email address is shown in Figure  1.1 and the corresponding CSS fragment shown in Figure  1.3. Conceptually, the presentation of this input control has two distinct visual components, the presentation of the edit field and the associated label.

input label help hint

Figure 1.1: Markup tree corresponding to control input.

However, examining the markup tree shown in Figure  1.1, we see that there is no explicit node that corresponds to the value in the edit field itself. In the absence of CSS pseudo-elements, a style-sheet author would not be able to attach a visual presentation to the value in the edit field that is distinct from the presentation style used for the rest of the input control.

CSS pseudo-elements enable the style-sheet author to refer to pseudo nodes in the markup tree. The set of pre-defined pseudo-elements is shown in Table  1.1; like the CSS pseudo-classes described in Section  ??, CSS pseudo-elements provide the necessary place-holders in the markup tree needed by the style-sheet to attach the appropriate presentation rules. The syntax used to refer to such pseudo-elements in the style-sheet is :: and parallels that used for referring to pseudo-classes covered in Section  ??.

We show the markup tree augmented with the pseudo element for the edit field in Figure  1.2. The CSS style rules shown in Figure  1.3 use these pseudo-elements to align the labels and their associated controls.

input label ::value help hint

Figure 1.2: Pseudo markup tree corresponding to control input.

<html xmlns="http://www.w3.org/1999/xhtml"
  <head><title>Email With Style</title>
    <style type="text/css">
      @namespace xf
      /⋆This causes form controls and their labels
      to align, as if a two-column table were used ⋆/
      xf}group { display: table; }
      xf}input { display: table-row; }
      xf}input>xf}label {
      display: table-cell; }
      xf}input::value {
      border: thin black solid;
      display: table-cell; }
      /⋆ Display repeat-items with a dashed border ⋆/
      ⋆::repeat-item { border: dashed; }
      /⋆Current item gets  a teal highlight⋆/
      ⋆::repeat-index { background-color: teal;}
    <group xmlns="http://www.w3.org/2002/xforms">
      <input ref="email"><label>Email</label>
        <help>Enter your email address</help>

Figure 1.3: Aligning user interface controls and their labels using CSS.

This is achieved by specifying that:

element group should be treated as a table for display purposes,
Element input should be treated as a conceptual row of this table,
Pseudo-element ::value for control input be treated as a cell in this table row,
Element label be treated as another cell in the table row.

The result is to achieve the same visual effect as when using HTML tables; however the content markup remains independent of layout constructs.




Represents the active area of a user interface control excluding its label.


Represents a single item from a repeating sequence.


Represents the current item of a repeating sequence.

Table 1.1: CSS 3 pseudo-elements for styling XForms user interfaces.

1.3.3 Accessibility Through Eventing

The accessibility design principles outlined in the previous section can be classified as pertaining to content, presentation or interaction. All of the interaction related design principles are met by XForms’ use of XML Events as summarized in Table  1.2.


XForms Solution

  • Defines a set of high-level interaction events.
  • Exposes processing model through eventing.

  • User interface controls define consistent behavior.
  • Centralized event handling through XML Events.
  • Navigation sequence is well-defined.

Late Binding
  • XML Events enables attaching of new handlers.
  • Declarative handlers enable augmentative behaviors.

  • Defines notification events for all key state changes.

  • Processing model exposed through events.
  • Custom hooks at key points in the interaction.

  • Defines declarative handlers for all common operations.

Table 1.2: XForms eventing enhances accessibility.

1.3.4 User Agent Guidelines For Leveraging XForms Accessibility

User agents that implement XForms play a key role in ensuring that the accessibility features present in the XForms design benefit the end-user. XForms user agents can provide direct support for accessibility; as an example, XForms user agents can directly augment the end-user experience by providing spoken feedback during user interaction. Implementing such spoken feedback is relatively straight-forward given a fully compliant XForms client. Since the XForms processing model and the underlying eventing framework expose all the needed hooks, augmenting the interface with custom behaviors that match a user’s special needs only requires authoring event handlers and attaching them at the right points within the XForms client.

XForms user agents that do not directly implement such augmented behavior should expose all aspects of the XForms processing model and eventing framework. This is essential to enable the creation of add-ons that augment an XForms browser with the specific behaviors needed by a particular user community.

1.3.5 Accessing XForms Features From Adaptive Technologies

When an XForms client does not directly implement the desired specialized behavior, it may be necessary to extend the client with an appropriate piece of adaptive technology. Such adaptive technologies will need to implement the DOM2 eventing framework and be capable of hooking into Web browsers that are fully DOM2 events compliant.

XForms content can also be augmented with special behaviors before the content is delivered to the client. Such server-side augmentation is likely to be a rich area of future investigation as we try to develop accessibility solutions that are usable on a variety of non-desktop information appliances.