Keywords

1 Introduction

Assuming that a functioning digital society is able to ensure equal access to all inherent (digital) devices, content and applications [1, 2], it should be clear that when developing software and digital content there must be a continuous effort to make it as accessible as possible [3, 4]. However, and despite the various efforts to shed light on the issue of digital accessibility - and highlight its importance - [5, 6] much remains to be done [7].

The visually impaired are, by default, one of the communities of citizens (digital users) that stand to benefit from the use of digital devices and applications to help them during their daily tasks [8]. According to Sousa e Silva et al. [7] and Okonji et al. [9], visually impaired citizens are also avid users of digital devices, such as computers and smartphones, which they use to perform ordinary tasks such as reading online newspapers, reading and writing e-mails, and interacting with others through social networks and online communication services.

Though various authors [2, 10, 11] deem the aforementioned arguments critical and of vital importance, this topic has yet to receive the necessary attention from those who are primarily responsible for the development of accessible software: the developers. In fact, according to Bohman [10] and Gonçalves et al. [12], the majority of software developers demonstrate a serious knowledge gap when it comes to understanding the techniques and regulations associated with e-accessibility. This creates barriers for those with disabilities as they are unable to use the inaccessible software products, limiting their ability to become equal members of the society.

With this context in mind, the present research has been conducted in order to present a proposal for a set of recommendations to be incorporated into software engineering classrooms. In order to achieve this goal, an analysis of both existing scientific literature and current international accessibility regulations and best practices has been done.

In terms of structure, the present article is divided into six sections, the first being the introduction. Section 2 outlines an analysis of existing related work. Section 3 presents a survey, completed by 29 blind or partially sighted citizens, which characterizes how the respondents use their digital devices and applications. In Sect. 4, the research artifact, the “slide 0” proposal, is presented. Its implications for both theory and practice are discussed in Sect. 5. The sixth, and final, section presents the set of identified limitations, the future research activities that were considered, and some final considerations of the overall research project.

2 Background Work

2.1 Software Accessibility as a Research Topic

When analysing the existing literature, one can easily perceive that, as a concept, digital accessibility is defined in slightly different terms, according to the context in which the concept is being characterized [13].

As argued by W3C [14] “…the Web is fundamentally designed to work for all people, whatever their hardware, software, language, culture, location, or physical or mental ability. When the Web meets this goal, it is accessible to people with a diverse range of hearing, movement, sight, and cognitive ability…”. Despite distinguishing between accessibility and usability, W3C states that the terms overlap in several aspects. Regarding usability, W3C claims “…usability and user experience design significantly overlap with accessibility when “specified users” includes people with a range of disabilities and “specified context of use” includes accessibility considerations such as assistive technologies. However, the needs of people with disabilities are often not sufficiently addressed in usability practice and research. Additionally, accessibility includes a technical aspect that is usually not a focus of usability. In practice, basic accessibility is a prerequisite for usability…” [15].

As presented by Baptista et al. [5], the International Organization for Standardization has also presented its interpretation of the accessibility concept. ISO [16], which is a multipart standard that covers several aspects of ergonomics of human-computer interaction, and joins usability and accessibility. According to said standard, usability is the “extent to which a product can be used by specified users to achieve specified goals with effectiveness, efficiency and satisfaction in a specified context of use”. Despite focusing its attention on a full range of user characteristics and capabilities, with regard to accessibility, the ISO interpretation is not strictly limited to users of a formal disability.

The perception and characterization of accessibility has also been the work focus of various entities worldwide. Examples of this work are EU [17] standard in the accessibility requirements for public procurement of ICT products and services in Europe (en301549), and US-GSA [18] Section 508 that enforces accessibility and usability constraints to public ICTs.

Standard en301549 was developed by the European Telecommunications Standards Institute (ETSI), as a result of Mandate 376, which covers accessibility requirements for public procurement of products and services in the ICT domain. This regulation is intended to join, in a single source, detailed, practical and quantifiable functional accessibility requirements. It takes into consideration the global initiatives in this field, which are applicable to all ICT products and services. Hence, it is supposed to be used in public procurement, and as a source of information to make conformity assessments.

