# Universal Design of Information Sharing Tools for Disaster Risk Reduction

Jaziar Radianti, Terje Gjøsæter, Weiqin Chen

<figure><img src="image_1.png" /></figure>

## To cite this version:

Jaziar Radianti, Terje Gjøsæter, Weiqin Chen. Universal Design of Information Sharing Tools for Disaster Risk Reduction. 2nd International Conference on Information Technology in Disaster Risk Reduction (ITDRR), Oct 2017, Sofia, Bulgaria. pp.81-95, 10.1007/978-3-030-18293-9_8. hal-02280324

HAL Id: hal-02280324

https://inria.hal.science/hal-02280324

Submitted on 6 Sep 2019

HAL is a multi-disciplinary open access
archive for the deposit and dissemination of sci-
entific research documents, whether they are pub-
lished or not. The documents may come from
teaching and research institutions in France or
abroad, or from public or private research centers.

L'archive ouverte pluridisciplinaire HAL, est
destinée au dépôt et à la diffusion de documents
scientifiques de niveau recherche, publiés ou non,
émanant des établissements d'enseignement et de
recherche français ou étrangers, des laboratoires
publics ou privés.

<figure><img src="image_2.png" /></figure>

Distributed under a Creative Commons Attribution 4.0 International License
# Universal Design of Information Sharing Tools for Disaster Risk Reduction

Jaziar Radianti<fnref n="1" />, Terje Gjøsæter<fnref n="2" />, Weiqin Chen<fnref n="2" />

**Abstract.** Disaster information sharing tools are an important aspect of disaster resilience, and it is of utmost importance that these tools are accessible and usable for as many potential users as possible. In this paper, we evaluate the accessibility of a selection of tools for crowdsourcing disaster situation in-formation. As our evaluation shows that the selected tools are not fully accessible, we provide rec-ommendations for mitigation, as well as highlight the importance of further re-search in this area.

**Keywords:** Disaster information sharing tools, Disaster resilience, DRR

## 1 Introduction

A majority of the world's population now lives in urban areas. Several global reports concern this rapid urban growth symptom introducing new vulnerabilities and increas-ing risk of disasters, e.g. more people living in disaster-prone areas. One of the vulner-able groups are people with disabilities. UNISDR global survey involving 5717 re-spondents worldwide on People with Disabilities (PWDs) indicates that PWDs are rarely consulted about their needs in potential disaster situations. Majority of them nei-ther have participated in community disaster management and risk reduction processes currently in place in their communities, nor have a personal preparedness plan in the event of a disaster. In fact, these PWD respondents face some hazard risks, especially, floods, extreme weather, tornadoes, earthquake and cyclones [1].

Stough and Kelman [2] documented narratives from disaster survivors with disabil-ities and find that they are characterized by passivity, helplessness and a lack of resili-ence. The narratives also reveal the barriers where both social and environmental fac-tors prevent them from being fully included in their communities and from participating in the disaster risk reduction. At the organizational level, the practice of exclusion of the diversity of people causes the emergency services to not be well prepared to handle all forms of disabilities.

With today's development on the Information and Communication Technology (ICT), both scientists and practitioners concur that appropriate ICT technology can im-

<footnote n="1">¹UiA, CIEM, Dpt. of ICT, Jon Lilletunsvei 9,N-4879 Grimstad, Norway
jaziar.radianti@uia.no</footnote>

<footnote n="2">²OsloMet, Dpt. of Computer Science, Box 4, St. Olavs Plass, N-0130 Oslo, Norway
{terje.gjosater, weiqin.chen}@hioa.no</footnote>
prove disaster management and crisis communication in all cycles: preparedness, re-
sponse and recovery in terms of the needs of PWDs [3, 4].

The accessibility of crisis communication tools intended for enhancing societal re-
silience has not yet been fully taken into account. These tools are particularly important
for reaching out to the vulnerable groups in the societies, including PWD, especially in
highly populated and dense areas such as cities.

The Hyogo Framework Action (HFA) outlines the importance for building the resili-
ience culture in all levels, and encourages pro-active community participation [5]. Re-
silience itself has been defined as “the capacity of a system, community or society po-
tentially exposed to hazards to adapt, by resisting or changing in order to reach and
maintain an acceptable level of functioning and structure”[6].

However, HFA has little attention toward the needs of PWD although Phibbs et. al. [17], for instance, try to clarify the linkage between emergency management agencies working with PWD and the HFA. The issue of PWD are defined better in the Sendai Framework for Disaster Risk Reduction (SFDRR) [7] which also addresses themes linking the PWD and universal design.

