In this article, we will explore the Multi-Faceted Application Model, an approach to accessible learning design that offers multiple modes of operation. This model makes 3D simulations and learning games more accessible and inclusive to a wider range of users.
In this approach, instead of trying to fit multiple accessibility features into a single presentation context, the application launches into one of several available modes of operation most tailored for the current user. Each time the user opens the application, they see the context that is most appropriate for them. This technique can be used on desktop applications, mobile apps, web pages, or dedicated kiosks and embedded systems.
Table of Contents
Background
Traditional methods
The traditional method for deploying simulations and learning applications often involved designing and developing the application without considering many or any accessibility features. Once the application was developed, an accessibility specialist reviewed the application and suggested changes that could be made to improve its accessibility for individuals with various assistive needs.
This approach often resulted in additional time and expense on the development and maintenance of the application, as well as potential unintended limitations in its overall accessibility. The higher the desired accessibility rating, the more restrictive the operation of the application would become for everyone contrary to the desired outcome.
The Multi-Faceted Application Model
The newer method for deploying applications, the Multi-Faceted Application Model, on the other hand, takes a proactive approach to accessibility by incorporating accessibility features from the start of development. This means that the creators consider accessibility throughout the design and development process using accessibility input and feedback as integral parts of the process.
By considering accessibility as a primary factor, the Multi-Faceted Application Model discipline provides a constant checkpoint to help ensure that the application is truly accessible to individuals with various assistive needs from the moment it is released to the public, all without introducing any limitations to the envisioned full-scope operation.
Benefits
There are many benefits of the Multi-Faceted Application Model. Primarily, it ensures that individuals with various assistive needs can use the application without requiring additional modifications or accommodations. This can increase the overall usability and accessibility of the application for a wider range of users while also potentially reducing the need for expensive and time-consuming modifications.
Secondly, each separate user interface mode can be built to play to its own specific functional capabilities. Consider a 3D world view, for example, which provides an extreme sense of visual accuracy and depth but provides little or no information in a non-visual format.
Additionally, the Multi-Faceted Application Model helps reduce the risk of non-compliance with accessibility regulations and guidelines. By incorporating accessibility features from the outset, the application is designed to meet or exceed the accessibility standards set forth by organizations such as the World Wide Web Consortium (W3C), making it more accessible for all disabled users.
A Look at the Domains
The Multi-Faceted Application Model is a unique and innovative approach to making applications more accessible to users with various assistive needs.
The model defines a usage case scope that is separated into three domains:
An Application domain containing a single application,
A Component domain containing the separate user interfaces, and
The Audience domain which identifies the types of needs fulfilled by each of the component facets.
The use of separate modes of operation tailored to different audiences is an excellent way to provide a more personalized and accessible experience for each user. By separating the application into three usability domains - the Application domain, the Component domain, and the Audience domain - we discover a framework that allows for greater flexibility and customization in terms of accessibility features.
Multi-Faceted Application Model Diagram
Application Domain
The application represents the general logic of the simulation. This will not change regardless of which user interface is active during a session. The application is a single, deliverable project, package, object, or file-set, depending on how it is deployed, such as via game engine, kiosk, or learning management system.
The application domain is the foundation of the other two domains in the model; once you can define the application, you can better identify the accessibility needs and the user interfaces that will best support them.
All the capabilities needed for a person in any consideration group are present in this application, and the licensed user does not need to purchase any other versions or licenses for any mode they decide to use.
Equally, an individual of any capability level can run the application in any of the available modes as they see fit. For example, a non-disabled person can use the text-only terminal mode if they have fond memories of playing old-school text-based PC games.
Component Domain
The Component domain provides the core benefit of the Multi-Faceted Application Model. It represents at least three modes of operation, each designed to cater to a specific group of users with different accessibility needs.
Immersive component
The Immersive component is the 3D world version of the application that offers a visually realistic experience. It is most suitable for audiences with no disabilities at all, those who require three flashes or less, or those who might need captions for the hearing impaired.
The Immersive component offers a rich and absorbing experience that engages multiple senses and allows for the highest degree of visual gradient, interactivity, and feedback.
Static 2D Visual component
The second component, the Static 2D Visual level, is most suitable for use by audiences who experience motion sickness, who have limited input capabilities, or who have any kind of vision limitation apart from total blindness. It relies on a combination of state context and branching logic rather than 3D movement to present information and govern flow.
The Static 2D Visual level provides a simplified and streamlined version of the application that focuses on the essential content and outcomes. It uses static images, text, and audio to convey information and choices to the user. The Static 2D Visual level also reduces cognitive load and minimizes distractions while still maintaining a clear and consistent structure.
Text-Only Component
The third component, the Text-Only level, is a terminal-only style interface with no graphics and no mention of graphics. This component is most suitable for use by input limited people and those who are blind and using screen readers and other assistive devices.
The Text-Only level relies solely on text and speech to communicate with the user. It offers a linear and logical progression through the application that follows a predefined script. The Text-Only level ensures that all users have access to the same content and outcomes regardless of their visual abilities.
Audience Domain
The audience domain lists the capabilities, limitations, and specialized inputs and outputs of the target users. These are specific enough to help developers identify which features the Component domain must include to support a wide range of user abilities.
In a real-time design using this model, all the audiences who should be able to use the finished application are represented by their associated capabilities, limitations, and inputs/outputs (I/O). While it is possible for any of the entries in the Audience domain to be noted multiple times or referenced from multiple components, it is most effective to keep each audience entry to as few component assignments as possible.
The diagram above depicts a small subset of the total needs enumerated by the W3C in their accessibility guidelines.
Flexibility
The model allows for flexibility and customization, in both the contexts of development and usage.
By relating the requirements of the Audience domain to the facets available in the Component domain, developers can get a clear and early indication of the types of features and functionality required of each of the facets, as well as a possible indication of whether an additional specialized facet might be required to accommodate a previously unsupported need.
During end use, learners can choose the mode that best fits their preferences and situation. Users can customize physical devices such as PCs and tablets to always start the application in the correct mode for each user, especially in cases where those systems are administered by an IT professional.
How to Use the Model
Planning
It is best to introduce the Multi-Faceted Application Model early in the envisioning and planning phases of the project, preferably as a type of visual connections chart or spreadsheet.
Use this model to create a living document that can adapt to new discoveries you make during the development process. For instance, as your team begins developing a learning simulation, they may realize that a user need is better supported with a different component. They can catch this change early and avoid costly revisions later.
Because the total accessibility of the product is considered at the beginning of the planning process, you can consult with an accessibility expert early to determine what accommodations your learning experience should support. In relation to this perspective, the Multi-Faceted Application Model is helpful for establishing clear answers to the basic questions of what it is, what it can do, and what its users need it to do.
The following sections describe specific planning tasks during each domain.
Application
During planning, the Application part of the model answers the question of what it is. Specific details about the application like target systems, deployment packages, distribution channels, and the like are kept in the Application domain. These notes help to remind everyone on the team about the operating environment.
For example, if the target system has no keyboard, all components must function well within boundaries without one. Your team may decide that the text-only component needs to employ an on-screen key display or allow users to connect their own assistive devices to it, depending on the application.
Component
In the planning phase, the model's Component domain answers the question of what the application can do in terms of interface with the outside world.
As mentioned previously, all components link to the single Application, the monolithic driver of the product. When managed as a flow chart, the various components link to their Audience counterpart entries. However, when maintained as a spreadsheet, the component is usually listed in one column while the audience entry is listed in the other.
The Component and Audience domains are prepared iteratively in an evolutionary progression relative to one another. For example, when planning a full 3D view with world-like navigation, you also need to plan the other components, such as Static 2D and Text-Only, depending on the kind of simulation you are building.
However, you may also need to define one or more additional components to fully support the needs of all the intended users. As an example, think in terms of physical-only interfaces, moving platforms, and mechanical actuators.
Audience
When in planning, the Audience domain contains a detailed answer about what users of the application will need it to do. How well the Component domain can match the requirements in the Audience domain will determine one of the primary metrics of success for the application.
Whether listed graphically or in spreadsheet form, the entries corresponding to capabilities, limitations, and input/output modes are usually listed nearest to the components that will be servicing them. In the cases where the element can be serviced on multiple components, it might be most advantageous to sort that element closest to the two or more shared components.
During the project's envisioning and planning phases, be sure to identify and describe every well-documented need that can be accommodated. Here are some helpful resources to get you started:
W3C Web Content Accessibility Guidelines: A thorough list of recommendations for making your digital learning experiences more accessible.
WebAIM’s Introduction to Web Accessibility: A beginner’s guide to what web accessibility is, why it is important, and some general principles of accessible design.
Management
Management of a project deployed as a Multi-Faceted Application Model is not much different from a typical modern software project employing a programming model like the Model-View-View Model (MVVM) or some similar model that enforces boundaries between the user interface, data, and base functionality of the application.
While this article does not go into any of those philosophies, some clear management effects are described that may already be familiar.
Central Business Logic
The so-called business logic of the application is essential to this approach. For anyone new to the idea, the term is more akin to "the business end of a shovel" than an enforcement of how tax should be added to a sales order in a business, although the latter is certainly a form of business logic used in a specific context.
The true advantage of the idea of business logic is that all the base functionalities can be hosted in a single principal place of the application. Although the entire application can access that central functionality, the business logic itself is not aware of any of the other parts of the system, especially not the input or output. This promotes a uniform, consistent style of operation that does not depend on any specific kind of interface to the world.
More importantly in our case, it allows for any kind of input and/or output without having to change the purpose, logical flow, or even a single line of base code in the system.
The following examples are some of the specific types of operation provided by the business logic in a typical simulation:
Managing the difficulty level for the current player's skill level and providing distinctive styles of feedback depending on the current skill level settings.
Managing the player's position and logical progression through the simulation, forking on the path when appropriate, managing immediate feedback and consequences, and maintaining overall status.
Organizing and providing access to each of the supplemental tools, learning or reference materials, and manuals offered at each stage of the simulation.
Handling of assessments and testing assignments and status, whether practical or question/answer based.
Separation of Duties
When seen in terms of just the user interface, the components amount to separate sub-applications so their development can be assigned to separate coding teams. At the very least, the separation of UI from logic is followed along a clean path.
At the far end of the spectrum, simultaneous work for up to five separate coding teams can be justified, as listed below:
Data
Logic
3D UI
2D Static UI
Text UI
Of course, in the larger project, the manager still employs the same separation of duty activities already implemented within the organization.
The model works equally well for small organizations in which every member has multiple roles. It provides a formalized process that guides developers through the accessibility dimensions of the learning experience.
Time Savings
Although it may seem like creating additional UI components would take more time, prior experience shows that this approach may be by far the quickest method so far for completing a project with full accessibility compliance.
This is mostly because as more demands are placed upon a single user interface, that user interface becomes either increasingly unmanageable or unusable. Any later change takes an increasing amount of time, effort, and additional planning to complete.
In contrast, the same project maintained on multiple dedicated user interfaces does not need to change very much as new versions are created. Although there is significantly more work to get it right up front, truly little work is required over time, including in all the pre-release versions.
By the time a product employing the Multi-Faceted Application Model is released to the public in its first version, it is already paying for itself in time benefits over the single user interface model. In cases specific to MVVM philosophy alone, those benefits are already known to exponentially amplify over time with the addition of each version.
Summary
The Multi-Faceted Application Model is an innovative way to create simulations and learning games truly accessible to all users. By offering different modes of operation that suit different accessibility needs, the model ensures that no user is excluded from the learning experience.
The Multi-Faceted Application Model is a powerful tool for creating engaging and effective learning applications that can reach a wide and diverse audience.