User Needs and Preferences Profiles

Universal design alone has been shown inadequate to cater for the needs and preferences of all users, even when the principles embodied in the Web Content Accessibility Guidelines [WCAG-1] specifications are complied with. This situation has led to interest in the complementary approach suggested by the Adaptive Technology Resource Center [ATRC] at the University of Toronto . They have a prototype system operating that matches resource components to user-determined requirements (The Inclusive Learning Exchange [TILE]). When this work was shared with those at the IMS Global Learning Consortium [IMS GLC], the author was working with the IMS Global Learning Consortium for IMS Australia (funded by the Australian Department of Education, Science and Technology). The first IMS Accessibility task was a set of guidelines for educators about accessibility (Barstow and Rothberg, 2002). These were developed at about the same time as the author's Accessible Content Development section (Appendix 8), but recent research had already shown the inadequacy of the then current work (Chapter 4). The author considered that the adoption of a complementary approach that would take into account the needs and preferences of individual users might make a difference.

In fact, the AccessForAll approach was a significant development and only the beginning of a chain of developments that has most recently led to the Fluid Project, a major user-interface architecture re-design project directed from the ATRC.

The first part of this chapter is in a published paper for the 2005 Dublin Core Conference (Nevile, 2005b). It presents the case for a private (anonymous) personal profile of accessibility needs and preferences expressed in a Dublin Core format. It introduces the idea that this profile, identified only by a URI, is motivated by a desired relationship between a user and a resource or service. It assumes a new Dublin Core term DC:Accessibility and argues that, without any reference to disabilities, personal needs and preferences, including those symptomatic of common physical and cognitive disabilities, context or location, can be described in a common vocabulary to be matched by resource and service capabilities.

Individual differences

As explained earlier (Chapter 3), everyone, at some time or another, is disabled by the circumstances in which they find themselves and most people, as they age, will experience disabilities more often. Most people will find their disabilities vary according to the circumstances in which they are operating. Disability, in this sense, is a description of a poor relationship between a person and their immediate operational requirements.

Similarly, it is inappropriate and inaccurate to attribute descriptions of disabilities, which are descriptions of relationships, to named people. At the same time, it is efficient to recognize that many relationships are similar and that when involved in a user-resource relationship, many people will want to use the same description of that functional relationship. For instance, many blind people trying to access a Web page with images will want to use similar profiles of non-visual functional relationships between a user and a resource.

The existence of a machine-readable profile of a enabling relationship can be used, by computer applications, to match users with resources and services they can use. This process involves a description of a user's immediate needs and preferences being matched with a description of the components of a resource or service. This may mean iterative testing of the relationship and alteration of resource components until there is no disability. It may involve the replacement, augmentation or transformation of components of the resource or service, such as changes of sensory modality. The user's descriptions of their needs and preferences, often called their profiles, will be used according to the context or circumstances and may differ according to the occasion. For convenience, a user will want to store and refer to such profiles rather than to create them afresh every time one is required. In some cases, they will depend upon profiles created for them by others and, in such cases, may be especially dependent on their being stored and available at all times.

Accessibility profiles

An accessibility profile for use by a blind person attempting to read a newspaper online will be very similar to that for a person driving a car wanting to access Google News via wireless Internet: both users will want vision-free access to the resource. Both users will need alternatives to visual content contained in the primary resource they seek and both will want to control their access to that resource using non-visual techniques. It is unlikely that either of them will want to see the 'Google ads' that would normally accompany the content on a screen presentation. A simple description of the relationship with the resource they seek will be non-visual. The description of the characteristics of this relationship, the user's needs and preferences profile, should be simply expressed in machine-readable form and available to any resource publisher. It can be identified by its URI and does not need to contain any information about any individual or community of people. It is, in fact, a description of functional requirements and could be known simply as non-visual functional profile "x", or named 'home-upstairs' to make it clear that it is the profile for use in a particular context.

A more complicated example occurs where, for whatever reason, there is a need for a visual relationship but the objects being viewed need to be larger than they might be when used on a stand-alone desktop computer. Such a case occurs frequently when resources are displayed on a large screen before a large audience and the presenter is not experienced enough to know that only very large font can be viewed this way. For this to be an accessible relationship, it does not need to be non-visual but there are some necessary qualifications of the visual qualities: the text and images need to be enlarged. Exactly how large the text should be will usually be decided by the author in a situation where the details of the relationship are well-known, as for the large audience, but should always be available for customisation where individuals may have special needs.

