ISO/IEC 24751-4:2023

Information technology - Individualized adaptability and accessibility in e-learning, education and training - Part 4: "Access for all" framework for individualized accessibility and registry server application programming interface (API)

This document specifies an AfA concept registry service, in particular: - requirements on registries; - requirements on concept submissions; - a data format (in JSON) for the exchange of registry entries (AfA concept records) between registry servers; - a set of RESTful operations for AfA concept registry servers to allow for the manipulation of AfA concept registry entries by external clients other than server-internal web interfaces.

Titre manque — Partie 4: Titre manque

General Information

• Status: Published
• Publication Date: 02-Feb-2023
• ICS: 03.100.30 - Management of human resources
• ICS: 35.240.90 - IT applications in education
• Technical Committee: ISO/IEC JTC 1/SC 36 - Information technology for learning, education and training
• Drafting Committee: ISO/IEC JTC 1/SC 36/WG 7 - ITLET - Culture, language and individual needs
• Current Stage: 6060 - International Standard published
• Start Date: 03-Feb-2023
• Due Date: 20-Apr-2024
• Completion Date: 03-Feb-2023

Relations

• Revises: ISO/IEC TS 24751-4:2019 - Information technology for learning, education and training - AccessForAll framework for individualized accessibility - Part 4: Registry server API
• Effective Date: 01-Jan-2022

Overview

ISO/IEC 24751-4:2023 defines the Access for All (AfA) framework for individualized accessibility in e‑learning, education and training, and specifies an AfA concept registry service. The standard covers registry requirements, rules for concept submissions, a JSON data format for AfA concept records, and a RESTful API for creating, updating, deleting and retrieving AfA concept entries. AfA concepts represent machine‑readable descriptors (with globally unique identifiers) for user preferences, resources and context that enable adaptive and accessible digital experiences.

Key topics and technical requirements

• AfA concept registry: requirements on registry servers to store, publish and exchange AfA concept records reliably and consistently.
• Concept submissions: rules and constraints for submitting AfA concepts so entries are semantically valid and interoperable.
• JSON exchange format: a specified JSON mapping for AfA concept records to enable machine‑readable vocabularies and synchronization between servers.
• RESTful operations: a set of CRUD endpoints (CREATE, UPDATE, DELETE, GET single and GET list) for external clients and services to manipulate registry entries (see Clause 9).
• REST architecture details: request/response parameters, response codes, MIME type requirements and other operational rules (Clauses 8 and 9).
• Security and authentication: considerations and requirements for secure access to registry APIs (Clause 8), including authentication mechanisms and secure transfer practices.
• Conformance and semantics: use of globally unique identifiers and controlled vocabularies to ensure semantic interoperability across systems.

Practical applications and users

ISO/IEC 24751-4:2023 is aimed at organizations building inclusive digital learning ecosystems and those implementing individualized accessibility services:

• LMS and e‑learning platform developers - integrate AfA registries to adapt content to individual needs.
• Assistive technology vendors - register and lookup standardized concepts for preferences and device capabilities.
• Accessibility engineers and UX designers - validate preference statements against authoritative concept records.
• Enterprise architects and IT administrators - deploy local or synchronized registry servers for secure, organization‑specific vocabularies.
• Standards bodies and researchers - harmonize vocabularies for context, resources and individual preferences.

Common use cases: registering new accessibility concepts, validating AfA preference statements, synchronizing registries across systems, and enabling adaptive UI components to query standardized concept definitions.

Related standards

• ISO/IEC 24751 series (Access for All framework)
• ISO/IEC 2382‑36 (terminology)
• IETF BCP 47 (language tags)
• IETF RFC 7159 (JSON), RFC 7231 (HTTP), RFC 3986/3987 (URI/IRI), RFC 2046 (MIME)

Keywords: ISO/IEC 24751-4:2023, Access for All, AfA concept registry, individualized accessibility, e-learning API, RESTful API, JSON concept records, accessibility registry, adaptive learning.

Standards Content (Sample)

