Main content (Site structure)
Description Language accessibility assessment Tool – DlaaT
Introduction & Information details for the DlaaT Tool
The DlaaT allows the accessibility assessment of SDL application designs.Accessibility assessment is performed on the basis of the respective HAM evaluation approaches. The selection of the evaluation approaches is performed either manually or through the selection of disabilities that are mapped onto guidelines and evaluation techniques. The output of the assessment tool comprises the evaluation result as well as suggestions for correcting the detected shortcomings. More specifically the accessibility Description Language assessment module consists of the following three sub-modules:
- a. The Accessibility Threshold Controller that is responsible for connecting to the ACCESSIBLE ontologies and receive the relevant guidelines and values for the assessment process. It also obtains the thresholds that will be used for the evaluation process. Some of the defined accessibility features include the size of GUI controls, the existence of text labels and titles, as well as their font size, the position of GUI components, etc.
- b. The Accessibility Features Parser, which is capable of parsing the SDL file and storing the accessibility semantic features. The module first communicates with the Accessibility Threshold Controller entity to get the application features that must be checked for the accessibility evaluation. It then parses the SDL system application’s source code (files with extensions ".pkg", ".pr" and ".fsm"), looks for specific SDL commands and seeks for the values of command parameters.
- c. The Accessibility Evaluator Resultant that is responsible for comparing the pre-defined thresholds with the current values of the accessibility features of the SDL system, displaying and storing the results of the accessibility evaluation and making the suggestions to increase application's accessibility. It provides input for the generation of the accessibility assessment Report (in printable as well as EARL based format). It also makes suggestions on how to increase the accessibility level of the SDL application. To satisfy the above functionality, the module communicates with the Accessibility Features Parser and Accessibility Threshold Controller modules. The following figure 1 depicts an overview of the Description Languages accessibility assessment module architecture.
Figure 1: System Architecture of the Accessibility Assessment Module for SDL Systems
Owner/Main Developer (including also key partners contribution)
SOLINET
Intelectual property Rights (IPR issues, Licences)
BSD licence
Nature of the Code
Open source, proprietary under SAFIRE IDE
Strengths and Weaknesses
| Strengths | Weaknesses |
|---|---|
|
|
Contribution to the state of the art
The DlaaT tool has been implemented in order to support the accessibility development of SDL applications and after a thoroughly examination in the literature on the subject we didn’t identify the existence of any similar tool.
Technical Testing Results from the developer and beneficiary validation
DlaaT tool has been tested in pilot tests with developers and beneficiaries and several important usability issues occurred. In the following table we outline the most important issues that were identified during the testing, and how they were addressed for the improvement of the tool.
| Issue description | Priority | Solved | Solution / Explanation |
|---|---|---|---|
| When selecting more than one disability, the mapping is not compliant with the HAM specification. | 1 | YES | It was found that when a single disability was selected, then the mapping was correct. However, in the cases that multiple disabilities were selected, then, indeed, the mapping was wrong. The implementation was corrected and the mapping is now according to the HAM specification in the cases of multiple disabilities selection. |
| The “Level” field in the report generated by the EARL-based reporting tool is “A” for all techniques. | 1 | YES | The implementation of the DLaaT integration interface with the EARL-based reporting tool was modified so that the reported bug relating to the technique level was corrected. The “Level” field in the generated pdf is now correct for all techniques. |
| The specified techniques and corresponding guidelines for correcting the results (e.g. for G2.5) are not clear sometimes. | 1 | YES | The description of the Techniques was improved in order to more accurately describe the corresponding requirements and better be linked to the respective tips for correcting limitations. |
| “Techniques” and “Tips” in the produced report are not self-explanatory in some cases. | 1 | YES | The description of the provided Tips was modified in order to more accurately pointy out the required modifications towards correcting accessibility limitations. |
| Although the provided tips for correcting errors point out what needs to be corrected (e.g. a parameter value), the description of some of the techniques in the generated pdf is not clear. In some cases this results in the user not being able to perform the required changes. | 1 | YES | The description of the provided Tips was modified in order to more accurately pointy out the required modifications towards correcting accessibility limitations. |
| Perhaps it would be useful that the SDL applications provided self-explanatory examples on the accessibility improvement of a design, e.g. by providing a “not accessible” and an “accessible” version of an application allowing the user to investigate the “required” modifications as these are reported by the tool. | 2 | YES | An “accessible” and a “not accessible” version of the Solenoid SDL application were created towards providing an example of correcting accessibility limitations through the use of the tool. |
Position in the theoretical development process
An accessible SDL application is the one that operates well satisfying the needs of both impaired and non impaired users. The application must be able of processing the user inputs and providing them with appropriate output content which is easy to interpret, useful and helpful for them. The above requirements define two accessibility layers which form the basis for the Accessible SDL application evaluation. The two accessibility layers are the basic accessibility layer and the extended accessibility layer.
In order an application to be basically accessible it must follow a set of rules-guidelines defined for this level of accessibility and in order to be extensibly accessible it must be a basically accessible application (satisfy the set of rules of the basic accessibility layer) that also follows the rules-guidelines defined for the extended accessible SDL applications ((More details could be found in the Deliverable D3.1 ). Furthermore, for each guideline, a set of techniques that can be used to check whether an already developed SDL application belongs to a specific class or not can be defined.
In order an SDL application to be fully accessible for all the users in respect to the needs of impaired people, the application must have increased usability in order to be used efficiently and satisfy all the groups of users. The figure below depicts the characteristics that an accessible SDL application must have in order to belong in one of the two pre-defined accessibility layers.
Figure 2: Accessible SDL application
A path to obtain the required quality to integrate the tools in mainstream development environments (e.g. Netbeans, JDeveloper)
The Description Languages Assessment Module has been integrated in the applications environment of SOLINET’s SAFIRE Integrated Development Environment (IDE). SAFIRE Professional IDE is a fully integrated development & run-time environment optimized for the implementation, validation & observation of complex systems. It is used for a wide range of applications, such as SW components of various platforms, gateways, signalling testers & protocol analyzers. With over a decade of experience in the industry, the SAFIRE team has created a powerful, innovative tool chain based on international standards, such as SDL, MSC, ASN.1 & TTCN (ITU-T, ETSI, ANSI, ISO). SAFIRE Professional has a graphical development environment for quickly creating, editing & building systems, test harnesses & test suites.
With SAFIRE’s advanced testing features, systems can be validated to various levels of confidence, from top-level tests to detailed conformance tests according to international standards or pre-defined requirements. SAFIRE tests are automated, deterministic, reproducible & documented. There are SAFIRE compatible libraries, test suites, drivers & hardware available for a wide range of systems, for example mobile, internet, aerospace & trunk networks libraries for signalling systems.