Flexibility of the kind anticipated by AccessForAll means there needs to be a common way of describing the range of sizes of text and images so that the correct accessible relationship can be indicated by the user. The author should not attempt to determine what the user will want, but instead allow for the user to choose. Responses to the description of the relationship in such a case may depend upon the transformability of the resource components. Images expressed in scalar vector format, for instance, will be easily transformed to suit such requirements. Text that is to be presented according to cascading styles should also be suitably transformable but, if it contains tables, there will be more complicated considerations.

In some cases, it is not a transformation of available components that is required so much as their replacement or augmentation. Such a case exists where a non-auditory relationship is required with, for example, a movie. Then, a text transcription of the background sounds might need to be supplied with captions for all speech. These may all need to be synchronized with the visual content. Where the only problem with the aural content is likely to be the choice of language, captions might be required but the background sounds will not be a problem.

Accessible resources and services

The provision of resources and services that ensure the correct accessible relationship for a user depends upon the existence of many components all with special accessibility characteristics. Captions for films are usually made by organizations known as caption houses: caption houses specialize in making captions but not films. Signing for people who use sign languages is usually done by specialists in that field; videos of signing that might be needed to complete an accessible relationship are likely to come from a source other than the original publisher of the resource.

In other words, the components that may be required to complete an accessible relationship with a resource or service are often distributed and may be the result of cumulative authoring. All that is necessary is that the components are available just-in-time for delivery to the user. Very often, as is obvious from the examples already given, they may be combined in different ways for different user/resource relationships. This means it is most convenient to not fix them to a particular relationship with any one resource, but to maintain them separately and make available the necessary metadata for them to be discovered and fetched when needed. The same metadata can be used to identify a need for more components in anticipation of a demand for them.

The definition of accessibility implied here is that the relationship between the user and the resource is one that enables the user to make sensory and cognitive contact with the content of the resource. This is expected to occur at the time of accessing the resource or, in other words, to be achieved just-in-time. This is the ISO/IEC AccessForAll definition of accessibility [ISO/IEC 24751-1:2008].

In addition to the availability of the necessary components to satisfy the relationship required by the user, there is a requirement for the metadata that will be used to arrange the final composition of the resource. There is also, of course, a need for a way of communicating the requirements, or the metadata. The vocabularies and common specifications for their description are the topic of this chapter. W3C was working on similar issues in several of their working groups including Device Independence, Protocols and Formats, Ubiquitous ??? W3C's first product in the field were the Composite Capabilities and Personal Preferences specifications [CC/PP].

Relationship Descriptions

Organising the possibilities for resource relationship descriptions means ensuring that the characteristics are uniquely described. Such organisation is common but can take some time to determine. Fortunately, the Adaptive Resource Technology Center [ATRC] has been requesting needs and preferences for people with disabilities for some time and, based on their research, were able to advise on how to 'divide up' the characteristics for user needs and preferences profiles.

There are three commonly known sensory modalities relevant to the current human-computer relationship: visual, auditory and tactile. Smell (olfactory) and haptic modalities are only just emerging. There are many possible variations of the modalities and their roles can be important: auditory input and output are not necessarily related to a user rather than their context. In a library, one may be able to listen with headphones but asked not to use voice input; in a car, general auditory output may be acceptable and voice input may be essential. While input and output are useful distinctions to make, in some cases, in the case of accessibility, the ATRC uses three classes: display, control, and content characteristics [TILE]. As determining these characteristics is not within the scope of the current research, the advice of the ATRC was willingly adopted.

For people who use adaptive technologies with special settings, describing their control needs and preferences may mean providing information about the settings for their personal adaptive technology, especially when that requires something like an on-screen keyboard to be activated by a head-pointer. In the case of an on-screen keyboard, the display characteristics of the resource also need to be adapted to allow for the loss of screen space for display purposes. In addition, there may be requirements for other display characteristics, and there may be separate needs for content adjustment. Particularly for users for whom settings are crucial to their engagement with resources, needs and preferences need to be distinguished. If a need cannot be fulfilled, their preference for what to compromise can make all the difference. For others, if flexibility is possible, it can mean greater satisfaction. For accessibility reasons, it is essential that the user's profile always overrides all other profiles, as is the case with cascading style sheets (W3C, 1999).

