Accessibility is a key quality for a system. If a system is not accessible, then it becomes hard for some users to use the system. The subject of accessibility is quite broad, therefore in this post we are concerned mainly with the accessibility of web based systems.
Usability has been recognized as an element of design of systems, but accessibility has been viewed primarily as a compliance matter. This must change, because accessibility is concerned with the usability of a system from the all inclusive perspective of human system interaction. Taking this approach allows accessibility to be designed.
In order to achieve Virtually Managed Software, qualities should be considered primary to a design. This approach allows an architectural aspect to be considered prior to design. Similarly, the architectural aspect of design for accessibility will be explored in this post.
First, let us take a look at the following infographic from webaim that shows the areas to consider when designing accessibility.
Architecture for Accessibility
A good architecture for a system will follow a pattern of separation of concerns. True separation of concerns in terms of virtuals causes architectures to be robust along each of the concerns that are reviewed.
So the architecture of a web system will separate the user interface components from other components of the system using techniques such as layering. Using layers of code, user interface code is separated from content management code and security code.
However, during implementation, the user interface code involves patterns such as Model View Controller (MVC) to integrate the different layers. The integration components or glue-code sometimes leads to developing proxies or representatives of UI components. When such proxy components are created, they love their base more than the UI design, thus leading to conflicts with design. For example, in java technology, JSP tags are defined that are proxies for html tags. These tags are more friendly to the Java developer than the UI designer. This leads to a problem.
Firstly the (UI) design is used as a starting point, but along the way the system code takes over and design becomes fixed. As a result, it is not possible to change the UI design once the system and UI are developed. Only partial changes are possible.
Next, UI design sometimes produces a great appearance, but the code produced is not ready for the system. Thus system code tweaks the design code and once again both cannot change independent of one another.
This problem is a major head ache for designing for accessibility. All the web pages that are presented to user must be accessible. Thus the system code and UI design code must remain independent and inter-operable.
One might think CSS solves this issue. In short, it does not. This is because the CSS classes are typically attached to HTML tags, and the class names are now fixed. Thus limited changes to design are possible just by changing the styles.
In order to create an architecture for accessibility of web systems, we need to review the other qualities that are involved in trade offs with usability and accessibility.
Functionality – Ability to do the work defined for the system.
Portability – Ability to work in various browsers
Efficiency – Ability to perform the functions while using resources proportionately.
Maintainability – Ability to make modifications with proportionate level of effort.
In addition to the qualities of the system, there are considerations related to the economical production of the system such as cost and time to market.
The effective level of accessibility of a system depends on the level to which the other qualities have been attained.
Functionality – is diminished if accessibility is diminished. (Independent of cost and time taken)
Portability – is increased if accessibility is decreased. (This relationship can be reversed with increased cost and time)
Efficiency – is increased if accessibility is improved (Partially dependent on cost and time taken)
Maintainability – is increased if accessibility is improved (Independent of cost and time taken)
The consideration of such trade offs leads to an approach to design that is based on heuristics. As a result, the cost of production of an accessible system is unpredictable. It also leads to the perception that it is a random requirement and painful to address.
Further, as accessibility is defined in terms of standards that are described in rules, the architecture of the system should be such that designs can be generated by inference to the maximum extent possible. Rules based testing is already a common practice for accessibility testing. However as noted earlier, design is still based on heuristics.
To facilitate an architecture that allows designs to be created from inference, the following approach is proposed.
- Separate web components from system code
- Define web components as building blocks such that the components are accessible
- Define composition rules such that the composites are accessible
- Define system components that facilitate rules based composition
- Map system functionality to web composite functionality
Each of these ideas will be explored in more detail in future posts. A brief summary of these methods is presented below for the time being.
Separate web components and system code
Make a subsystem with all presentation and data combinations. The web components can be altered independently of the data, and there will be a clear definition for the various scenarios. For example, how many columns or data elements can be presented at once, how much data can be presented at once etc. These decisions are codified into reusable procedures or guidelines so that they can be reapplied in new design scenarios.
This is not the same thing as making a huge theme with lots of styling that is all inclusive. Each web component and its subsystem will appear together and can be easily consumed in application development scenarios.
Define web components as building blocks that are accessible
Each of the web components should be complete and accessible.There can be system components that permit the full exercise of the web components.
Define composition rules so that components are accessible
The way in which web components are combined into larger pages and presentations should be explicit and validated for an accessible result. Certain combinations of components may not function similarly as when they are separate. Therefore composition rules allow designs to be inferred from components.
Define system components that facilitate rules based composition
When system components are created with various concerns separated, their integration depends on the techniques and technology. The approach should be to allow rules based composition. Rules based composition specified permitted combinations as well as methods of composition.
Map system functionality to web composite functionality
The preparation of web components and system components that work together to create an accessible subsystem should allow the mapping of the composed functionality to the complete UI. This step creates the application for use, and can be decomposed into its parts for easy analysis.
This is very important as the real desirable consequence of any method is to develop the application so that it can be easily broken into its separate parts that can be analyzed.