First theme is related to universal design with support tools and build environment.
Ramps, for instance, assists PWD in disasters, such as fastening the evacuation of peo-
ple with wheelchairs. With universal design, the build environment should not put the
vulnerable people in a disadvantaged group in a disaster. Second theme emphasizes
inclusivity of disaster preparedness, response and mitigation activities. This approach
incorporates the needs and viewpoints of other marginalized groups and potentially
strengthens overall resilience. Third theme deals with accessible technology and com-
munication during the disasters. Fourth theme highlights the importance of stakeholders
such as individual person with disabilities and disability organizations to collaborate
during the emergency-cy planning and recovery. In brief, the concepts of inclusion,
universal design and accessibility have been included in SFDRR to empower
people with disabilities in disaster and eventually strengthen the community resilience
in general.

In the context of community engagement, the role of ICT tools to enable the society
in general to adapt and recover from hazards and stresses is evident as reflected in one
of the pivotal themes in SFDRR, especially to ensure that the crisis information flows
smoothly to the intended audience. Many ICT tools have been created for alerting citi-
zens and for community engagement purposes, which allow information flows from the
public to the government, from government to public, or information sharing among
communities [3, 8-13]. Typically, information sharing tools are provided in the form of
web sites or mobile phone apps. The question is then: have these tools taken into ac-
count the universal design aspect into the tool development process?

Universal design is the design of products and environments to be us-able by all people, to the greatest extent possible, without the need for adaptation or specialized design. However, in this paper we refer to universal design primarily in terms of web accessibility. According to WAI/W3C, for the web, accessibility means that people with disabilities can perceive, understand, navigate, and interact with websites and tools, and that they can contribute equally without barriers [14]. For the purpose of ensuring accessibility of web pages, the Web Content Accessibility Guidelines
(WCAG) have been developed, currently at version 2.0 with a new version 2.1 in the pipeline. These guidelines include success criteria that can be used to evaluate the accessibility of web pages.

Our research goal is to identify the accessibility issues in the tools for disaster resilience and provide recommendations for improvement. We will in particular focus on accessibility of web-based information sharing tools for disaster resilience.

**1.1 Research Question**

Our main research question in this paper is to what extent universal design and accessibility has been taken into account in existing samples of engagement tools in selected countries intended for disaster resilience. To answer this question we conduct tests based on WCAG 2.0 on samples of pages from selected information sharing tools.

**1.2 Organisation**

The rest of the article is organised as follows. Section 2 briefly cover related work. The method is explained in Section 3. The results of the tests are reported in Section 4, and discussed in section 5. Section 6 concludes this paper and lays down our future research agenda.

**2 Literature Review**

Disaster management and crisis communication that support and include PWDs have been discussed in the literature [2, 3, 6-12, 15-17]. Alexander [18] makes clear the distinction between disaster management and response for the general public and measures also intended to accommodate PWDs where the latter requires a specific adjustment that can ensure inclusivity.

According to Stough and Kang [7] "Accessibility" within the disaster context not only refers to physical access to emergency evacuation vehicles and shelters but also access to emergency communications and disaster resources. The term "inclusive" within the disability community is used to convey the notion that people and societies should accommodate the needs of people with disabilities. Community engagement through ICT supported tools has been proposed as a way to improve resilience. The understanding of the ecosystem concerning PWDs at the micro, meso, exo and macro levels are highly important to get a comprehensive understanding on response to reduce the disaster risks [19]. In this paper, we will focus on the universal design of communication technology support, especially web accessibility.

Literature [18, 20] point out the importance of information systems (ISs) for crisis response and management for supporting people with disabilities and other vulnerable groups, which is in fact often overlooked by emergency response organizations in rescue operations. This literature, however, only identifies the gap in current practice where information on the vulnerable groups is not included. The recommendations to improve this situation, among other things are to include this information in the ISs for
emergency response [20] and to improve the coordination among the agencies that deal with the needs of PWD.

Kent and Elis [11] discuss the use of social media mash-up (Face-book, Twitter, YouTube) as communication channels for disaster situations that are not always accessible for PWDs. They extend the definition of disability to also include digital disability, in terms of access communication and internet. This is because digital disability affects a person's ability to survive in a disaster. The study reveals that Twitter, Facebook, and MySpace, for example, are inaccessible for people with disabilities [10, 11]. Despite lacking the inclusivity and universal design principles, these social media are continuously recommended [12] as alternative tools to increase community engagement that eventually will improve the community disaster resilience. Likewise, adoption of the alert systems for emergencies using mobile phone is growing, but still the needs of people with disabilities are not entirely addressed. For example usage of visual symbols depicting threats and appropriate actions are rarely taken into account [10]. Therefore, Hakkinen et al. [9] address that the development of accessible web content has allowed software developers to render information in a combination of synthetic or natural speech, in Braille, and visually, with the styling of the presentation to include speech and non-speech cues. Hence, the information is accessible to PWDs.