As the requirements can conflict in combination, determining a structure for their representation that allows for them to be described fully and unambiguously is essential. For this reason, descriptions of needs and preferences for display, control and content characteristics need to be separated. The needs and preferences need to be easily describable, so it is essential that if there are no special needs, nothing needs to be described, but that when there is a need, there is a check-list of details that are easily understood and recorded.

In addition to the three categories of resource characteristics and their details as described, there is an over-riding quality that is essential in the human-computer context. Usability is not a technical quality but it can be the most significant quality when user resource interactions are required. It is not included as a technical characteristic of AccessForAll but it should always be considered (DRC, 2004). Figure 47 shows the classes of characteristics proposed by the ATRC for AccessForAll for digital resources.

Display descriptions

Where there can be no effective visual relationship with resources and services, all visual displays need to be presented in some other modality. Often the choice is for auditory presentation of the visual content but it may be for tactile displays such as Braille or other tactile forms. Where the adaptive technology does not change the modality but changes the characteristics of the display, as in the case where screen-enhancing software is being used, the requirements for the desired display may involve object sizes, colour, or placement on the screen. The requirements can be very detailed and vary depending on the circumstances. Changes in the modality of content, as occur when a screen reader renders visual content (text) as auditory content, may depend upon it being possible to transform the content in this way. This in turn will depend upon the form of the original content: it can be transformed easily unless there is formatting, for example, that interferes with the process. The ‘transformability' of the text will need to be described if it is relevant to the user's relationship with the text.

Tables 5, 6 and 7 show the potential characteristics (attributes), how many there may be and what kind of values are expected.

Attribute	Allowed Occurrences	Datatype
screen reader preference set	Zero or one per Display Preference Set	Screen_Reader_Preference_Set
screen enhancement preference set	Zero or one per Display Preference Set	Screen_Enhancement_Preference_Set
etc	etc	etc

Table 5: 6.2.1 Display Preference Set (Treviranus et al, 2005)

usage	Zero or one per Screen Reader Preference Set	Usage_Vocabulary
screen reader generic preference set	Zero or one per Screen Reader Preference Set	Screen_Reader_Generic_Preference_Set
application preference set	Zero or one per Screen Reader Preference Set	Application_Preference_Set

Table 6: 6.2.2 Screen reader Preference Set (Treviranus et al, 2005)

font face preference set	Zero or one per Screen Enhancement Generic Preference Set	Font_Face
font size preference	Zero or one per Screen Enhancement Generic Preference Set	Positive integer
foreground color preference	Zero or one per Screen Enhancement Generic Preference Set	Color
background color preference	Zero or one per Screen Enhancement Generic Preference Set	Color
etc	etc	Etc….

Table 7: 6.2.9 Screen Enhancement Generic Preference Set (Treviranus et al, 2005)

Control descriptions

Not all users control their systems using the typical mouse and keyboard combination. In some cases, they use assistive technologies that effectively replace these devices without any adjustment but in others they use technologies that require special configuration. An on-screen keyboard will use screen space that will have to be denied to the resource or service. Any resource or service that cannot accommodate this loss of screen space, for example because it demands a full-screen display for all controls to be available, will probably not be suitable for use in all circumstances.

It is necessary to be able to capture what is necessary with proprietary devices and systems as well as what is generic to types of systems and devices. It is also necessary to be aware of possible developments so there is room for extensions. A typical example of the definition of these needs in an ISO/IEC standard is as shown:

Hundreds of such definitions are represented in a structured hierarchy so that it is easy for users or their assistants to provide only as much detail as is necessary. Nevertheless, due to the complexity of dealing with the multitude of possible needs, the vocabulary is very large and deeply hierarchical.

Content descriptions

