Keywords

1 Introduction

Once characterized by static pages and a passive environment, the web is currently a dynamic structure, that, through the use of several components (widgets), it combines a desktop interface and functionalities with the wide range of a web application [6, 10]. However, concerning the accessibility of these pages, all this interactivity represents a problem for users with disabilities, since assistive technologies are still trying to cope with this interaction model and dynamic updates [5, 6]. Furthermore, in order to make an accessible web 2.0 it is essential to comprehend how users interact with these dynamic contents and highly interactive components [6]. With that in mind, we correlated WCAG guidelines and WAI-ARIA recommendations that can be applied on the development of accessible web widgets. Following that, an empirical study was conducted with eleven blind users to gather a collection of barriers faced by them when interacting with dynamic components. The goal of this research was to link both specifications and analyze how far they can assure an accessible dynamic environment and which problems are still not covered by them.

2 Background

Power et al. [13] and Vigo and Harper [15], concentrate the efforts on the perspective of understanding user behavior and navigation strategies, however, with different goals. While the first one aims towards personalized web applications for people with disabilities, the second one aims towards navigation problems in real-time. Moreover, about code standardization, one significant attempt to create accessible dynamic content is WAI-ARIA. Published in 2014 by the W3C, it adds roles, states and properties to HTML tags to identify user features and their connection and states. It also offers the resource of communicating some updates to the screen reader [16]. Regarding methods for evaluating the accessibility on dynamic updates, Abu Doush et al. [1] and Fernandes et al. [9], proposed the evaluation of these pages by triggering all JavaScript events, i.e. generating all possible code changes, in order to check code compliance with WAI-ARIA and WCAG 2.0 specifications respectively. However, one considerable problem still remains: although it is essential to enable users to access the information, it is also extremely important being sure that they are able to make efficient use of it [4], i.e. that they understand interact with the content. Yet, this subject is not yet being sufficiently addressed by current researches. Given that, we aim to connect all those points, by finding out existing gaps between currently guidelines and navigation barriers, through gathering interaction problems from an empirical study and correlating them with WCAG 2.0 guidelines and WAI-ARIA Authoring Practices 1.1.

3 Method

We conducted an exploratory study case with eleven blind users who undertook several tasks on a variety of pre-defined websites, in order to observe their interaction and gather a collection of problems encountered by them while performing online activities.

3.1 Website Selection

Websites to be used was first based on a list provided by AlexaFootnote 1 web analytics tool, with the most accessed ones in France and, to ensure a dynamic sample, the sites at the top of the list were analyzed from the tell-signs described by [7]. Those who had the highest number of web widget were selected. Next, we elaborated tasks for each website based on its main activities as well its own purpose and also considering an activity that required an interaction with the widgets available on their pages.

3.2 Participants

This study was conducted with eleven blind users, between 36 and 66 years old. Most of them self-declared as experienced users and working with computer related activities, while the other two participants declared having an average familiarity with computers and internet. One participant used Voice Over and the rest of them used JAWS as their main screen reader software. Some of them used NVDA as a second screen reader during the evaluations, changing between tasks. Five of them counted with a braille display to assist their navigation. To exclude some external factors, all evaluations were conducted in their familiar environment (home/work places) and their usual assistive technologies, computers and software configurations were used.

3.3 Design

Evaluations began with us informing the participants about the study goal and how it would be conducted. Next, we ask them to sign a consent form and applied a profile form. The participants were encouraged to report any problems, using the “think aloud” verbal protocol [8], and after finishing the tasks from a website, they were asked to summarize their difficulties and how they affected task execution. Each evaluation was registered by an external digital camcorder and additional notes.

4 Data Analysis

In the first place, all data collected (notes, videos, forms and user reports) from participants was reviewed to identify barriers during their interaction with selected websites and their respectively widgets. Each barrier was labeled and categorized by the following items: (1) widget: corresponding element; (2) severity (minor/significant/critical): level of disruption caused by the barrier (from a minor shift in the interaction to an interruption of current task); (3) signalized/identified: whether the barrier has been signalized by the user or identified by the researcher; (4) impact: description of the consequences of the barrier in the interaction and task execution; (5) description: description of the barrier itself. Further, a second round of categorization was realized to highlight the instances of same barriers. For this, each instance was classified by its frequency, assistive technology used, user experience (from 1: none to 5: advanced), severity and general description. The final step consisted in correlate each final barrier with WCAG 2.0 guidelines and WAI-ARIA authoring practices to determine which of these barriers could be avoided by using recommendations and to identify the gap between development specifications and interaction barriers.

5 Results

For the first round of data analysis, a total of 43 instances of single barriers from an interaction with some web widget were identified and categorized (Table 1).

Table 1. Example of a single barrier identified and categorized
Full size table

From that, it was possible to detect the recurrence of 10 types of barriers, described as Final Barriers, with the following five widgets: Tabs, AutoSuggestList, Popup content, Carrousel and Collapsible panels. As the goal of this work was, by identifying existing barriers on the interaction of people with disabilities with web widgets, investigate how current efforts handles the accessibility of those elements, we correlated these barriers with WCAG 2.0 guidelines and WAI-ARIA Authoring Practices 1.1. It is important to stress that, as an accessibility evaluation, several barriers were also identified, however, only those linked, directly or indirectly, to the selected web widgets were categorized and further analyzed. Next, from all barriers categorized, we highlight those with the highest level of severity or frequency in Tables 2, 3 and 4.

Table 2. Final Barrier 1: lack of feedback from a PopUp Content.
Full size table
Table 3. Final Barrier 2: difficulty in the perception of contents and sections in a Carousel.
Full size table
Table 4. Final Barrier 4: inappropriate identification of the element “Tabs”.
Full size table

From that we propose more guidance to support the development of accessible widgets. For the elements presented in described barriers, besides the items from W3C [16], to guarantee the accessible development of these elements, we add that:

  • PopUp Content: (1) Users must be able to identify the opening of this element, being notified that new content is available as a result of a previous action; (2) As a modal dialog, keyboard should be moved to this descendent window, since users cannot interact with content outside an active dialog window; (3) Functionalities available through this element must be part of a set of consistently identified features;

  • Carousel: (1) Elements at the same hierarchy level should be equally identified in the code, respecting their corresponding section grouping; (2) Page main structure and information should not be altered without a user action or a notification; (3) If what is changed is only visual, i.e., one content at a time being visually highlighted from a list, it should be kept along with control layout and presentation code (CSS);

  • Tabs: (1) Titles of tabs and their corresponding contents must have the same logical structure as that displayed visually when read by the screen reader; (2) Users must be able to recognize the titles of the element and also manipulate them only with the use of the keyboard; (3) Visual hierarchical structure of the tabs must be reflected in the code so that the software is able to accurately reproduce the available content.

6 Conclusions

As already shown in several researches [2, 3, 11, 12, 14, 17], relying only in accessibility guidelines is not enough to ensure an accessible website, especially if taking into account the growth on web 2.0 related technologies. Automatic evaluation tools are capable to identify a great number of possible barriers, however, some of them can only be perceived through real user interaction. From the conducted study case we analyzed how currently guidelines such as WCAG 2.0 and WAI-ARIA combined can and should be used to promote web accessibility for dynamic pages. We also perceived that there is still a gap in accessibility guidelines, since it depends on the interpretation of the relationships between the elements present in the page. For that, it becomes necessary more studies on how users interact with these widgets to check which barriers are still not covered by current guidelines in order to direct our efforts.

As this is an ongoing research, future studies include users with different kinds of disabilities and also the development of a tool for assisting dynamic pages evaluations based on navigation barriers, evolving these conclusions into code checking items.