On the use of technologies to improve accessibility, Kenneth et al. [3] suggest the use of wireless technologies to empower PWDs regarding individual preparedness (technology outreach), response (warning and reaction), recovery (enable location of accessible shelters) and mitigation (wireless technologies integrated into post-disaster reconstruction). Kenneth et al. provide an excellent, comprehensive framework on the use of wireless technologies and how it helps PWDs, at different emergency management stages and different ecosystems of PWDs at micro, meso, exo and macro levels. However, many of these futuristic technologies have not yet been embraced in current disaster management practices, and how far the web-based platform will be a part of the suggested future disaster response are still vague. Therefore, despite sounding promising in improving accessibility for PWDs, it is still hard to evaluate the practical implementation of these notions.

While web accessibility testing is a quite common approach to testing webpages, studies that focus on accessible web information for emergency management are rare. We found literature on web accessibility testing for emergency webpages, for example, Wentz et. al. [21]. The authors evaluate the accessibility of 26 emergency alert sign-ups in Massachusetts, New York, and Maryland, and point out that the sign-up process for emergency-related information is in fact inaccessible. An extensive hybrid approach, i.e. a usability test and an expert inspection is applied. The inspection tasks focus on accessibility of the link to the sign-up page, the description, the form field, button labels, required field notification, CAPTCHA, progress indicator and alternative mean to register the alert service. The authors found that out of 26 sign-up pages, 21 have one or more accessibility violations. Slightly different in our study, we evaluate the content of webpages for information sharing in crisis situations using automatic tests, and we do not look at the login process of the selected webpages listed in Section 3.1.
To sum up, there are increased global awareness on inclusive emergency manage-
ment, and efforts to empower and build resilience among vulnerable groups including
PWDs with the help of technology, but still, universal design and accessibility are lack-
ing at the practical level.

3 Method

In this section, we cover the test method, metrics and tools for assisting in the testing,
as well as the selection of tools to be evaluated.

3.1 Selection of Information Sharing Tools for Evaluation

Ushahidi [22] or Google Crisis Response [23] are examples of platforms for community mapping. Some of these ICT-based tools support crowdsourcing. In different countries, smartphone apps for emergencies have been widely used as communication tools by the government such as FEMA App, Hurricane App (USA), Disaster Alerts, Emergency+, First Aid or Fire Near Me (Australia). Globally, some apps have been developed to alert of earthquakes such as QuakeWatch [24], Earthquake bud-dy [25] or Disaster Alert [26]. Other platforms include Wiki for professionals [27] and Emergency 2.0 Wiki [28].

For this evaluation, we have selected the tools Ushahidi Syria-tracker, Google Crisis Response Person Finder demo, Quake Watch Prediction Center, Wiki for professionals and Emergency 2.0 Wiki.

3.2 Test Metrics

For evaluation of the selected tools, we have primarily used automatic evaluation based
on Web Content Accessibility Guidelines (WCAG) 2.0. WCAG 2.0 is divided into 4
primary principles. A web page should be: perceivable, operable, understandable, and
robust. Based on these principles, 12 guidelines are stated. They provide the objectives
for accessible web design, but are not testable as such. Therefore, each guide-line comes
with success criteria that can be tested either automatically or manually. These success
criteria facilitate conformance testing, and the automatically testable subset of these
success criteria provides the basis for the evaluation performed in this paper.

WCAG 2.0 defines three levels of conformance, A, AA and AAA (the highest), to be achieved depending on which success criteria are passed. Usually, AA is recommended as a target for conformance testing instead of AAA, as stated in the documentation for WCAG 2.0 "It is not recommended that Level AAA conformance be required as a general policy for entire sites because it is not possible to satisfy all Level AAA Success Criteria for some content." [29] Conforming to Level AA means that all success criteria for Level A and AA are passed.
## 3.3 Selection of Automatic Evaluation Tool

Several tools both commercial and free are available for automatic checking of WCAG 2.0 compliance. Example of free tools are AChecker [30] and Mauve [31], while power mapper, Siteimprove, and FireEyes are examples of commercial ones. We needed a tool that could support WCAG 2.0 tests, and support validation through URL, HMTL file upload or direct html input. In this work, we have selected AChecker since it satisfies these requirements.

## 3.4 Test Method

We have selected a sample of 2 pages from each site, the main page, and a page related to information submission. This is to check if the crowdsourcing functionality is accessible. Normally one can put the URL of the page to be tested and AChecker will provide the test results. In our test, we found that if we give the URL, Syria Tracker serves a blank page. Therefore, we opened each web page to be tested in the Google Chrome browser (version 60.0.3112.113), and pasted the page source into AChecker.

The following options were selected in AChecker:

* HTML Validator is enabled.

* WCAG 2.0 (Level AA) is selected as conformance level to check against.

The validation of the HTML source is an extra check to verify that the page complies with the HTML standard. Although many web browsers are quite capable of repairing broken HTML, valid HTML ensures that the page can be read with a variety of user agents (web browsers) including screen readers and other assistive technologies.