Public procurement can be an important instrument to prompt accessibility. It is critical that procurers make clear and very well-defined requirements. To make this happen, en301549 has, in “Chap 4 - Functional Performance”, and in “annex C - Determination of Compliance”, respectively, information to help procurers to make a clear definition of accessibility requirements, and tools to guide them on their assessment and evaluation of compliance levels.

Standard en301549 is also envisioned to be a critical document to be followed by all ICT developers, considering its high level of detail, ease of access, and organized structure.

As stated, en301549 takes into account global initiatives in this field. Therefore, ISOs and WCAG are assimilated into it.

2.2 Analysis of the Needs Presented by Impaired Users When Using Software

Accessible software benefits all users, not only those with disabilities or impairments [19]. Although this fact should be enough to make every developer want to produce accessible software, and every stakeholder request it, the actual situation is still very far from this [6, 12]. Hence, the world does not seem to be going in that direction.

In order to assess how the scientific community is approaching the digital accessibility issue, a direct analysis has been made of six of the most relevant international scientific repositories (Web of Science, Science Direct, IEE Xplore Digital Library, SpringerLink, Wiley Inter Science Journal Finder, and IET Digital Library), by searching their content using the following keywords as filters: “software accessibility”, “digital accessibility”, “Web accessibility” and “mobile accessibility” (Fig. 1).

Fig. 1.
figure 1

Number of occurrences of “Software Accessibility” (SA), “Web Accessibility” (WA), “Digital Accessibility” (DA) and “Mobile Accessibility” (MA) as key words in relevant scientific repositories.

Full size image

By analysing these indicators, it is evident that the topic of digital accessibility, and more specifically the production and delivery of accessible software, has yet to be properly considered by the scientific and academic communities. Hence, these facts can have a major negative influence in spreading digital accessibility concerns, research, and routines.

As argued by Draffan et al. [20] and Gonçalves et al. [21], digital accessibility is also not suitably taught, nor applied, in academic environments, hence the need to change mentalities and develop not only the existing theory on the topic, but also to present improvements and developments to existing practical approaches when developing software.

3 Blind Users and Software

There have been several assessments of digital accessibility. One example, the Study on Assessing and Promoting E-Accessibility, endorsed by the European Union and published on November 2013 [22], tested e-accessibility compliance in 27 European countries and, not surprisingly, indicated that much work needs to be done in this area.

In July 2015, WebAIM conducted a survey of screen reader software from all-over the world [23], where a total of 2515 responses were validated. This survey included questions on both the screen reader software – e.g. what screen reader was being used, what operating system was being used – and the user’s opinion about the evolution of Web accessibility. Also, the survey enquired about some more specific e-accessibility problems – e.g. accessibility in PDF files. However, this survey seems to assume, as its baseline, a number of unclear arguments and certainties which are in fact also ignored by many stakeholders. Namely, the survey asked about Web accessibility on news websites. This may lead to the conclusion that those who work with disabled people, know, empirically, that this section of the population are consumers of this type of content. Although this is a strong belief, some background work seems to be missing in order to validate this same belief, since e-accessibility is clearly not well addressed.

Digital accessibility has the potential to change the life of several groups of people with disabilities. It means that people with disabilities may have the chance to participate more meaningfully in society. However, not everybody can use the resource equally [24]. For example, visually impaired people can now, perhaps for the first time in history, read a book, outside, using mainstream equipment such as a smartphone, or a tablet. Also, this group of people now has the possibility to have a portable dictionary. Continuing with the same example of visually impaired people, it is now possible to read a newspaper, accessing news at the same time as a sighted person. And, if they are using a mobile device, it is now possible to use the time in a waiting room, or seated at a cafe, to read. Simple things, like consulting the information of a product, are now reasonably easy activities, or even making a purchase using an accessible device with accessible software. Through the Internet, in an accessible manner, a blind person can manage to listen to a specific radio, or TV channel, overcoming the inaccessible devices such as set-top boxes. Several groups of people are now able to communicate, using social media, either because it is accessible by screen reader, or it is possible to use written communication, or it is simply convenient if, for some reason, the person cannot leave the house. For a visually impaired person, it is now possible to be independent in written communication, in an accessible manner, providing him another level of independence and privacy, just because they can have access to mobile service and e-mails. The facility to have a video call is simply astonishing for a deaf person, who can now use his lip reading abilities or a gestural idiom. The possibilities are so extensive that now, a blind person can use a mobile application to call a volunteer, who, through a video call, can help the blind person, using their vision instead of the blind person. Also, it is possible to have an optical character recognition application in a smartphone, that can be used, by a blind person, to check a bill, or the mail. Another possibility is to use a mobile application to overcome closed functionality equipment, such as a ticket machine, or a printer with just a tactile screen, without speech output [8, 25]. Naturally, for all of this to come to fruition the software has to be accessible.

