Keywords

1 Introduction

It was reported that accessibility resources can overwhelm web authors (i.e. all persons involved in the making process of a web application) with information [1, 2]. Also, the classification how severe reported accessibility issues are for some users, is not always evident for a web author [3, 4] and the interpretation differs even more between beginners and experts [5]. While experienced evaluators have the knowledge on how a certain WCAG success criterion should be applied and how different users can benefit from its compliance, it can be tough for beginners to make the connection between a WCAG success criterion and the benefits for users that comes with its compliance [5]. Since accessibility is considered strongly a user centered issue [3, 6], and is characterized as follows: “[Accessibility is, when] specific users with specific disabilities can use it [the software] to achieve specific goals with the same effectiveness, safety and security as non-disabled people” [3], it should be an obligation to feature the connection to the user, and to provide a motivation for the relevance of each success criteria. This is especially important for beginners in the application of WCAG. Therefore, the usage of automatic testing tools, checking a web applications’ accommodation to WCAG, is not fully sufficient to state the accessibility of a web application [7, 8]. While WCAG (version 2.0) forms the technical foundation, and provides rules and instructions to solve - or avoid - defects on web applications, there is also the other side of the coin (respectively: the barrier).

Following the user centered view on barriers, as stated above, a defect on a web application only turns into a barrier if the defect hinders a specific user with specific traits from achieving their specific goals. It is this tension, i.e. seeing a barrier from the user perspective, that can actually create meaning for barriers, and for the success criteria of WCAG, and therefore help to meet the requirements of people with impairments.

From a sociology point of view, Bowker and Star [9] stated: “We [humans] know what something is by contrast with what is not”; e.g., light versus darkness, or in the way that silence makes musical notes perceivable. As they further explained: “We often cannot see we take for granted - unless we encounter someone who does not take it for granted”. Bowker and Star conclude that “tension” between contexts is necessary to create meaning and that information, generally spoken, only gains weight if it can be interpreted in multiple ways.

This provides a sociological explanation why web authors who are new to the topic of accessibility have issues to classify the severity of reported accessibly issues. It can therefore be hard for novices to see barriers and distinguish between severe and trivial accessibly issues [4], since they themselves can perform all use-cases in a web application. Hence, they take the interaction paradigm of a web application for granted – unless, they encounter someone who is actually facing barriers during the interaction, for example while observing a user test. On the other hand, the values of constructional accessibility, like ramps to bypass stairs, are easier recognized, since we encounter them almost every day. We can regularly observe people and situations in which the physical circumstances of our world impose a barrier. In contrast, interaction with software is usually a more private affair; there is no (legal) way of overseeing a product’s users.

Another difference between software- and constructional accessibility is that constructional accessibility can imply meaning for everybody. If someone is facing stairs in the contextual situation of traveling with a baby buggy or carrying heavy luggage, the importance of a ramp or an elevator is highly valuated. In other situations, however, the barrier that stairs can imply may be overlooked or not be recognized. Therefore, a specific object or situation may be experienced differently in different contexts, which then creates meaning, following the argumentation of Bowker and Star.

This tension between contexts is stripped away when focusing solely on (automatic) tools, which evaluate the conformance of web application to WCAG. This could be problematic for beginners as literature suggests [3, 5]. At some point, a web author has internalized WCAG to an extent in which WCAG and its success criteria are taken “for granted”. Hence, the web author can state the severity of potential accessibly issues and has in-depth knowledge on how people with disabilities interact with web applications; thus, the web author has become a web accessibility expert. This process is called: naturalization [9]. At this point, the web author has an intrinsic knowledge of the meaning of web barriers. Forgotten are the struggles of being new to the accessibility topic when everything was strange and odd.

Rooted in the disciplines of human centered design, personas [10] are a widely-used concept to transport user needs and requirements and to keep track of them during the product development process. Using walkthrough techniques to question product features and evaluating interaction paradigms, personas can be a tool to create contextual tension, thus seeing the product through the eyes of the persona.

In this paper, we present and discuss an approach for creating tension in the presentation of WCAG by using personas as a classification schema. The underlying principle is that each success criterion of a guideline should be represented as a set of personas affected by the success criterion; similar concepts have been discussed in [11, 12]. This paper provides an insight on the status quo of augmenting WCAG with personas. Hence, this work outlines some major issues when adding personas to WCAG and seeks to identify steps on how personas should be constructed and used in this context to overcome these issues. The remainder of this paper is structured as follows. Section 2 provides an overview on our persona in context concept and how it differs from the persona concept advocated by Cooper [10]. Section 3 introduces our work in this area, the PersonaBrowser, and a user experience study we conducted with students. In Sect. 4, we present the lessons that we have learned from our study and our conclusions.