Some tests are not fully automatable. In addition to known problems, AChecker reports issues that are likely problems and potential problems. Both of these classes of issues require manual verification, and the difference is that while likely problems refer to an element or combination of elements that tend to indicate a problem, potential problems refer to common web page elements that has potential problems, and while there are no specific indications that there are problems present, it cannot be determined automatically. Here, we have performed a manual check on all reported likely problems.

# 4 Experiments

In this section, we report the results of testing the web site primary page (not necessarily the front) and information submission page of the selected web sites using AChecker against WCAG 2.0 level AA.

## 4.1 Results Overview

Tables 1 and 2 give an overview of the problems detected by AChecker for the main pages and the information submission pages, respectively. They are divided into known
problems (problems identified with certain-ty), likely problems (probably a problem but require manual check to be certain), and potential problems (problems that may or may not be pre-sent, and require human interaction to determine). In addition, we asked AChecker to report HTML Validation errors, as mentioned above in the Method section. In the tables we also provide the URL to the tested page.

<table><caption>**Table 1.** Overall Results Main page (AChecker)</caption><thead><tr><th></th><th>Known Problems</th><th>Likely Problems</th><th>Potential Problems</th><th>HTML Validation</th></tr></thead><tbody><tr><td>Ushahidi Syria Tracker<br>https://syriatracker.crowdmap.com/</td><td>6</td><td>1</td><td>308</td><td>11</td></tr><tr><td>Google Crisis Response Person finder demo<br>https://google.org/personfinder/demo</td><td>1</td><td>1</td><td>68</td><td>0</td></tr><tr><td>Quakewatch Prediction Center<br>http://quakewatch.net/predictioncenter/</td><td>8</td><td>3</td><td>190</td><td>0</td></tr><tr><td>Crisis Communication Wiki for prof.<br>http://www.crisiscommunication.fi/wiki/</td><td>19</td><td>1</td><td>267</td><td>0</td></tr><tr><td>Emergency 2.0 Wiki<br>http://emergency20wiki.org/wiki/index.php/</td><td>16</td><td>1</td><td>266</td><td>22</td></tr></tbody></table>

<table><caption>**Table 2.** Overall Results Information Submission page (AChecker)</caption><thead><tr><th></th><th>Known Problems</th><th>Likely Problems</th><th>Potential Problems</th><th>HTML Validation</th></tr></thead><tbody><tr><td>Ushahidi Syria Tracker<br>https://syriatracker.crowdmap.com/re-ports/submit</td><td>85</td><td>1</td><td>300</td><td>10</td></tr><tr><td>Google Crisis Response Person finder d.<br>https://google.org/person-finder/demo/query?role=provide</td><td>1</td><td>1</td><td>66</td><td>0</td></tr><tr><td>Quakewatch Prediction Center<br>http://quakewatch.net/forums/</td><td>16</td><td>0</td><td>212</td><td>0</td></tr><tr><td>Crisis Communication Wiki for prof.<br>http://www.crisiscommunication.fi/index.php?option=com_users&view=registration</td><td>1</td><td>0</td><td>171</td><td>0</td></tr><tr><td>Emergency 2.0 Wiki<br>http://emergency20wiki.org/contact-us</td><td>12</td><td>1</td><td>522</td><td>62</td></tr></tbody></table>

## 4.2 Known Problems

Tables 3 and 4 show the detected known problems, with a reference to the success criteria in question. The referenced guidelines and success criteria are provided in sub-section 4.5.
<table><caption>**Table 3.** WCAG 2.0 AA Known Problems for Main page (AChecker)</caption><thead><tr><th></th><th>Perceivable</th><th>Operable</th><th>Understandable</th><th>Robust</th></tr></thead><tbody><tr><td>Ushahidi Syria Tracker</td><td>1.3.1a</td><td>2.4.6</td><td>3.3.2</td><td>4.1.1</td></tr><tr><td>Google Crisis Response Person finder demo</td><td>1.3.1a</td><td></td><td></td><td></td></tr><tr><td>Quakewatch Prediction Center</td><td>1.3.1a, 1.4.4</td><td>2.4.4a</td><td>3.3.2</td><td>4.1.1</td></tr><tr><td>Crisis Communication Wiki for professionals</td><td>1.4.4</td><td>2.4.4a</td><td>3.3.2</td><td>4.1.1</td></tr><tr><td>Emergency 2.0 Wiki</td><td>1.1.1, 1.4.4, 1.4.6</td><td>2.4.6</td><td></td><td></td></tr></tbody></table>