INTERNATIONAL ISO/IEC
STANDARD 24751-4
First edition
2023-02
Information technology —
Individualized adaptability and
accessibility in e-learning, education
and training —
Part 4:
"Access for all" framework for
individualized accessibility
and registry server application
programming interface (API)
Reference number
© ISO/IEC 2023
© ISO/IEC 2023
All rights reserved. Unless otherwise specified, or required in the context of its implementation, no part of this publication may
be reproduced or utilized otherwise in any form or by any means, electronic or mechanical, including photocopying, or posting on
the internet or an intranet, without prior written permission. Permission can be requested from either ISO at the address below
or ISO’s member body in the country of the requester.
ISO copyright office
CP 401 • Ch. de Blandonnet 8
CH-1214 Vernier, Geneva
Phone: [phone]
Email: [e-mail]
Website: www.iso.org
Published in Switzerland
ii
© ISO/IEC 2023 – All rights reserved

Contents Page
Foreword .iv
Introduction .v
1 Scope . 1
2 Normative references . 1
3 Terms and definitions . 1
4 Symbols and abbreviated terms.3
5 Conformance . 3
6 Access for All framework . 4
6.1 General . 4
6.2 Basic principles . 4
6.3 Use cases . 5
6.4 Preference concept. 5
6.5 Resource concept . . 5
6.6 Context concept . 5
7 Concept registry .5
7.1 General . 5
7.2 Requirements on registries . 6
7.3 Requirements on concept submissions . 6
8 REST architecture .7
8.1 General . 7
8.2 Request and response parameters . 7
8.3 Response codes . 8
8.4 Security considerations . 8
8.5 Authentication . 8
8.6 MIME type . 8
8.7 Other general requirements . 9
9 Registry API (JSON mapping) . 9
9.1 General . 9
9.2 Concept record (JSON format) . 9
9.3 CREATE concept record.12
9.4 UPDATE concept record . 14
9.5 DELETE concept record . 16
9.6 GET concept record . 16
9.7 GET list of concept records . 17
Bibliography .20
iii
© ISO/IEC 2023 – All rights reserved

