This section details how various aspects of the XForms architecture can be leveraged in meeting the accessibility design principles covered in Section 1.2.
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.
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.
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〉
|
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.
|
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.
|
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.
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.