<table><caption>**Table 4.** WCAG 2.0 AA Known Problems for Information Submission page (AChecker)</caption><thead><tr><th></th><th>Perceivable</th><th>Operable</th><th>Understandable</th><th>Robust</th></tr></thead><tbody><tr><td>Ushahidi Syria Tracker</td><td>1.3.1a</td><td>2.4.6</td><td>3.3.2</td><td></td></tr><tr><td>Google Crisis Response Person finder demo</td><td>1.3.1a</td><td></td><td></td><td></td></tr><tr><td>Quakewatch Prediction Center</td><td>1.1.1, 1.3.1a, 1.4.4</td><td></td><td>3.3.2</td><td></td></tr><tr><td>Crisis Communication Wiki for professionals</td><td></td><td></td><td>3.3.2</td><td></td></tr><tr><td>Emergency 2.0 Wiki</td><td>1.3.1a, 1.4.3</td><td>2.4.6</td><td>3.3.2</td><td></td></tr></tbody></table>

## 4.3 Likely Problems

In addition to the clear problems detected in the previous subsection, the following likely problems were detected, as shown in Tables 5 and 6. They are marked with strikethrough in the cases where they were found not to be a problem after manual checking.

<table><caption>**Table 5.** WCAG 2.0 AA Likely Problems for Main page (AChecker)</caption><thead><tr><th></th><th>Perceivable</th><th>Operable</th><th>Understandable</th><th>Robust</th></tr></thead><tbody><tr><td>Ushahidi Syria Tracker</td><td></td><td></td><td>3.2.2</td><td></td></tr><tr><td>Google Crisis Response Person finder demo</td><td></td><td></td><td>3.2.2</td><td></td></tr><tr><td>Quakewatch Prediction Center</td><td>1.3.1b</td><td></td><td></td><td></td></tr><tr><td>Crisis Communication Wiki for professionals</td><td></td><td></td><td>3.2.4</td><td></td></tr><tr><td>Emergency 2.0 Wiki</td><td>1.3.1b</td><td></td><td></td><td></td></tr></tbody></table>
Table 5 shows that Ushahidi Syria Tracker as well as Google Crisis Response Person Finder Demo triggers a likely problem regarding success criteria 3.2.2, which refers to making web pages appear and operate in predictable ways. The select element could cause extreme change in con-text. However, here it is used as a language picker, changing the content to the selected language, but not the context.

1.3.1b refers to a paragraph element that may be used as header. That is not the case for Quakewatch, however, in the case of Emergency 2.0 Wiki a manual examination confirms that there is a bold p paragraph used as a header without being tagged as such. Finally, Crisis Communi-cation Wiki for professionals triggers the 3.2.4 test case concerning list item used to format text. However, this is triggered by an actual list.

<table><caption>**Table 6.** WCAG 2.0 AA Problems for Information Submission page (AChecker)</caption><thead><tr><th></th><th>Perceivable</th><th>Operable</th><th>Understandable</th><th>Robust</th></tr></thead><tbody><tr><td>Ushahidi Syria Tracker</td><td></td><td></td><td>3.2.2</td><td></td></tr><tr><td>Google Crisis Response Person finder demo</td><td></td><td></td><td>3.2.2</td><td></td></tr><tr><td>Quakewatch Prediction Center</td><td></td><td></td><td></td><td></td></tr><tr><td>Crisis Communication Wiki for professionals</td><td></td><td></td><td></td><td></td></tr><tr><td>Emergency 2.0 Wiki</td><td></td><td>2.4.4b</td><td></td><td></td></tr></tbody></table>

As shown in Table 6, Ushahidi Syria Tracker and Google Crisis Response person finder demo trigger 3.2.2, but as in the previous case it refers to a harmless language picker and not a problem. Emergency 2.0 Wiki triggers test case 2.4.4 referring to making the purpose of a link clear, with a “suspicious link text” “More”. In this case it refers to more ways to share the page, and is not part of the essential functionality of the page. However, for users of screen readers that list up all links on a page, the lack of clear link text is actually a real issue.

<table><caption>**Table 7.** WCAG 2.0 AA Problems for Main page (AChecker)</caption><thead><tr><th></th><th>Perceivable</th><th>Operable</th><th>Understandable</th><th>Robust</th></tr></thead><tbody><tr><td>Ushahidi Syria Tracker</td><td>Fail (1.3.1)</td><td>A (2.4.6)</td><td>Fail (3.3.2)</td><td>Fail (4.1.1)</td></tr><tr><td>Google Crisis Response Person finder demo</td><td>Fail (1.3.1)</td><td>AA</td><td>AA</td><td>AA</td></tr><tr><td>Quakewatch Prediction Center</td><td>Fail (1.3.1, 1.4.4)</td><td>Fail (2.4.4)</td><td>Fail (3.3.2)</td><td>Fail (4.1.1)</td></tr><tr><td>Crisis Communication Wiki for professionals</td><td>A (1.4.4)</td><td>Fail (2.4.4)</td><td>Fail (3.3.2)</td><td>Fail (4.1.1)</td></tr><tr><td>Emergency 2.0 Wiki</td><td>Fail (1.1.1, 1.3.1, 1.4.4, 1.4.6)</td><td>A (2.4.6)</td><td>AA</td><td>AA</td></tr></tbody></table>
## 4.4 Evaluation Results