3.1 Analysis of the Needs Presented by Impaired Users When Using Software

With the goal of creating a better understanding that could sustain a stronger approach to e-accessibility, a survey, directed at blind and partially sighted citizens, has been conducted. The execution of the survey was supported by the Portuguese Association of Blind and Partially Sighted People (ACAPO) which invited 29 of its associates to answer a number of questions. This survey’s initial results (sample of 15 complete answers), was presented to the public in [7].

From a conceptual perspective, it was important to characterize the sample of citizens who answered our survey. As is clear from Fig. 2, the majority of the respondents were between 30 and 59 years of age, which, from our perspective, indicates some maturity and life experience.

Fig. 2.
figure 2

Target group age dispersion.

Full size image

A more incisive analysis of the respondents’ answers (Fig. 3) indicates that despite the inherent limitations, the majority of the questioned participants do use the computer and the smartphone in their day-to-day lives.

Fig. 3.
figure 3

Devices used by the survey respondents.

Full size image

3.2 Results Presentation and Analysis

The survey intended to highlight the importance of digital interaction and the inherent need for all software (regardless of its nature) to be accessible to all users. In order to reach the aforementioned goal, the survey questioned its respondents on the extent to which they incorporated digital devices and activities into their daily lives.

An initial analysis of the provided answers showed that more than 90% of all respondents use digital devices on a daily basis for tasks as simple as reading, working or interacting with others. From a more technological perspective, it was also possible to see that about 80% of the respondents access the Internet from their device using the provided Internet browsers. Figure 4 shows what the respondents use the Internet for.

Fig. 4.
figure 4

How target group members use the internet.

Full size image

A proper analysis of Fig. 4 clearly reveals the importance of advocating for accessible software. If we extrapolate the current survey sample to a national, or even international, level, one can perceive that mundane tasks such as reading and sending e-mail messages, using social media, using search engines or even using news websites, are on the list of the most recurrent activities of those who are blind or partially sighted.

Despite the importance of digital public services in order to ensure equality in the ability to reach all types of public services (social security services, tax services, etc.) [26], only a small minority of survey participants admitted to having used digital public services to take advantage of the immense possibilities associated with it.

4 Liking Accessibility and Software Projects During Expert Training States – Slide 0

In order to spread e-accessibility awareness among developers, the topic should be taught in the academic environment. As shown, this topic – e-accessibility – is extremely under-addressed. The topic is so poorly taught that it requires a baseline to even start the learning process. Due to this lack of discussion, in combination with the overwhelming number of documents regarding e-accessibility, a good starting point would be to relate each type of document to its appropriate type of user interface. We believe that this would save a lot of research and useless reading. Therefore, below, a Table 1 is presented as a proposal for an e-accessibility slide 0:

Table 1. Relationship between each type of document and its appropriate type of user interface.
Full size table

4.1 Web-Based Software Development

As for Web User Interfaces, Web Content Accessibility Guidelines from the World Wide Web Consortium are the recommended accessibility standards from many organizations – including governmental organizations – for the establishment of an accessible Web for people with disabilities [27]. It is comprised of guidelines, and checkpoints, to ensure a certain level of accessibility addressed to specific disability-related problems. These guidelines are included in en301549, therefore, if a person follows Chap. 9 of that standard, the outcome will be WCAG compliant. Also, if the user of en301549 wants to consult the WCAG, a copy of it can be found in annex A of en301549. In case the desired product has a Web user interface, the correct use of the WCAG, or Chap. 9 of en301549, will ensure that the user interface is as good as the level and quality of the implementation of these guidelines. It is important to understand that following the WCAG, or Chap. 9 of en301549, may not be enough. Web projects can be huge, and include several different types of content. For example, if the Web project has a video asset, the developers might need to follow Chap. 7 of en301549, which covers ICT with video capabilities. Furthermore, if the Web project will have an area to distribute documents, those documents have to be under the recommendations depicted in Chap. 10 of en301549, which has the information about non-web documents.