Foreword
ISO (the International Organization for Standardization) and IEC (the International Electrotechnical
Commission) form the specialized system for worldwide standardization. National bodies that are
members of ISO or IEC participate in the development of International Standards through technical
committees established by the respective organization to deal with particular fields of technical
activity. ISO and IEC technical committees collaborate in fields of mutual interest. Other international
organizations, governmental and non-governmental, in liaison with ISO and IEC, also take part in the
work.
The procedures used to develop this document and those intended for its further maintenance
are described in the ISO/IEC Directives, Part 1. In particular, the different approval criteria
needed for the different types of document should be noted. This document was drafted in
accordance with the editorial rules of the ISO/IEC Directives, Part 2 (see www.iso.org/directives or
www.iec.ch/members_experts/refdocs).
Attention is drawn to the possibility that some of the elements of this document may be the subject
of patent rights. ISO and IEC shall not be held responsible for identifying any or all such patent
rights. Details of any patent rights identified during the development of the document will be in the
Introduction and/or on the ISO list of patent declarations received (see www.iso.org/patents) or the IEC
list of patent declarations received (see https://patents.iec.ch).
Any trade name used in this document is information given for the convenience of users and does not
constitute an endorsement.
For an explanation of the voluntary nature of standards, the meaning of ISO specific terms and
expressions related to conformity assessment, as well as information about ISO's adherence to
the World Trade Organization (WTO) principles in the Technical Barriers to Trade (TBT) see
www.iso.org/iso/foreword.html. In the IEC, see www.iec.ch/understanding-standards.
This document was prepared by Joint Technical Committee ISO/IEC JTC 1, Information technology,
Subcommittee SC 36, Information technology for learning, education and training.
This first edition cancels and replaces ISO/IEC TS 24751-4:2019, which has been technically revised.
The main changes are as follows:
— requirements on registries and concept submissions have been added to the scope;
— new terms have been defined in Clause 3;
— new clauses on the Access for All framework (Clause 6) and the concept registry (Clause 7) have
been added.
A list of all parts in the ISO/IEC 24751 series can be found on the ISO and IEC websites.
Any feedback or questions on this document should be directed to the user’s national standards
body. A complete listing of these bodies can be found at www.iso.org/members.html and
www.iec.ch/national-committees.
iv
© ISO/IEC 2023 – All rights reserved

Introduction
This document introduces the AccessForAll (AfA) concept registry as warranted by the AfA framework
whose basic principles are introduced in subclause 6.2.
The AfA framework follows an inclusive approach to participation in life by individuals. This inclusivity
focuses on addressing the usability of all resources based on individual requests and requirements
which would thus reverse the current practice of favouring the majority.
Typically, services and products are designed for the largest possible customer base. This leaves
many marginal, or minority needs unmet. Nevertheless, many products and services can be adapted
to accommodate individual requirements. The expression of unmet requirements can also prompt the
diversification of available resources, increasing the pool of choices available to individuals.
The AfA approach recognizes that anyone can experience a mismatch between personal needs and a
resource (including service, environment, experience or product). The approach addresses accessibility
for persons with disabilities as integral to the spectrum of human diversity, and an impetus for more
flexibility, responsiveness, and inclusion for everyone.
Everyone can benefit from designs that match their personally unique needs and preferences. Inclusive
systems respect individual needs and preferences.
For individualized accessibility, the needs and preferences of individual users need to be described
in a concise and machine-readable manner. User interfaces and their components can then read such
personal AfA preference statements and accommodate them in their adaptations. In addition, other
aspects of the context of use need to be described so that user interfaces and their components can take
the user's tasks, their equipment and their environment into account. Also, user interface resources
need to be described so that AfA services can identify the most appropriate resources for a specific
context of use.
For all descriptions, vocabularies are instrumental to allow for a strict semantic and machine-readability.
Therefore, this document specifies an AfA concept registry for AfA concepts for the description of AfA
preference statements, other aspects of the context of use and user interface resources. For each AfA
concept, a concept record contains a globally unique identifier and other characteristics of the AfA
concept.
An AfA concept registry needs to be globally accessible through a well-defined API and format rules
need to exist for the exchange of AfA concept records. This document specifies a RESTful API for an
AfA concept registry service (a.k.a. registry server) and a JSON format for AfA concept records to be
exchanged through the AfA concept registry API.
The following use cases are meant to illustrate the benefits of the AfA framework and its standardized
AfA concept registry including API and concept record format. This list of use cases is not meant to
restrict further uses of this document in any way.
— A person using an AfA concept registry (e.g., a developer of an assistive technology solution)
registers an AfA concept on a registry server. This can be facilitated by either a web interface of the
registry or by a third-party development application (e.g., an integrated development tool) running
on the person's computer. The third-party development application has some advantages over the
web interface since it allows for a tighter integration of development platform and registry server.
It requires the definition of a concept registry API and of the format of AfA concept record.
— An infrastructure component (e.g., a tool for setting up AfA preference statements or an AfA service)
looks up an AfA concept on a registry server. Thus, the definition of an AfA concept can be presented
to the user or the range of allowed values of an AfA concept can be considered for the identification
of matching AfA resources.
— A syntax checker (e.g., special lint tool) verifies the contents of a new AfA preference statement by
validating against the AfA concept records on a registry server. By this procedure, invalid values for
v
© ISO/IEC 2023 – All rights reserved

AfA concepts can be detected. In case of an invalid AfA preference statement, the syntax checker can
notify the user about the error or make automatic corrections.
NOTE 1 A syntax checker could be part of a service managing AfA preference statements, checking every
incoming AfA preference statement for syntax errors before storing it.
— Two services managing AfA preference statements synchronize their AfA preference statements.
This could be a full synchronization over all contained AfA preference statements, or it could affect
only a part of the statements. To avoid the distribution of invalid content, incoming statements can
be verified against the AfA concept records of an AfA concept registry server (e.g., to detect invalid
values), and erroneous statements can be skipped or automatically corrected.
— Two AfA concept registry servers synchronize their entries. This could be a full synchronization
over all contained AfA concept records or it could affect only a part of the entries.
NOTE 2 It is possible to run multiple registry servers globally. Some organizations have built, for security
and privacy reasons, self-contained digital infrastructures (such as intranets) with only very few and well-
defined gateways to the external internet. Such organizations would possibly prefer to have their own
registry server running in their infrastructure, and have it synchronize with some global registry server
in a secured way from time to time. Also, organizations that develop adaptive user interfaces or assistive
technology solutions would likely want to have their own registry server for experimentation purposes.
vi
© ISO/IEC 2023 – All rights reserved

INTERNATIONAL STANDARD ISO/IEC 24751-4:2023(E)
Information technology — Individualized adaptability and
accessibility in e-learning, education and training —
Part 4:
"Access for all" framework for individualized accessibility
and registry server application programming interface
(API)
1 Scope
This document specifies an AfA concept registry service, in particular:
— requirements on registries;
— requirements on concept submissions;
— a data format (in JSON) for the exchange of registry entries (AfA concept records) between registry
servers;
— a set of RESTful operations for AfA concept registry servers to allow for the manipulation of AfA
concept registry entries by external clients other than server-internal web interfaces.
2 Normative references
The following documents are referred to in the text in such a way that some or all of their content
constitutes requirements of this document. For dated references, only the edition cited applies. For
undated references, the latest edition of the referenced document (including any amendments) applies.
ISO/IEC 10646, Information technology — Universal coded character set (UCS)
IETF BCP 47, Tags for Identifying Languages
IETF RFC 2046, Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types
IETF RFC 3986, Uniform Resource Identifier (URI): Generic Syntax
IETF RFC 3987, Internationalized Resource Identifiers (IRIs)
IETF RFC 7159, The JavaScript Object Notation (JSON) Data Interchange Format
IETF RFC 7231, Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content
3 Terms and definitions
For the purposes of this document, the following terms and definitions apply.
ISO and IEC maintain terminology databases for use in standardization at the following addresses:
— ISO Online browsing platform: available at https:// www .iso .org/ obp
— IEC Electropedia: available at https:// www .electropedia .org/
© ISO/IEC 2023 – All rights reserved

3.1
access for all
AfA
approach to providing accessibility in a computer-mediated environment in which the digital resources
and their method of delivery are matched to the needs and preferences of the user
[SOURCE: ISO/IEC 2382-36:2019, 3.8.1]
3.2
AfA concept
globally identifiable unique combination of characteristics relating to context, individual preference(s),
and resource(s) relevant for the personalized interaction for AccessForAll (3.1) and individualized
accessibility (3.12)
Note 1 to entry: The registration of an AfA concept captures its unique identifier, label(s), definitions(s),
domain(s), and value space in an AfA concept record.
Note 2 to entry: The defined terms “AfA” and “individualized accessibility” incorporate the concepts of
individualized needs and matching of resources.
3.3
AfA concept record
data or file associated with an AfA concept (3.2) in an AfA concept registry (3.4)
EXAMPLE AfA concept identifier, its label(s), definition(s), domain(s), and value space.
3.4
AfA concept registry
electronic directory of AfA concept records (3.3)
3.5
AfA concept value space
component of an AfA concept record (3.3) providing the specifications of the values associated with an
AfA concept (3.2)
3.6
AfA context concept
situation or circumstance for which an AfA preference statement (3.8) applies
Note 1 to entry: A minimal set of AfA preference concepts can be a single preference value.
3.7
AfA preference concept
personal set of values based on a sub-set of registered AfA concepts (3.2)
Note 1 to entry: The collection of AfA preference concepts provides the potential choices of preference values
that can be declared by an individual in an AfA preference statement.
3.8
AfA preference statement
user defined set of AfA preference concepts (3.7), and where appropriate, incorporating the AfA context
concept (3.6) and resources to which the set applies
Note 1 to entry: A minimal set of AfA preference concepts can be a single preference value.
3.9
AfA resource concept
AccessForAll (3.1) approach using an AfA concept (3.2) to deliver a resource that satisfies the user’s
requirements
Note 1 to entry: A resource can include but is not limited to activities, configurations, content, environment,
experience, interface, product, service, technology.
© ISO/IEC 2023 – All rights reserved

3.10
AfA concept registry server
AfA service (3.11) running an AfA concept registry (3.4)
3.11
AfA service
system that supports individuals in determining and declaring personal AfA preference concepts (3.7)
found in AfA preference statements (3.8), and delivers the matching resource
3.12
individualized accessibility
facility of an IT system-based learning environment to address the needs of an individual
as learner (through adaptation, reaggregation and substitution)
Note 1 to entry: Accessibility is determined by the flexibility of the education environment (with respect to
presentation, control methods, structure, access model and learner supports) and the availability of equivalent
content deemed to be adequate alternatives.
[SOURCE: ISO/IEC 2382-36:2019, 3.8.7]
4 Symbols and abbreviated terms
AfA AccessForAll
API application programming interface
IRI internationalized resource identifier (IETF RFC 3987)
HTTP hypertext transfer protocol (IETF RFC 7230, IETF RFC 7231)
HTTPS HTTP secure (IETF RFC 7230, IETF RFC 2731)
JSON JavaScript object notation (IETF RFC 7159)
MIME multi-purpose internet mail extensions (IETF RFC 2046)
[10]
REST representational state transfer
URI uniform resource indicator (IETF RFC 3986)
5 Conformance
A conforming AfA concept registry shall have the following characteristics:
— it shall meet all requirements on registries, as specified in subclause 7.2;
— it shall accept only concept submissions that meet all requirements, as specified in subclause 7.3.
A conforming AfA concept registry server shall meet all of the following requirements:
— REST architecture, as specified in Clause 8;
— The JSON mapping for the registry API, as specified in Clause 9.
A conforming AfA concept registry server may support additional format mappings for the registry API.
NOTE The requirements and recommendations for a registry server in this document apply to its API and
data formats for parameters in the API. Nothing in this document is meant to constrain the design, data structure
and implementation of the internal parts of a registry server, including its database of AfA concepts.
© ISO/IEC 2023 – All rights reserved

6 Access for All framework
6.1 General
This document assumes an AccessForAll (AfA) framework that enables:
— individuals to discover, explore, refine, prioritize, and request their personally unique preference
statements, for a given context;
— developers to attach metadata to resources to facilitate matching to AfA preference statements;
— AfA services to satisfy the individual preferences by delivering a matching resource, e.g, by
finding, assembling, developing, recruiting, or using other strategies to deliver products, services,
configurations, or environments that match the preferences.
AfA is in large part motivated by the goal of addressing currently unmet or poorly met preferences
(where the term preferences encompasses the range from critical needs to preferred configuration).
This goal is in part satisfied by registries, which are open to any individual or organization, to register
possible AfA concepts, including concepts associated with unanticipated, emerging, or new preferences.
These registered concepts might then be used to express individual preferences within a broad
diversity of AfA implementing services.
An AfA concept registry is intended to provide a living directory of possible AfA concepts (preference,
context and resource concepts).
NOTE An AfA concept registry is not used for individuals to declare or store personal preferences or personal
preference sets (AfA preference statement). For this purpose, a user-context service (a.k.a. preference server) is
specified in ISO/IEC 24752-8.
6.2 Basic principles
The AfA framework is designed with the following basic principles in mind:
— Description of resource functionality, not users. The AfA approach recognizes that the preferences
of a person are a declaration of functional requirements or preferences relative to resources. They
are not a description of a personal deficit, medical condition, or disability. An AfA approach gives
priority to the individual, and their understanding of their own preferences.
— Flexible use of registered AfA concepts. AfA concepts shall be freely available for use in multiple
ways, including to create preference statements (using AfA preference concepts), describe contexts
where preference statements apply (using AfA context concepts), and describe resources for
matching preferences (using AfA resource concepts).
— Extensibility. The AfA approach enables practices that continuously improve the matching of
resources to users’ individual preferences in general or in specific contexts. It does not limit the
diversity of preference concepts, associated human understandable labels, or strategies for
addressing the preferences. An AfA concept registry supports the inclusion of preference concepts
not previously considered.
— Accessibility of Processes and Services. The AfA approach is in part intended to address the lack
of representation and the barriers to participation experienced by individuals with minority or
uncommon needs and preferences. This exclusion can occur even in processes or services specifically
intended to meet the needs of underserved individuals. To break the cycle of exclusion and lack of
participation, AfA processes and services must themselves adhere to individualized accessibility
principles and practices.
— Internationalization: An AfA concept may have multiple human-readable labels (in an unlimited
number of languages) but is still globally identifiable by its IRI. On the example of preferences, more
than one person may have the same requirement in mind, but they may use different languages and
labels to refer to the same preference concept.
© ISO/IEC 2023 – All rights reserved

6.3 Use cases
AfA concepts are used by AfA services in terms of:
— AfA preference concepts: Enable individuals to create AfA preference statements or requests,
(this includes discovering, exploring, evaluating and refining an understanding of the preferences
that work best for them in a given context to achieve a given goal);
— AfA context concepts: Identify situations and circumstances for which AfA preference statements
apply;
— AfA resource concepts: Identify resources that match AfA preference concepts (including, but not
limited to, through the application of resource metadata);
— Match making: Match resources to personally declared AfA preference statements.
6.4 Preference concept
AfA preference concepts are possible user preferences that an individual may choose to express personal
preferences through an AfA preference statement. The extensible cataloguing of possible preferences
that a user may wish to express will help to guide producers and developers in addressing currently
unmet user requirements. This in turn supports innovation and greater inclusion of individuals that
are currently excluded or marginalized.
A preference concept’s type is "PreferenceStatement".
6.5 Resource concept
AfA resource concepts describe candidate resources for matching or satisfying with an AfA preference
statement in a specific context. Candidate resources are user interface resources such as user interface
components, symbols, images, subtitles, audio descriptions, or custom settings. Resource concepts can
also be used to describe specific techniques and processes for adaptations.
An AfA service that matches preference statements to resources in a specific context can make use of
resource concepts.
A resource concept’s type is "ResourceDescription".
6.6 Context concept
AfA context concepts describe situations and circumstances of user interface usages. They can be used
to identify whether a specific preference statement applies in a specific context or not. They can also be
used to specify the applicability of resources and resource concepts.
A context concept’s type is "ContextDescription".
7 Concept registry
7.1 General
The primary purpose of an AfA concept registry is twofold:
— To enable the extensibility of AfA concepts and the registration of new or unanticipated concepts;
— To support clarity and interoperability of AfA concepts, as used by users of user interfaces and
suppliers and producers of resources and AfA services.
© ISO/IEC 2023 – All rights reserved

AfA concept registries should be distinguished from other AfA services. AfA concept registries do
not deliver matches for personal preferences or the means for creating and storing AfA preference
statements.
An AfA concept registry will gather, store, maintain and publish AfA concepts, their definitions, the
different labels used to refer to them, an assigned identifier (IRI), as well as other optional information
associated with a preference concept.
7.2 Requirements on registries
Registries shall accept all registrations of AfA concepts and additional information that are submitted
in good faith. Published registry policies may define and publish a process for determining ‘in good
faith’.
A registry shall allow free, remote, electronic interrogation of the registry by any individuals or
organisations and allow free use of AfA concepts. Registry policies may limit inappropriate access, but
this shall be published in the policy and shall be consistent with the provisions in this document.
Registrations shall be enabled online, such as by e-mail or via a Web-based form, and may also be
accepted by facsimile or paper copy according to the policy of the particular registry.
Where a contribution is rejected for some reason, and the person making the submission is contactable,
the registry authority shall notify the submitter including the reason why the contribution is rejected
and provide an opportunity to appeal the rejection (unless the rejection was due to technical reasons,
e.g., syntax error or missing information). Published registry policies shall define an appeals process
where rejections are anticipated.
Where registries include policies for approval/rejection of submissions based on their content, these
shall be defined and published in accessible forms.
Registries shall provide security for all AfA concepts and other registrations and shall publish their
security policies. This includes frequency and means of backup, archival, continuity and succession
plans.
As these registries are intended to serve the purpose of improving accessibility, registries that have a
human interface shall ensure those user interfaces are accessible.
It is assumed that many using the registries will not be technology specialists, so it is expected that
registries will support users with plain language applications to help them use the registry. In some
cases, such assistance may be very comprehensive.
7.3 Requirements on concept submissions
A concept submission shall include the following information items:
1) a globally unique identifier (IRI) for the concept (as specified by IETF RFC 3987);
2) natural language names (termLabels) for the concept in at least one natural language;
3) natural
...