In Tables 7 and 8, results for each category are given as Fail, or pass level A, AA; and failed success criteria are given in parenthesis. More details on these failed criteria are provided in Section 4.4 above.

<table><caption>**Table 8.** WCAG 2.0 AA Problems for Information Submission page (AChecker)</caption><thead><tr><th></th><th>Perceivable</th><th>Operable</th><th>Understandable</th><th>Robust</th></tr></thead><tbody><tr><td>Ushahidi Syria Tracker</td><td>Fail (1.3.1)</td><td>A (2.4.6)</td><td>Fail (3.3.2)</td><td>AA</td></tr><tr><td>Google Crisis Response Person finder demo</td><td>Fail (1.3.1)</td><td>AA</td><td>AA</td><td>AA</td></tr><tr><td>Quakewatch Prediction Center</td><td>Fail (1.1.1, 1.3.1, 1.4.4)</td><td>AA</td><td>Fail (3.3.2)</td><td>AA</td></tr><tr><td>Crisis Communication Wiki for professionals</td><td>AA</td><td>AA</td><td>Fail (3.3.2)</td><td>AA</td></tr><tr><td>Emergency 2.0 Wiki</td><td>Fail (1.3.1, 1.4.3)</td><td>Fail (2.4.4, 2.4.6)</td><td>Fail (3.3.2)</td><td>AA</td></tr></tbody></table>

## 4.5 Guidelines, Tests and Success Criteria

The success criteria mentioned in the sections above refer to the following guidelines and success criteria from WCAG 2.0:

*Principle 1 Perceivable:* Information and user interface components must be presentable to users in ways they can perceive.

* **Guideline 1.1 Text alternatives:** Provide text alternatives for any non-text content.

* 1.1.1 Non-text content (A): Image used as anchor is missing valid Alt text.

* **Guideline 1.3 Adaptable:** Create content that can be presented in different ways (for example simpler layout) without losing information or structure.

* 1.3.1a Info and Relationships (A): Missing labels.

* 1.3.1b Info and Relationships (A): p element may be misused (could be a header).

* **Guideline 1.4 Distinguishable:** Make it easier for users to see and hear content including separating foreground from background.

* 1.4.3 Contrast (Minimum) (AA): The contrast between the colour of selected link text and its background is not sufficient.

* 1.4.4 Resize text (AA): *i* (italic) element used instead of *em* or *strong*; *font* used.
*Principle 2 Operable*: User interface components and navigation must be operable.

* *Guideline 2.4 Navigable*: Provide ways to help users navigate, find content, and determine where they are.

* 2.4.4a Link purpose (in context) (A): Anchor contains no text.

* 2.4.4b Link Purpose (In Context) (A): Suspicious link text (contains placeholder text).

* 2.4.6 Headings and Labels (AA): Incorrect header nesting.

* 2.4 Navigable: Provide ways to help users navigate, find content, and determine

*Principle 3 Understandable*: Information and the operation of user interface must be understandable.

* *Guideline 3.2 Predictable*: Make Web pages appear and operate in predictable ways.

* 3.2.2 On Input (A): Select element may cause extreme change in context.

* 3.2.4 Consistent Identification (AA): List item used to format text.

* *Guideline 3.3 Input assistance*: Help users avoid and correct mistakes.

* 3.3.2 Labels or Instructions (A): Empty label text.

*Principle 4 Robust*: Content must be robust enough that it can be interpreted reliably by a wide variety of user agents, including assistive technologies.

* *Guideline 4.1 Compatible*: Maximize compatibility with current and future user agents, including assistive technologies.

* 4.1.1 Parsing (A) id attribute is not unique.

# 5 Discussion of Implications and Limitations

## 5.1 Summary of Results

From the results shown in the previous section, we see that none of the tools are fully compliant even to level A. For the main pages, three of them fail at 3 of the 4 main principles of WCAG 2.0. For the information submission pages, the situation is a bit better, and we see that all of them conform to level AA on the robustness criteria, and all are operable at least at the A level. The most common detected issues include:

* Missing labels (1.3.1) is an issue present in all tested tools except *Crisis Communication Wiki for professionals*. Missing labels could affect screen reader users who rely on screen readers to understand the meaning and intention of the web elements (e.g. buttons).
* Resizing issues (1.4.4) affects *Quakewatch Prediction Center, Crisis Communication Wiki for professionals* and *Emergency 2.0 Wiki*. Resizing affects users with visual impairments, making it more difficult to adapt the web site to their needs.