It is important to keep in mind that Web accessibility is a very complex and broad topic. This means that not everybody has to know it fully. Following these guidelines can be seen as a shortcut to achieving Web accessibility, using the knowledge of a group of specialists that have spent their effort and expertise to develop these guidelines.

4.2 Development of Native Applications with Standard Controls

For Native Application with standard controls, the human interface guidelines from the host operating system are mandatory, in case developers want to create a GUI akin to the operating system style. It is relevant to mention that when a developer keeps the same graphic style from the host operating system on his application, he is already increasing the level of accessibility, since the interaction will be similar to the rest of the system. Therefore, there is probably no need for a specific learning curve. Using standard graphical components, the developer would not have to make them particularly accessible, since they are already built with the accessibility features provided by the accessibility APIs. Consequently, using the standard components, developers would just have to consult the accessibility programming guide of the host operating system in order to use those components accurately.

4.3 Development of Native Application with New UI Components

When developing native Applications with UI components made from scratch, developers may follow the same approach as in the previous paragraph, and in addition, study the documentation regarding the Host operating system accessibility APIs in order to implement them in the right way on their new and personalized graphical components. Only after this will the UI be accessible. In a situation like this one, it is strongly recommended that the developer read Chap. 11 of en301549. This paper covers non-Web software. There, it is possible to find a lot of information that will allow the developer to better understand and correctly implement what he has read regarding accessibility for his chosen platform. It is important to emphasize that software accessibility is a very important, complex, and broad topic. To make accessible software, a lot of work and testing is required. Choosing to build graphical components from scratch, means that a lot of accessibility research and projection will be wasted. Operating systems like some versions of Windows, iOS, Android, MacOS, etc. already have a lot of work done regarding accessibility. When choosing not to use standard graphical components, the developer must be aware that he is wasting a lot of work that someone else has already done, during the platform’s UI development. In a situation like this, developers might find Chaps. 4 and 5 of en301549 helpful. These chapters talk about functional performance and generic requirements. They will be mentioned in more detail in Sect. 4.5.

4.4 Development of Complex Software Systems

For the creation of a bigger UI for a larger software system, such as an operating system, the recommendation is to use the ISO 9241-171:2008 - Ergonomics of human-system interaction – Part. Prepared by Technical Committee ISO/TC 159, Ergonomics, Subcommittee SC 4, Ergonomics of human-system interaction, this ISO “provides ergonomics guidance and specifications for the design of accessible software for use at work [18], in the home, in education and in public places”, as stated in its abstract. This should be the guidance for a big, new UI, built from scratch.

4.5 Development of Complex Software Systems

In addition to this guidance, there are some specific governmental rules, such as Section 508 from the United States of America [19], which may be consulted. However, the above recommendations overlap with these governmental guidelines. Actually, these national recommendations, such as the Brazilian eMAG - Modelo de Acessibilidade em Governo Eletrônico [28], are in line with the international recommendations mentioned above. Although ISO 9241-171 can be used, en301549 can be used instead of it. As mentioned, it includes global accessibility initiatives, including ISO 9241-171. Standard en301549 has the advantage of being free of charge.

In Chap. 4 of en301549, developers, or procurers, can find the functional performance statement. This means that it will be possible to read what functionality is required to satisfy a particular user need. This paper explains how to enable users to locate, identify, and use functions, regardless of their abilities. This is very important to have in mind before looking for the technical requirements that are depicted in the later chapters of en301549. Annex B of en301549 is a very good tool to make the relationship between the technical requirements and the user needs as it is intrinsically connected with Chap. 4. It is intended to help to map the technical requirements to the user needs, and consequently, to meet the functional performance statements. This paper is a very good and very important starting point. After knowing the relevant information presented in Chap. 4, developers should go through Chap. 5. Chapter 5 of en301549 covers generic requirements. This means that it has information about accessibility requirements, regardless of technology. So, it has requirements that can be used across different types of ICT projects and services – e.g. vending machines; ticket machines; white technology user interfaces; and graphical user interfaces of operating systems. It is important to emphasize that not all the requirements have to be used at the same time. Instead, just the relevant requirements for the project should be taken into account. Picking the example of a vending machine that sells drinks and snacks, the developers should pay attention to Chap. 4, and, for example the first part of Chap. 5, 5.1, which talks about closed functionality. Closed functionality means that a user cannot adjust the setting, and cannot install or connect personal assistive technology. This is very common in this type of machine. Therefore, the developer has to know how to overcome the obstacle, and make it operable for all users.