According to the definition in this thesis of accessibility, the relationship between a user and a resource or service will also be accessible only if the content is perceptible by the user. Perception in this sense includes the case where a dyslexic person needs more than the usual image-based content because they cannot process a text-heavy resource; or where a person with neurological damage, such as a stroke victim, can not manage a screen that is too ‘busy', or where a blind person is working with an explanation that is based on an example that is useful only to people with vision. It is often the case that the original content has to be supplemented, perhaps with the availability of a dictionary or captions, or replaced by different content that achieves the same outcome but in a different way. Information about the resource that indicates that it contains such alternative content, or the location of such content that is available externally, is needed to determine if the user will be able to form an accessible relationship with it in terms of perception.

Metadata models

The original IMS GLC approach was to add the AccessForAll element into the established hierarchy of the IMS Learning Resource Meta-Data Information Model Version 1.2.1 Final Specification (2001).

Whereas the DCMI metadata model provides several ways in which a DC metadata set can be extended whenever necessary, the LOM requires the extensions to be determined in advance:

Not only is the model hierarchical (see Figure 48) but the thinking was. If one has thought for a long time with a particular model, and is obliged to implement systems in a hierarchical environment, it is very difficult to think otherwise. This problem was acute for some time within the AfA metadata team and it caused very lively discussion as the participants struggled to make the AfA work as interoperable as possible, trying to accommodate both the hierarchical LOM model and the 'flat' DC model. This challenge caused extra effort but in the end, the AfA Team agreed upon an elegant solution. There is considerable confidence that in the end it can, indeed, be implemented in both LOM and DC without loss, even if this does depend on a cross-walk from one to the other.

Profiles of user needs and preferences

User needs and preference profiles are designed to save a user from having to work their way through a new set of preferences every time they engage with a new computer. The profiles only help in this way if they can be stored and available when they are needed.

Web-4-All uses a smart card to provide a portable set of user needs and preferences for adaptive devices and software available within a device. These cards were designed to make it easy for users of computers distributed throughout Canada and for those managing the computers. The computers are fitted with suitable adaptive technology and a card reader. By inserting or extracting the cards, users can set up the computers, use them, and then leave them in a basic state for other users, without the need for a technician.

The paper presented at the 2005 Dublin Core conference argued that if the resource or service's capacity to adapt to different user needs and preferences is described in a Dublin Core element, the individual user's needs and preferences also should be described in Dublin Core format (Nevile, 2005b). It proposed a resource that contains information about a user's needs and preferences; what in some contexts is being called the user's Personal Needs and Preferences (PNP) and a metadata record of that resource. Figure 49 shows an early (and naive) representation of how the PNP characteristics might be combined with the resource discovery characteristics in a search for a resource.

It reiterated the argument that in order to match a resource or service to a user to achieve accessibility, there is no need to identify the user. All that is required is machine-readable information about their needs and preferences.

The need for this paper lay in the fact that the accepted use of DC metadata was to describe objects and description of people have been resisted for some time by the DCMI Usage Board. Previous attempts to encourage the DCMI to extend their way of working to include descriptions of people (Nevile & Lissonnet, 2004), even though that was often practised, were still being resisted. It was later discovered that this was because the person is usually not the resource that is being described, but the author of it, and so descriptions of the person are not really properties of the resource. In some cases, however, it has been of interest to describe people using DC style metadata, for example where an organisation uses software that manages DC metadata and so could be used to manage metadata about the people in the organisation as well.

In the case of the AccessForAll situation, the person is not being described, deliberately. In fact, the description is a profile of their functional needs and preferences relative to a context. This was, at the time, very contentious, particularly as it was not well-understood by the author that there was the historic problem that was worrying the experts. It was also difficult because, as explained earlier, some of the decisions made in the formation of the initial set of DC terms were made in the knowledge that they could lead to difficulties later on, and this was a typical case of what could highlight the problems with the early DC models. In addition, of course, there were potential problems with the model being used at the time for the semantics of the user needs and preferences profiles that would raise the hierarchy vs flat metadata issues. (In the end, the DC model has moved more closely to that of the Semantic Web and there is less emphasis on this issue because it is no longer relevant in the way that it was.)

A shared profile