2 Personas

Personas can be useful to solve some main obstacles and traps in the product development process: the elastic user; the self-referential design; and design edge cases [10, 13, 14], and they limit the action space [13, 15].

The elastic user refers to the issue that without having a common framing, the “user” is - metaphorically spoken - stretched to justify any decision and feature of a product. The self-referential design points to the common mistake of developers putting themselves “into the seat” as the later users of a product; hence, ignoring the needs and goals of the real users. Personas can also provide guidance in political disputes and discussions on design edge cases, helping to decide the issue of whether a certain feature should be included or excluded in a product, or on issues of the general design approach. With personas, the blurry “user” becomes tangible - with specific needs and requirements. One can refer directly to “Anna” and state: “Yes, someone might want that feature, but we are not designing for someone - we are designing for Anna” [10]. If the usage of personas is engrained into the working habits of the project team from the beginning [14, 16], personas can indeed become a boundary object [9] among team members and stakeholders.

Personas support the “limitation of action space” pattern [13, 15] since they cluster the needs and requirements of a product’s end users by reducing the complexity from satisfying “the user”, a vague and unknown entity, to a manageable number of personas (cf. [29]).

2.1 Personas: Vehicle and Information

Personas are, in their essence, just a different form of conveying user needs and requirements in a product development cycle, mainly advocated by the scholar of user centered design. To understand this tool, one has to distinguish between the vehicle, which is the shape or appearance, respectively, and the information, transported in said vehicle.

According to Cooper et al. [10], the important information that is conveyed in personas are the goals and motivations of end user towards the usage of certain product [17]. These are usually gathered through interviews and observations. It is the narrative framing that forms the vehicle and brings a persona to life [13]. This framing puts a mental model into the reader’s head; it thus makes the behavior of that pictured personas vivid. To bolster the vividness, personas are usually accompanied by a photo, a name and other details that makes a persona an authentic character. Despite the fact that they are often called hypothetical users, personas are never an image or a representation of the average user-group, they are, as said, vehicles to communicate the important information – of real users – during product development in the most appropriate way for the development team.

The distinction between the information and the vehicle raises an interesting question: Can any form of information be more vivid and memorable if told by dint of personas – here, in the sense of wrapping something “bulky” up in the most delightful way for the audience? Much like one would hide a dog’s medicine, a “bulky” but important piece, in a sausage slice so that a dog would eagerly swallow it. This work explores to reveal principles of how this vehicle needs to be designed to create tension and support meaning making to make WCAG more comprehensible for beginners. Following the dog’s medicine analogy, WCAG is the “bulky” information and personas are the sausage.

2.2 Using Personas to Communicate the Relevance of WCAG Success Criteria

The benefits of personas as a vehicle to transport the needs and requirements of people with disabilities have been highlighted in various works, notably in tools and learning environments [18,19,20,21,22]. Besides [20], where personas with disabilities are used in the original fashion, these are all examples where the information that needs to be transported is the needs and preferences of the user group itself. This differs from the approach explored in our work. Here, the important information is not the needs and preferences of the user group but a set of rules. And these rules are not directly bound to the goals and motivations of a future user.

Ontologies have been developed [23, 24] to provide links between success criteria and impairments for which those criteria are considered essential. While these ontologies also make use of user entities similar to personas, they are dedicated to classifying the success criteria according to their relevance for certain impairments.

We envision to adapt the narrative persona concept to convey information outside its designated usage fashion, as introduced by Cooper [10]. The stories told by personas are tightly coupled with the information contained, or in other words, the stories are the information told in a narrative way. The information is constructed by clustering the goals and motivations of the end user towards a certain product. When using personas to communicate the relevance of WCAG success criteria, there are no goals or motivations directly involved to tell the story. People, artificial or real, are driven by motivations to reach a certain goal. When an application, for example a web shop, is compromised by defects that lead to barriers and hinders people from achieving their goals, then this application should adhere to WCAG. But, WCAG success criteria do not represent “goals” for users in any sense. This raises the question of what “items” the narrative nature of personas should be constructed of to convey the meaning for the success criteria (for details see Sect. 4).

3 The PersonaBrowser

