XForms. XML Powered Web Forms with CD

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

11.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 3.2.1). XForms user interface controls encourage platform-independent eventing and support consistent keyboard navigation (see Section 3.2.1) 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 4.1 and Section 4.2). 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.

11.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 position user interface controls correctly 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 pseudoelements ”is a key enabler in styling XForms controls (see CSS3 UI ^[3] 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.

^[3] http://www.w3.org/tr/css3-ui

We demonstrate this use in Figure 11.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, the markup tree for control input that collects the user's e-mail address is shown in Figure 11.1, and the corresponding CSS fragments is shown in Figure 11.3. Conceptually, the presentation of this input control has two distinct visual components , the presentation of the edit field and the associated label.

Figure 11.3 Aligning user interface controls and their labels using CSS.

< html xmlns ="http://www.w3.org/1999/xhtml" xmlns:xf ="http://www.w3.org/2002/xforms"> < head >< title >Email With Style</ title > < style type ="text/css"> @namespace xf url(http://www.w3.org/2002/xforms); /*This causes form controls and their labels to align, as if a two-column table were used */ xfgroup { display: table; } xfinput { display: table-row; } xfinput>xflabel { display: table-cell; } xfinput::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;} </ style >...</ head > < body > < group xmlns ="http://www.w3.org/2002/xforms"> < input ref ="email">< label >Email</ label > < help >Enter your email address</ help > < hint >...</ hint ></ input > </ group ></ body ></ html >

However, examining the markup tree shown in Figure 11.1, we see that there is no explicit node that corresponds to the value in the edit field itself. In the absence of CSS pseudoelements, 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 pseudoelements enable the style sheet author to refer to pseudo nodes in the markup tree. The set of predefined pseudoelements is shown in Table 11.1. Like the CSS pseudoclasses described in Section 5.1.1, CSS pseudoelements 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 pseudoelements in the style-sheet is :: and parallels that used for referring to pseudoclasses covered in Section 5.1.1.

We show the markup tree augmented with the pseudoelement for the edit field in Figure 11.2. The CSS style rules shown in Figure 11.3 use these pseudoelements to align the labels and their associated controls.

This is achieved by specifying that

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

11.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 11.2.

Table 11.1. CSS3 Pseudoelements for Styling XForms User Interfaces

Table 11.2. XForms Eventing Enhances Accessibility

11.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 straightforward, 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.

11.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 nondesktop information appliances.