Keywords

1 Introduction

The Polycare H2020 projectFootnote 1 mission and biggest challenge is to provide functionality that supports home hospitalization artefacts using IoT (Internet of Things) (See Fig. 1). Polycare consists of adaptable and distributed user interfaces, a knowledge layer and a service layer.

Fig. 1.
figure 1

Overview polycare system

Full size image

The service layer consists of a smart sensor platform, an FHIRFootnote 2 (Fast Health Interoperability Resources) server, a decision support system, a reporting tool and APIs to third party components. In addition, Polycare aims at empowering the caregiving activities as well as providing facilities to integrate the activities of all stakeholders participating in the caregiving process at all stages and minimizing their workload [5]. We have conducted combined usability and accessibility evaluation of the Polycare components as suggested in [3]. Accessibility as indicated by W3C WCAG 2.0 is concerned with aspectsFootnote 3 of user interface such as: Perceivable, Operable, Understandable, Robust, so that content must be robust enough that it can be interpreted reliably by a wide variety of user agents, including assistive technologies. In this paper we are going to describe the methodology of the accessibility evaluation of the Polycare user interfaces designed as Web app and Android app.

2 Accessibility Evaluation

Two main components of the Polycare system were in focus of the accessibility and usability evaluation in Polycare were the Collaborative Environment (CE) and the Polycare Patient App. The accessibility evaluation was conducted in two ways (1) expert evaluation (2) automated accessibility evaluation.

2.1 Expert Tests

For evaluation of accessibility issues of Polycare web (CE) app and Polycare Patient App (native android) different approaches were chosen in accordance to targeted end users and development environment. The target end users of CE are primarily medical staff such as doctors and nurses where it is to assume that they might be suffering from low vision but not have lost sight such as it is the case in blind people. Therefore, the CE accessibility audit included manual checks with the screen magnifier ZoomText to evaluate presentation of information when enlarged. Also keyboard accessibility as a core requirement of accessibility was tested to ensure that all functionality of the content is operable through a keyboard interface. Keyboard accessibility is not only crucial for users with visual impairments, because it allows them to tab through a web page and reach functionality more readily, but also for users with, e.g., a physical impairment accessing the web with alternative interface technologies such as alternative mice, onscreen keyboards or screen readers. Additionally, manual checks were performed while conducting the expert walkthrough for instance in regard to accessibility issues that cannot be determined by automated accessibility evaluation such as whether text equivalents for non-text content are meaningful or not. This applies also to descriptiveness of link texts and labels. The Polycare Patient App addresses primarily older patients suffering from COPD (Chronic obstructive pulmonary disease), which might well be affected by a serious visual or physical impairment, so this application was evaluated manually with Voice Assistant for Android as standard screen reader for blind users of Android apps. As for CE possible accessibility issues caused by lacking keyboard accessibility to functionality, inadequate or missing text alternatives for non-text content or non-descriptive link texts and labels were also evaluated by manual checks during the expert walkthrough. In accordance to current W3C.WAI recommendations both applications were evaluated for compliance to WCAG 2.0 guidelines, in addition to that requirements from Mobile AccessibilityFootnote 4 were considered for evaluation of the Polycare Patient App. Violations of guidelines and suggestions for improvement were recorded together with results from the Expert Walkthrough for better handling by developers.

2.2 Markup Validation and Automatic Accessibility Tests

Markup validation is an important step towards ensuring the technical quality of web pages. However, it is not a complete measure of web standards conformance. While the W3C and other HTML and XHTML validators assess pages coded in those formats, a separate validator like the W3C CSS validator can check that there are no errors in the associated Cascading Style Sheet. CSS validators apply current CSS standards to referenced CSS documents. This report focuses on the syntactic markup analysis of the Polycare user interfaces. We have validated the webpages against the HTML5 specification. Validation is an important component of the compatibility WCAG 2.0 guideline 4.1. The validation issue is described in detail under the relevant technique G134. Automatic web accessibility evaluation builds internally a DOM model of every tested page and traverses all elements checking them for any accessibility issues. It can provide an initial assessment much faster, and give a good input for the expert evaluation. There are, however, certain issues which automated testing cannot detect. This depends on the standards or guidelines we are testing for. For example, when we are testing for a specific syntax, such as valid HTML, the existence of programmatic table headers or color contrast automatic testing tools can provide us with 100 percent accurate results. When we are trying to determine if some information is indicated by the use of color only, an automated tool cannot tell with a high certainty and extra expert evaluation is required. Therefore we conducted automatic accessibility tests to complement the manual tests as explained in the previous section.

3 Conclusions and Future Work

This paper presented the methodology of the accessibility evaluation of all components of the Polycare system. The results of our work has shown that only a combined accessibility evaluation consisting of automated and expert evaluation would really unveil the accessibility problem of an application, especially when it provides different and distributed user interfaces in our case a web application and an Android app. Targeting various stakeholder. Additionally we think that a combined accessibility and usability evaluation is required to ensure good user experience of an application, though there certainly some overlap between them, even though there might be different rationales for that, e.g., for visually impaired users who have limited or no access to visual information, it is crucial that adequate text alternatives are provided for non-text content like images and that link texts clearly describe the target otherwise they will not be able to navigate in an application. However, same issues will also pose a usability issue because self-descriptiveness and conformity to user expectations are understood in usability as important features to support users in achieving their tasks and facilitate learnability of an application. In CE as well as the Polycare Patient App there were shortcomings in regard to these aspects, in that text alternatives were missing or not meaningful and link texts were misleading. Sometimes they did not describe clearly the target or links with the same link text were leading to a different target or link texts of a menu link with the same target were worded differently.