Personalization involves tailoring aspects of the user experience to meet the needs and preferences of the individual user. For example, having familiar terms and symbols is key to many users being able to use the web. However, what is familiar for one user may not be familiar to another, requiring them to learn new symbols. The challenge has been the ability to identify the types of content in a document that should be adapted to the preferred user experience. The introduction of standardized semantics allows web applications to customize the presentation of that content to one that is familiar to individuals based on their specific needs and preferences. This specification defines standard semantics to enable user driven personalization. For example, the association of user-preferred symbols with elements having those semantics. This ensures that users can quickly find familiar icons, for example, a help icon, within the context of user interface elements.

This document is an explanation for understanding how to use Personalization properties to personalize an accessible web site.

Introduction

The goals of this specification include:

This is a proposal for defining syntax for adaptable content such as: links, buttons, symbols, help and keyboard. The proposed syntax will start by using the data-* mechanism provided by HTML5.

Technology holds the promise of being extremely flexible and the design of many systems includes the expectation that users will be able to optimize their interaction experience according to their personal preferences or accessibility needs.

Why We Need Personalization

We need personalization because:

Some users need extra support. This can include:

To achieve this, we need standardized terms and supportive syntax. These can be linked to associated symbols, terms, translations and explanations. They are then provided to an individual based on personal preferences.

Use Cases

Requirements for Personalization Semantics [[personalization-semantics-requirements]] elaborates many use cases that further contextualize the above summary of user needs. These use cases form the basis of requirements for this technology.

Examples include:

Assuming an author can make it programmatically known that a button sends an email, and based on user preference settings:

In addition, the button could be identified as important and always rendered or rendered in an emphasized form.

Another use-case is the use of Symbols. Some users might have a severe speech and/or physical impairment and communicate using symbols, rather than written text, as part of an Augmentative and Alternative Communication (AAC) system. The use of symbols to represent words is their primary means of communication for both consuming and producing information.

Symbol users face a wide variety of barriers to accessing web content, but one of the main challenges is a lack of standard interoperability between different symbol-sets, or a mechanism for translating how a concept is represented in one symbol-set to how it may be represented in another symbol-set.

It should be noted that users who depend on symbols for daily communication needs often also struggle the most with mistranslations, as they have severe language disabilities. Inferring what was meant by using an incorrect symbol will not be achievable for many users. This rules out relying on machine learning until it is almost error free.

In another use-case, a user has dyscalculia and has difficulty understanding numbers. They struggle with understanding websites that use numbers to convey information. For this reason, the numeric information must also be provided in an alternative format that the user can understand.

It is important to note that people with dyscalculia are often very good with words, so long text can be better than short numbers.

Finally, consider someone with autistic spectrum disorder and with a learning disability. They may be a slow reader but find numbers clear and precise. They may go to the same website and find all the word and images unclear and the animations cause cognitive overload. They want the same information with more numbers and less words.

More examples can be found on https://github.com/w3c/personalization-semantics/wiki/Use-cases.

More information on persona and user needs can be found in https://www.w3.org/TR/coga-usable/.

Out of Scope

While the intention of this work is to introduce a new set of attributes to support Personalization, the following work items are out of scope:

We encourage a the development of these items and a list of implementations can be found on our wiki.

Technology Comparison Summary

The task force reviewed various vocabulary options before deciding upon the use of the data- HTML attribute syntax. The list of technologies included:

The details of our research and discussion is documented on the Comparison of ways to use vocabulary in content (https://github.com/w3c/personalization-semantics/wiki/Comparison-of-ways-to-use-vocabulary-in-content) and Prototypes with data dash(https://github.com/w3c/personalization-semantics/wiki/Prototypes-with-data-dash-*-(Take-2)) pages in our Wiki.

We presented some of these options at the TPAC 2018 Personalization Plenary Day presentation and provided a working example using the data- attribute to add personalization features. The data- solution was recommended by representatives of several working groups attending our presentation and discussions. See the Vocabulary Implementations section in the Expainer document (https://w3c.github.io/personalization-semantics/#vocabulary-implementations) for further details on the use of data- attributes.

Modules

This specification has been divided into modules.

Each module has use cases and vocabularies:

Vocabulary Structure

Personalization Semantics is made of a vocabulary of properties and their values. This generic structure makes it possible to apply Personalization Semantics in a variety of contexts by adapting how the vocabulary is instantiated. The Vocabulary Implementations section below describes current ways to use the vocabulary.

Properties

Properties are the main units of personalization types supported by the vocabulary. A given property supports a specific type of personalization. That property would only be used once on a given piece of content, but multiple different properties could be used on the same piece of content to address different needs.

Values

Values provide the specific personalization information for the property. The possible values for each property are elabrated in the definition of the property in the modules. Some properties require the value to come from a predefined list of possible values, others can accept arbitrary strings, and some may accept multiple values. The value may be one of the following types:

true/false
Value representing either true or false, with a default "false" value.
true/false/undefined
Value representing true or false, with a default "undefined" value indicating the state or property is not relevant.
ID reference
Reference to the ID of another element in the same document
ID reference list
A list of one or more ID references.
integer
A numerical value without a fractional component.
number
Any real numerical value.
string
Unconstrained value type.
token
One of a limited set of allowed values.
token list
A list of one or more tokens.
URI
A Uniform Resource Identifier as defined by RFC 3986 [[RFC3986]]. It may reference a separate document, or a content fragment identifier in a separate document, or a content fragment identifier within the same document.

Vocabulary Implementations

At the present stage of development, the Personalization Semantics vocabulary can be used in HTML content using data- attributes [[html5]]. Attributes in this form can be used in valid HTML to implement features recognized by browser extensions or other special processors. Personalization Semantics is using this approach to gain early implementation experience of the features in a way that is simple and likely to be accepted within the web ecosystem as an interim approach.

For this publication of Personalization Semantics, the task force has accepted the name and values of three attributes for the Content module:

Other properties in the vocabulary are not yet mature enough to suggest using them in production HTML with data- attributes. Examples of those properties in the modules are to facilitate review, not to suggest implementation. See the discussion Prototypes with data dash.

The HTML data- attribute syntax is not intended to be used for long-term wide-scale features. The task force is using this approach at the moment to gain implementation experience and demonstrate the usefulness of Personalization Semantics in practice. Content authors and user agent implementers should be aware that the recommended approach to use the vocubulary is expected to change, and structure their implemetation in a manner that will facilitate the transition to a new syntax.

Stakeholders

This document is useful for:

For early implementations of content we suggest including a link to an extension an implementation that can maximize the benefit for users.

Acknowledgements placeholder