In general, the paper argued, a profile will be for a single person, sometimes from within a class of people, such as someone using the Jaws device with the default settings, for instance. The profile could cater for a combination of users, however, with a combination of needs and preferences, even asking for redundant components so that everyone in the group has what they need. It is very common for a person with a disability to be working with someone who has different needs. In fact, some users' needs include a person who can assist them. This may or may not mean they have special functional requirements for the resources they want to access.

When a system is to be used simultaneously by two users who point to different profiles, it may depend on the circumstances how this is to be handled. If they are to share a screen, their needs will have to be harmonized. If they are working on the same application but separately, as when two remote users share a chat session, their individual needs should be accommodated separately. When the two users are, for example, a corporate group for whom there is a corporate set of ‘needs and preferences' that conflict with the individual's essential needs and preferences, the latter should be matched in preference to the former.

Table 8 shows a typical set of user needs and preferences that might be used as a default set for some users with some specific values indicated.

Table 8: A typical set of user needs and preferences showing the default and the user's individual choices.

User needs as a resource

By rendering the user's needs and preferences profile as a resource, problems associated with the politically unpopular activity of labeling people by disabilities can be avoided. The technical problem that a single person will be associated with a number of AccessForAll profiles is also avoided as they can point at different times to any of a range of profiles. In addition, where there is a need for many users to share a profile, as with students in a lecture theatre, this is easily achieved. This approach was difficult to work within the DC rules for profiles but on a day in 2007 when it became very important to solve the problem if metadata was to be included in the forthcoming WCAG Version 2.0 [WCAG-2], the W3C POWDER Working Group was considering a similar problem, and released their first version of the POWDER protocol. The POWDER protocol provides a way for exchanging metadata about a resource but it also defines a collection of metadata as a resource, in that case establishing the useful term 'description resource' (W3C POWDER, 2008). This seems very appropriate.

A system working on the match, to ensure accessibility, will read the AccessForAll profile selected by the user (or user group) and use that information to test the metadata of potential components for the resource or service to be delivered. In the absence of an AccessForAll profile, systems will have to assume that a user has no special needs to constrain their relationship with resources and services at that time. In such a case, the user will have to determine the match themselves, somehow.

Accessibility Vocabularies

At this point it should be noted that while the user's PNP is described by a metadata record, it is itself metadata in another sense. The value of this is that it can be used in conjunction with resource metadata in the matching process for accessibility.

The vocabularies for the metadata to be associated with the resource or service and with the user's needs and preferences for accessibility have been carefully matched in the AccessForAll profiles. Other technical device information might also need to be conveyed to the resource server but it is expected to be covered by the work of the W3C Device Independence Working Group or others using such protocols the Composite Capabilities and Personal Preferences protocol [CC/PP].

For all preferences, usage is required to determine if the user must or must not have it or if they merely have a preference for the setting. Flashing content, for example, can be dangerous for some users and content with nothing but graphics will be useless to a blind person unless they have a friend available to describe it to them.

As the values of the descriptive elements are what is matched once the elements have been matched, it is important that there is a standard vocabulary available to be used for those values. This can occur several ways: a recommended form such as yyyy-mm-dd or mm--dd-yyyy, an encoding conformant to some set standard, such as Getty colour schemes, or what is called a controlled vocabulary - a set of words with definitions. All these rules need to be available to any matching software. It is very often possible to adopt existing standard vocabularies as has been done throughout the AccessForAll profiles. For example, developing a complex vocabulary for settings for dynamic Braille displays would seem inappropriate when there are already Braille systems that have such settings (ref???).

Chapter Summary

In this chapter, the redefinition of accessibility that assumes all people have accessibility needs, or alternatively that these are just part of the environment, suggests a way in which the three areas of concern to users of digital resources might record their needs and preferences: display, control and content. These classes of characteristics are briefly explained to show how they have been used in AccessForAll work. The idea of a description of a user's personal needs and preferences is new and has not yet been built into many systems (see Chapter 11). Nevertheless, it is considered one of the most significant contributions of the AccessForAll work because of its potential to support the automated matching of resources to user's individual needs and preferences. It is also important in that it does not distinguish user's with permanent disabilites in any way for other users with temporary disabilities. It therefore supports the United Nation's notions of inclusion.

In the next chapter, the metadata terms for describing the accessibility characteristics of resources that users might access are examined.

Chapter 8: User needs and preferences

Introduction