In a web application called PersonaBrowser, we implemented a visualization of the connection between WCAG success criteria and personas for which the conformance of certain success criteria is essential. As a structural foundation, we used the ontology described in [23]. The PersonaBrowser illustrates nine personas, grouped into four categories of general impairment types: visual, auditory, physical, and cognitive. The personas are based on the “day-in-the-life” stories developed by the MOOCA project [27]. The term “persona” was actually avoided in MOOCAP to emphasize the fact, that they were created by experts and not by newly researched data. Nevertheless, the validity and the benefits of the MOOCAP’s stories for conveying the needs and requirements of people with disabilities have been presented in [19]. For their usage in the PersonaBrowser, we added additional web links featuring further information about the impairment and used assistive technologies. A user of the PersonaBrowser can read about a persona, their life, needs, and essential WCAG success criteria. We also provided a mechanism to filter the WCAG success criteria for each persona according to conformance levels and (on a second view) all success criteria according to impairments and conformance levels.

3.1 User Experience Study with the PersonaBrowser

Since novices could benefit from featuring WCAG in a human-centered fashion (cf. Sect. 1), we used the PersonaBrowser as a teaching tool in an introductory HCI course (jointly hosted by the bachelor course programs media informatics and mobile media at the Stuttgart Media University) to field-test the PersonaBrowser over a period of three months. The study consisted of two parts with different goals. In the first part, we wanted to get insights on principles of how personas should to be constructed to serve as proper vehicles for WCAG success criteria, by identifying current issues in linking success criteria and personas based on impairments; thus, tackling the question raised in Sect. 2.2. This part consisted of observations in the class when using the PersonaBrowser for teaching accessibly, and informal feedback from the students (Sect. 3.2). In the second part, we wanted to quantify the effect on a user’s experience with WCAG as generated by the means of personas. Therefore, we compared the user experience of the PersonaBrowser with that of the WCAG Quick Reference [25], which we used in a prior instance of the same course (with different students) as a teaching tool. The quantitative measurement of the user experience was based on the User Experience Questionnaire (UEQ) [26].

3.2 Results of the User Experience Study

For the quantitative comparison of the user experience between the PersonaBrowser and the WCAG Quick Reference, we included the WCAG Quick Reference in the PersonaBrowser, literally, with original colors and font styles as in the specification [25]. We surveyed 65 undergraduate students from two semesters, all novices in accessible design. One group of students (n = 38) worked solely with the PersonaBrowser, while the other group (n = 27) worked solely with the WCAG Quick Reference. We assessed the user experiences of both groups, using the User Experience Questionnaire (UEQ) [26] (see Fig. 1). In general, the UEQ yields the following aspects of user experience, including pragmatic and hedonic aspects: Attractiveness: Do users like or dislike the product? Perspicuity: Is it easy to learn how to use the product? (pragmatic). Efficiency: Can users solve their tasks without unnecessary effort? (pragmatic). Dependability: Does the user feel in control of the interaction? (hedonic). Stimulation: Is it exciting and motivating to use the product? (hedonic). Novelty Is the product innovative and creative? (hedonic). For each aspect, the scale ranges from −3 to +3 [28].

Fig. 1.
figure 1

Results of the UEQ. Comparison of scale means and the corresponding 5% confidence intervals.

Full size image

The UEQ considers scores starting at 0.8 as positive and starting at −0.8 as negative. The overall user experience is therefore, at best, in the scale of average, for both systems. It should be noted that the study took place within the context of a mandatory lecture and that the results could have been influenced by a rather low motivation of some participants towards the topic of HCI and accessibility. Nevertheless, our result shows the issues of the WCAG Quick Reference when it comes to its usability for beginners. We did not expect any significant differences in the pragmatic values (perspicuity, efficiency), since the only thing we added in the PersonaBrowser is the connection between success criteria and personas based on their impairments, but the higher efficiency score can be seen as a hint for the benefits of a user-centered presentation metaphor due to its complexity reduction (cf. Sect. 4). While the average scores of perspicuity, efficiency and stimulation are higher for the PersonaBrowser, the pertaining T-Tests showed no significant differences (α = 0.05). Only for novelty, the study reveals a significant difference between the PersonaBrowser and the WCAG Quick Reference. The UEQ score for novelty is still low, but this seems to be a hint that a user-centered presentation metaphor can be effective to catch the interest of web authors. While the PersonaBrowser has a higher efficiency score, the lower score for dependability was rather unexpected. This discrepancy can be explained under the spotlight of an issue that occurs if impairments are used as the only mean to link success criteria to the personas – the elastic system, see Sect. 4.

4 Discussion

We have learned some lessons from actively using the PersonaBrowser as a preparation tool for the accessibility course.