* Lack of instructions or help (3.3.2) affects all sites except *Google Crisis Response Person finder demo*. Instructions or help are essential for users to learn how to use the web sites and get help when needed. They can also help users to prevent errors and understand error messages. Without appropriate instructions or help function, it is often difficult for users to understand what they should do and how to interact with certain functions.

* Compatibility issues (4.1.1) affects *Ushahidi Syria Tracker, Quakewatch Prediction Center* and *Crisis Communication Wiki for professionals*. Lacking the robustness to ensure compatibility with current and future user agents, including assistive technologies.

## 5.2 Implications for Emergency Management

It is important to be aware that situational disabilities may affect people in emergencies. In general, issues such as being unable to type messages on a mobile phone virtual keyboard due to cold, wet and shaky hands, noisy background, only using one hand, bumpy roads, eyes are busy observing surrounding areas. These situations are likely to occur in a disaster situation, adding to the importance of the universally designed information sharing tools. Little research has focused on accessibility and universal design of disaster information sharing tools with respect to situational disabilities. We would like to highlight that following recommendations and guidelines for accessibility and universal design will also benefit users in these situations greatly.

When such a system is not accessible, it could in the worst case lead to some users not being able to access life-saving information. It is not only the lives of PWD that are at stake, and we can easily imagine that because of an inaccessible system, some users might not be able to submit important information, that could help facilitate the rescue of many potential disaster victims.

Although the set of criteria tested as well as the selection of pages from each site are limited in this study, it is enough to be able to say that the websites in question are not fully accessible for all users. Since most of these sites are experimental and not fully relied on in an emergency situation yet, it may be tempting to think that universal design and accessibility is an aspect that can be added in later versions of the tools. However, it is important to be aware that to be successfully realised, universal design should be factored into the process from the start. It should be explicitly stated in the requirements, emphasized through the design and development, and verified through extensive testing. Not only conformance testing for WCAG 2.0 and HTML validation should be performed, but also user testing with a broad diversity of users and user agents including assistive technologies.
## 5.3. Limitations

Access to disaster information is important to citizens. This study illustrates an exploratory examination of the accessibility on a set of samples of web pages intended for communicating information for improving disaster risk reduction and effort for enhancing community resilience, empowering vulnerable group and PWDs emergency. In some countries, emergency information is sometimes hidden as a pre-set setting of the main e.g. municipality portals, and will be activated when disasters strike. In this case, it is difficult to assess if actually the pages meet accessibility criteria.

However, there are some limitations in this research that could be addressed in the future research projects. First, user testing and expert testing are not implemented in this study, which actually can provide more comprehensive overview of web barriers. Second, we use very limited samples of webpages. Third, the quality of automatic testing tools varies and can contain some weaknesses, resulting inconsistent results from one to another tool. In this paper, we do not evaluate or compare the quality of the testing tools. A thorough heuristic testing and user testing with a broad diversity of users will likely reveal some barriers that have not been detected by the automatic testing [32], while some automatically detected barriers may not be a problem in practice.

# 6 Conclusions and Future Work

Our experiments reveal that improvements of web-based information sharing tools are required in order to include as wide range of users as possible. This can be achieved by putting stronger focus on the importance of universal design and web accessibility of these tools which eventually will enhance the disaster resilience of communities. More specifically, improvement of the tools should focus on the following aspects:

1. Providing labels for web elements in order to support screen reader users.

2. Providing and improving resizing functions.

3. Providing instructions and help.

4. Improving compatibility with current and future user agents, including assistive technologies.

Future work includes using a broader range of manual and automatic test methods and tools to evaluate the universal design of the selected disaster information sharing tools. We will perform heuristic evaluation as well as user testing, with a focus on different user groups. Finally, testing a broader range of tools including mobile apps and tools for different aspects of emergency management is part of the future work.

Since we have focused on dedicated tools for disaster information sharing, we have not covered the crowdsourcing of disaster information through social media. Smartphone apps are also out of our scope in this study. However, they are highly relevant when it comes to universal design of disaster information sharing, and will be covered in later studies.
For future directions, more recent technologies such as wearable devices can be used by the first responders in emergency response Bennett et. al. [3], to improve communication with people. Wearables can assist by providing accessible information such as braille, text, voice or ASL interpretation. In combination with the recent trend of interconnected devices, they can improve a quick response for people needing rescue.

## References

1. UNISDR, Living with Disability and Disasters. 2014: United Nations: Geneva.

2. Kelman, I. and L. Stough, Disability and disaster: Explorations and exchanges. 2015: Springer.

3. Bennett, D., B.D. Phillips, and E. Davis, The future of accessibility in disaster conditions: How wireless technologies will transform the life cycle of emergency management. Futures, 2017. 87: p. 122-132.

