Introduction

Cloud4all/GPII is intended to become the largest and most pervasive infrastructure for accessibility in the world and anyone can join this open source community and contribute. The Project has established (and is expanding through Prosperity4All, UIITA-RERC, Fluid, PGA, Omni Agora) a set of mechanisms and tools that will allow diverse developers and helpers to contribute to this global effort. Developers inside and outside the Project collaborate in building parts of Cloud4all/GPII. AT developers and vendors are included and also invited to integrate their products and solutions and thus benefit from the auto-configuration capabilities provided by Cloud4all/GPII. Developers of all types are invited including programmers, engineers, designers, testers, users, writers, organizers, makers, thinkers, tinkerers, drawers, doers, helpers and more.

Any kind of application can benefit from Cloud4all/GPII: an OS, native application, web or mobile app, AT or not, all can benefit from Cloud4all/GPII enabling and setting their access features according to the needs of the user. The list of solutions that are Cloud4all/GPII compatible as of today can be found at solutions.

In order to be compatible with the Cloud4all/GPII a solution must:

  1. Be listed in the GPII as a solution for specific user N&P or be listed as a mainstream product with features (user interface options or adaptations) that ease the use by people with disability, literacy, digital-literacy, and aging related barriers to ICT use.
  2. Optionally, have all of its user interface options or adaptations entered into the GPII Unified Listing
  3. Optionally, have all of the terms used to describe the interface options or adaptations registered as terms in the Preference Terms Dictionary/Registry [1];
  4. Have a (standard or custom) programmatic way for Cloud4all/GPII to read and change the product’s settings
  5. Have a (standard or custom) way for Cloud4all/GPII to launch and close their app.
  6. Have a (standard or custom) way for Cloud4all/GPII to detect whether the application is installed

The developer or vendor can fill out a single document (attaching configuration files where this is more convenient) and the GPII onboarding or “Tiger” team can do the rest from there. The developer would provide (via the onboarding form and optional attachments) a description of:

  1. the product
  2. all of the user interface options, adaptations, or features (including, in the case of AT, any abilities to transform user interfaces of other materials, software, services, or devices) along with their definitions, allowable value-ranges, and any dependencies between the features or settings
  3. how the settings can be read and changed by Cloud4all/GPII
  4. the way to launch and end the program/service and detect whether it is installed.

For items 3 and 4 this can be a standard method for the platform or custom to the product/service. The Cloud4all/GPII team would then use this information to make all the proper entries in the Preference Term Dictionary (PTD), the Cloud4all/GPII Unified Listing, and the Solutions Registry. It would work with the developer/vendor as needed for these or for any special transformers, settingsHandlers, launchHandlers etc. that some products/services might require.

In order to make the system more efficient, lower the load on the matchmakers, and increase the power of the statistical matchmakers, Cloud4all/GPII has created the Preference Term Dictionary. This is the tool where all terms used to describe solutions’ settings (and users’ N&P) are registered, and alias and transform relationships between terms are documented. This is vital as some solutions use different names for identical setting-concepts and others with the same settings-name are actually different concepts. In addition, the range of values allowed may or may not vary between terms. Thus, the PTD is used to keep a list of all preference terms and their aliases as used in solutions.

[1] Items 2 and 3 are required for a good integration with GPII – for example have your application adapt to a user NP set, even if they haven’t used it before. If these aren’t registered, the application cannot work with common terms and won’t be selected by the matchmaker unless the user has some preferences specific to that application in their NP set.