Continuing with the same example, developers should use the recommendations of Chap. 8 of en301549, which deal with hardware. There it is possible to find recommendations regarding mechanically operable parts - Chap. 8.4 - and physical access to the hardware - Chap. 8.3- so that, for example, a person using a wheelchair can get close enough to use it properly. In a project like this, it is very important to keep in mind that accessibility is not something that can be planned in an inattentive manner; it will probably require specialists in several accessibility areas.

5 Discussion

5.1 Theoretical Implications

The clarification of the reason and contents of the previously mentioned documentation may also encourage many professors who, after this, may feel confident enough to incorporate digital accessibility into their classroom topics and spread awareness of the issue.

This paper has the potential to break several myths regarding digital accessibility – e.g., If a blind person has screen reader software, everything is already ok; If a website has passed through an automatic accessibility validator, it means that it is ok; If the OS for which an application is being developed is accessible, further effort regarding accessibility does not have to be made.

If a teacher gets in touch with digital accessibility, he may do his work while including digital accessibility – e.g. slide presentations; supporting documents; supporting programming code assets; scientific research. After a student who has been exposed to this knowledge goes to the job market, his concerns may also include digital accessibility.

After some generations of students have been exposed to this knowledge, digital accessibility may be, finally, part of the mainstream. Everybody that is exposed to this knowledge, may become more aware of the difficulties of several groups of people with disabilities, thereby increasing the awareness of how to interact with a person with impairments, becoming able to make more informed judgments about these individuals.

5.2 Practical Implications

Slide 0 introduces a clarification of the reason and contents of the aforementioned documentation. This contribution leads to a simplification of presenting the means to implement digital accessibility. The immediate access to this knowledge, instead of being a finding, reduces the attention, work capacity, and time to what really matters, thus, to the learning and implementation of digital accessibility. The access to this relation between type of projects and its appropriate documentation, avoids mistakes that cause problems in the accessibility of a project - e.g. using an OS accessibility paradigm in another OS; trying to make creative solutions instead of using the existing, proper, and studied solutions.

6 Conclusion

6.1 Limitations and Future Work

This research was constrained by the lack of research focused on the topic of digital accessibility, as shown in Sect. 2. Also, the groups of people which have an interest in this type of work are not easily reachable, to respond to questionnaires, and are also relatively small in number. Lastly, their impairments make it harder for them to meet researchers, and limit their independence in answering the surveys.

An important part of the process is to set accessibility steps in how software is developed. This work is already in progress. To motivate developers to implement accessibility in software, promotional work to make evident the different benefits of accessibility is envisioned for the future. This work could range from automated software testing or, to the best of our knowledge, a totally new area of study concerning system integration through accessibility. This research is intended to help in mitigating first and foremost the lack of research in the area of digital accessibility, which is a stated constraint. Establishing connections between organizations of impaired people is also envisioned, with the goal of reaching a bigger universe to respond to the questionnaire, thereby strengthening the impact of the collected results.

6.2 Final Considerations

Digital accessibility is a very under-implemented feature. Those with decision-making power are not likely to actually care or even know enough about it. Since software accessibility is not being fulfilled, and its power is under-evaluated, a possible and reasonable solution would be to address it in the academic environment. Since the topic is under-addressed in the academic environment, and it seems that there is a lack of information regarding the topic, the information presented in the previous section was designed to be an easy and informative first approach for its implementation. It was designed to relate the right documentation to each type of UI, thereby removing a complexity barrier in its implementation by filtering the enormous amount of documentation regarding the topic.