[Accessforall] Are common terms a flawed concept?

Christophe Strobbe strobbe at hdm-stuttgart.de
Tue Dec 3 12:59:05 EST 2013


During the preparatory work for the revision of ISO 24751, the move from a
closed set of preference terms to a open-ended set (to be maintained in a
Registry of Common Terms) led to a distinction between different
categories of terms:
(1) common term: name for a setting or preference that would apply across
many applications or devices and for which the name (unique ID), data
type, value space and definition are defined in the Registry. This type of
term should be stable and not change much (if at all). In the current
Cloud4all implementation, these terms belong in the namespace
(2) application-specific term: name for a setting or preference that
applies to a specific device or application, that has a name, data type
and value space that are determined by the device or application for which
the term was defined. This type of term represents settings that can only
be applied to other devices or applications after translation or
transformation because those other devices or applications use a different
name, a different data type, a different value space (or even a
combination of multiple settings) to represent the same thing. In the
current Cloud4all implementation, these terms belong in the namespace
(3) application-unique term: name for a setting or preference that applies
to a specific device or application, that has a name, data type and value
space that are determined by the device or application for which the term
was defined. This type of term only makes sense in the context of the
device or application for which it was defined; it cannot be translated to
anything else.

Common terms imply stability, for example, because each change in the
value range (or data type, description, ...) would necessitate changes to
transformers and other code that would affect all the implementations that
rely on it. Using a common term for an application's setting implies that
the values for that setting need to be just as stable as the value range
defined for that common term. As an application developer (our SP3
solutions), I think you would want the freedom to change your settings,
and therefore the freedom to change the (application-specific) terms when
improving your application. For example, if you develop an AT for colour
inversion on a desktop OS, you would not want to be prevented from adding
a new colour inversion scheme by relying on a common term for colour
inversion scheme that lists only x values (but not the ones you want to
add to the new version of your AT). If you develop an operating system and
you want to add more contrast themes, you don't want to be limited by a
fixed list of contrast themes defined for the corresponding common terms.
If you develop a screen reader that can announce capitals in certain ways
and you want to add a new way of announcing capitals, you don't want to be
limited by the options listed for the corresponding common term. There are
probably many settings where developers would want to avoid such
limitations and opt for application-specific terms instead of common
So I see two main reasons why application developers would prefer
application-specific terms over common terms:
(1) the flexibility to modify the definition of their settings as the need
arises, without being hampered by the stability of common terms;
(2) the settings they had implemented before GPII came into existence
differ from the definitions of the common terms and they don't want to
move to the common terms (for whatever reasons).

I can think of only a small number of settings where common terms make
sense, e.g.:
* Any terms that use language tags as their value range, since these tags
are determined by standards (currently IETF BCP 47). (Not every solution
supports the same languages but what they support would always be a subset
of these language tags.)
* A number of terms that express concepts from physics, such as pitch (in
Hertz), sound level (decibel), colour (e.g. for foreground and background
colours, expressed as RGBA, although there are other ways of defining
colours), ...
* A number of terms that are generic enough, e.g. speech rate expressed as
words per minute, possibly pointer speech expressed a meter per second,

However, how many settings really exist that are generic enough that
application developers can commit to them without limiting the changes
they can make to their applications later? The above list even ignores
that you often wouldn't want to present users with the values used for the
common terms, e.g. screen readers use a range for 1-100 for speech rate
that does not represent words per minute, but the common term "speech
rate" is currently (provisionally) expressed as words per minute. In such
cases, you would only use the common terms if the conversion from the
range in the UI to the range of the common term is done in the application
(so it can use the common term's range internally).

When we said in previous discussions (last year, during the AccessForAll
teleconferences) that there would probably by hundreds of common terms, we
were probably too optimistic. Based on the implementation experience so
far, I can't imagine more than a few dozen common terms (as a very
optimistic estimation), and I expect all other terms to be
application-specific. I don't know what the future of application-unique
terms will be, but I guess that application-specific terms without
mappings or transformations to common terms will be just as opaque to the
real-time framework as application-unique terms.

Moreover, the common terms are not needed by the statistical matchmaker
because its goal is to infer relationships between application-specific
settings. In other words, the common terms are a requirement for a
specific class of matchmakers that got promoted to a requirement at the
level of the real-time framework itself.

I see a future for common terms to be used in conditions and common terms
for operators inside conditions, but only a limited future for common
terms that describe concrete preferences. Perhaps "flawed concept" is an
overstatement but I currently think that common terms are much more
limited than we thought originally.

Best regards,

Christophe Strobbe

Christophe Strobbe
Akademischer Mitarbeiter
Adaptive User Interfaces Research Group
Hochschule der Medien
Nobelstraße 10
70569 Stuttgart
Tel. +49 711 8923 2749

More information about the Accessforall mailing list