Elastic System.

Using only impairments as anchors to success criteria leads to an elastic system, where personas can be stretched to justify almost any success criteria. Personas are never an embodiment of the average user. Just because one persona can benefit of a success criterion does not mean that a second persona, sharing the same or similar impairment, can benefit from that criterion as well; especially if the two personas do not use the same assistive technologies. The link between a persona and a success criterion should always be reliable in the sense that it is clearly described why this criterion is considered as relevant and another not. Personas are specific and so are their impairments and needs. In the PersonaBrowser, we have two personas with macular degeneration (Maria and Monika). While Maria uses text-to-speech software to help her speed up things with office applications, Monika does not use any text-to-speech software. Maria therefore clearly benefits from the compliance of WCAG 2.0 success criterion 1.1.1 (“None-text content”). If we stated that Monika can also benefit from text-to-speech and therefore of success criterion 1.1.1, we would stretch Monika to fit our assumption that every person with macular degeneration can benefit from text-to-speech and so should Monika – even though the persona does not hold for this assumption. This would blur the personas towards average users and would therefore make them less precise. But, being precise and specific is what personas make vivid and suitable for the construction of a mental model [10, 13]. Therefore, the meaning should be constructed based on the entire persona (including its context) and not only on their impairments. Issues with this elasticity can also be seen in the average score for “dependability” in the user experience test (see Fig. 1).

Action Space Shift.

One exercise in the accessibility course was to examine a web application for barriers. This exercise was split up into three sessions each focusing on one WCAG principle. (Exception: Principles 3 and 4 were combined since principle 4 has only two success criteria.) The students using the WCAG Quick Reference had to state the conformance for all success criteria of a single principle during a session. Doing so, the complexity for the tutors was moderate, as they had to explain the success criteria of each principle once during a session. In contrast, the PersonaBrowser offers a more user-centered approach. A student had to pick a set of three personas for which they had to state the conformance of one principle per session. Since not every success criterion is relevant for every persona, the complexity for the students was reduced. At the same time, the complexity for the tutors increased, since they had to discuss every success criterion nine times during one session, one time for every persona. Combined with ambiguity due to the elasticity of the personas, the complexity was actually not reduced but shifted from the students to the tutors. While this might be unique for teaching scenarios, it advocates the meaning for precise personas.

WCAG as the Culprit.

From our observations, the descriptions of the WCAG success criteria, including what barriers they address and what needs to be tested for their assessment, were hardly read by the students using the PersonaBrowser. While the personas reduced the action space, the students often tried to conclude the implications of a success criterion by the needs of the personas and the heading of a criterion. This is probably triggered by the task given to the students, namely to state the accessibility for the chosen persona set. As one students puts it: “The vita of the fictitious people are cumbersome, if one is just interested in the impairments [hence, which criteria applies].” We have learned from this that — when used in the context of personas – the description of WCAG needs to be adapted in order to be told from the perspective of personas and in a more application-oriented manner (cf. [1]). This would better accommodate the needs of web authors, namely being able to assess the accessibility of their applications. The low result for “stimulation” in the UEQ (see Fig. 1) can be interpreted in light of this effect.

Barriers as a Tie to Wrap the Stories Around.

As described above, a mapping between a success criteria and impairments is not sufficient to establish a confident vehicle to convey the relevance and meaning of the success criterion. As in the example with ramps and stairs (Sect. 1), meaning for solutions is only created if the problem becomes obvious. Most success criteria are actually a set of solutions for which the problems are not evident. In the run-up of this study, we conducted a survey among accessibility novices. After working in accessibility and with WCAG for several months, we asked for their opinion on what would make accessibility resources more comprehensible. From 44 participants, a vast majority (86%) agreed that it would be helpful for comprehension to highlight the impact if a criterion is not met; hence, this empathizes the relevance of featuring barriers. This leads back to our question on how the narrative shape of a persona should be constructed to convey WCAG in a vivid way. We therefore argue that the barriers should be the center around which the stories are told.

This study provided insights into the status quo of a persona-centered presentation metaphor for WCAG, discussed the potential of such a system and outlined the issues that arise with it. We stated that using impairments as a link between personas and WCAG success criteria is not sufficient and creates an overly elastic system. Based on our experience and observations, we discussed some initial suggestions to overcome the issues. Yet, more research is needed e.g., to test if novices, using a system, built on the principles discussed here, will have a better comprehension of WCAG or the impact of said system on experts, since our initial study focused solely on novices and, as discussed in Sect. 4, there might be implications that are unique for teaching scenarios.