4. Bennett, D., P.M. Baker, and H. Mitchell, New 9 media and accessible emergency communications. Disability and Social Media: Global Perspectives, 2016: p. 119.

5. UNISDR, Hyogo Framework for Action 2005-2015: Building the Resilience of Nations and Communities to Disasters, in World Conference on Disaster Reduction. 2005: Kobe, Hyogo, Japan.

6. UNISDR, Living with risk: a global review of disaster reduction initiatives: 2004 version - Volume II Annexes, in International Strategy for Disaster Reduction (ISDR). 2004: United Nations: New York and Geneva.

7. Stough, L.M. and D. Kang, The Sendai framework for disaster risk reduction and persons with disabilities. International Journal of Disaster Risk Science, 2015. 6(2): p. 140-149.

8. Brooks, M. Challenges for warning populations with sensory disabilities. in Proceedings of the 3rd International ISCRAM Conference, Newark, NJ, USA (May 2006) 2006.

9. Hakkinen, M. and H.T. Sullivan. Effective communication of warnings and critical information: application of accessible design methods to auditory warnings. in Proceedings of Information Systems for Crisis Response and Management Conference (ISCRAM), Delft, Netherlands (May 2007). 2007.

10. Sullivan, H.T., M.T. Hakkinen, and K. DeBlois, Communicating critical information using mobile phones to populations with special needs. International journal of emergency management, 7(1), 6-16 (2010).

11. Kent, M. and K. Ellis, People with disability and new disaster communications: access and the social media mash-up. Disability & Society, 30(3), 419-431 (2015).

12. Majchrzak, T.A. and M. Sakurai, Design Principles for the Use of Social Network Services to Promote Citizen Engagement, Public Deliverable, SMR Project (H2020-DRS-2014 653569). 2016.

13. Sullivan, H.T., Crisis resilience-enhancing technology: a desk study of accessibility and inclusiveness, in Public empowerment policies for crisis management (PEP) EU FP7 Project. 2014.

14. W3C/WAI. Introduction to Web Accessibility. 2005 [cited 2017 September 1, ].

15. Stephanidis, C., Towards user interfaces for all: some critical issues. Advances in Human Factors/Ergonomics, 1995. 20: p. 137-142.

16. Phibbs, S., et al. Emergency preparedness and perceptions of vulnerability among disabled people following the Christchurch earthquakes: Applying lessons learnt to the Hyogo Framework for Action. in Australasian Journal of Disaster and Trauma Studies, IRDR Conference. 2015.
17. Crozier, M. and M. Dee, Critical literature review: Disaster support and the resource needs of marginalised children and young people with disabilities from diverse cultural backgrounds. 2016.

18. Alexander, D., Disability and Disaster: An Overview, in Disability and disaster: Explorations and exchanges, I. Kelman and L. Stough, Editors. 2015, Springer.

19. Phillips, B.D., Inclusive emergency management for people with disabilities facing disaster, in Disability and disaster: Explorations and exchanges, I. Kelman and L. Stough, Eds. 2015, Springer.

20. Sefyrin, J. and S. Pilemalm. " It's More Important to be Fast than to be Informed"-Gender, Age, Disability and Ethnicity in Relation to IT in the Swedish Rescue Services. in ISCRAM. 2016.

21. Wentz, B., et al., Danger, danger! Evaluating the accessibility of Web-based emergency alert sign-ups in the northeastern United States. Government Information Quarterly, 31(3), 488-497 (2014).

22. Ushahidi. Available from: https://www.ushahidi.com/

23. Google. Available from: https://www.google.org/crisisresponse/

24. Quakewatch. Available from: https://itunes.apple.com/app/disaster-alert-pacific-disaster/id381289235?mt=8.

25. EarthquakeBuddh. Available from: https://www.techinasia.com/earthquake-buddy-alert-location

26. DisasterAlert. Available from: http://www.pdc.org/solutions/tools/disaster-alert-app/

27. WikiForProfessionals. http://www.crisiscommunication.fi/wiki/Main_Page.

28. Emergency2.0. Available from: http://emergency20wiki.org/wiki/index.php/Main_Page

29. W3C. Understanding WCAG 2.0 - Understanding Conformance. [cited 2018 01-27]; Available from: https://www.w3.org/TR/UNDERSTANDING-WCAG20/conformance.html.

30. Achecker. Achecker Web accessibility checker. [cited 2018 01-27]; Available from: http://achecker.ca/checker/index.php.

31. Mauve. Mauve - Multiguideline Accessibility and Usability Validation Environment. [cited 2018 01-27]; Available from: http://hiis.isti.cnr.it:8080/MauveWeb/.

32. Rømen, D. and D. Svanæs, Validating WCAG versions 1.0 and 2.0 through usability testing with disabled users. Universal Access in the Information Society, 2012. 11(4): p. 375-385.