Accessibility in e-governance: introducing a toolkit
containing accessible User Interface components
SODFA SHAFIK
11906812
Submitted in partial fulfillment for the degree of
master of science
Master Information Studies
Human-centered Multimedia
Faculty of Science
University of Amsterdam
July 7, 2018 1stSupervisorFrank Nack
University of Amsterdam (UvA)
2ndSupervisor
Tom van Engers
University of Amsterdam (UvA)
Accessibility in e-governance: introducing a toolkit
containing accessible User Interface components
June 2018, Thesis MSc
S. Shafik, 11906812
University of Amsterdam sodfa.shafik@student.uva.nl
ABSTRACT
The majority of governmental web-services in the Netherlands keep failing in terms of accessibility. There is not a sufficient amount of time and attention payed to the accessibility of e-governance, mostly due to budget limitations and other priorities. The existing web-accessibility guidance is considered to be insufficient for guar-anteeing web-accessibility, and is to a large extent not even reliably testable. In this work, a toolkit is introduced and evaluated as a pro-posal for web-accessibility improvement in Dutch e-governance, by means of standardized UI-components. The key findings are outlined as a set of Golden Rules and are included in the toolkit.
KEYWORDS
accessibility, usability, e-governance, user interface, system compo-nents
1
INTRODUCTION
The majority of governmental websites, applications and digital documents are proven to fail in terms of accessibility, usability and understandability, causing the so-called ICT-chaos [24]. A proper example is the "Walvisprotocol" [5], constructed by the Ministry of Economics. This whale-protocol should guide people through situations that include a stranded whale, yet the layout of this pdf-file1makes people feel like they would rather become that stranded whale. Readers have to deal with tables that do not fit the pages, out-dated fonts, unusual color usage in models and a scanty cover page [19]. In 2004, the Dutch cabinet decided that it was vital to renovate the national personal register, but 13 years later, 100 million euros were spent without result and the project was shut down [45]. The Nederlandse Omroep Stichting (NOS) published a confronting list of failed IT projects, including those regarding DigiD, OV-chipkaart, voting machines, police declarations and the Uitvoeringsinstituut Werknemersverzekeringen (UVW) [6]. Additionally, in 2016, an organization called Logius2performed an assessment to reflect on accessibility of (semi-)governmental websites, applications and documents. It turned out that only 46% of the websites and appli-cations contained the mandatory accessibility statement. Due to other priorities and budget limitations of governmental organiza-tions, a shortage of attention is payed to accessibility, explaining the percentage [2]. Remarkably, the Dutch government does not comply with her own regulations, for a striking extent.
1
https://www.rijksoverheid.nl/binaries/rijksoverheid/documenten/ rapporten/2013/06/27/protocol- stranding- levende- grote- walvisachtigen/ protocol- stranding- levende- grote- walvisachtigen.pdf
2
https://www.logius.nl/
Despite the lack of accessible e-governance in the Netherlands, the Dutch vision on accessibility is rather clear, as it aims at the equality of people. Similar to a building that must be accessible for someone in a wheelchair, buttons on a website must be accessible for a colorblind. The Ministry of Internal Affairs has formulated the following [2]:
Every human being has the right to live as any other and to participate in society. Using the internet, computers and smart-phones is of course a part of that. Therefore, it is important that digital services are made accessible for everyone (para. 1). In order to realize this vision, the Dutch government introduced theWet Digitale Overheid (Dutch e-governance law) that aims at regulating (semi-)governments in terms of digital means. The law makes open standards mandatory, including guidelines of the Eu-ropean Union [3]. The government has set up two requirements regarding the accessibility of e-governance [2]:
(1) All (semi-)e-governmental applications must be aligned with the WCAG 2.0 on levels A and AA, as stated in Chapter 9 Web of the European accessibility standard EN301549 [21]. (2) The presence of an accessibility statement, that summarizes
the organization’s measures for providing accessibility. From the first of July 2018, all e-governance websites and applica-tions must conform to the above mentioned guidelines as a legal obligation, recorded in the Web Content Accessibility Guidelines (WCAG) [14]. However, the guidelines are not reliably testable [8] and several municipalities have mentioned their need for unam-biguous guidelines or standards that provide clearance and under-standable information on web-accessibility [2]. The legal obliga-tion that will go into effect together with the lack of accessible Dutch e-governance motivates the need for alternative methods that support web-developers and web-designers in guaranteeing web-accessibility in the e-governance field. A recommended ap-proach for e-governance is to standardize elements of the User Interface (UI) [36], which is most effectively achieved by creat-ing sets of components [47]. To explore the possible added value of accessible UI components, the following research question is formulated:
RQ: How can the accessibility of Dutch e-governance web-sites and applications be enhanced by applying pre-defined UI components in their development?
Several aspects need to be covered when answering this question. Background information is provided in Section 2, Section 3 covers the research method, including a casestudy. Section 4 covers the development of a toolkit that will be evaluated in Section 5 and dis-cussed in Section 6. Conclusions can be found in Section 7, followed by future recommendations in Section 8.
2
RELATED WORK
In order to provide background information and clearance on the terminology used throughout this study, several topics related to e-governance accessibility are explained and discussed in this section.
2.1
Accessibility on the web
Accessibility is considered to be a property of a web-service, imply-ing that "people with some impairment can use it with the same effectiveness as non-disabled people" [12] (p. 2). It copes with tech-nical difficulties on one side and subjective factors on the other side. Subjectivity is relevant the moment human beings are involved, and in this context regards the way a user interprets, perceives and behaves on a User Interface. Personal aspects like one’s ex-perience with web-services, specific software and motivation to-gether with contextual aspects like lightning and noise strongly affect the accessibility of a web-service [42]. The World Wide Web consortium3 (W3C) listed the existing standards4 for providing web-accessibility, such as the WCAG and Accessible Rich Internet Applications (ARIA). Leading the web to be accessible and to equally enable people to participate on the web is part of their activities.
2.2
E-governance
E-governance is defined as the utilization of internet and the World Wide Web, in order to deliver governmental information and ser-vices to citizens [37]. The governmental websites, applications and documents attempt to automate and optimize manual internal pro-cesses [9]. Doors are opened for not only improving such propro-cesses, but also for connecting citizens and creating a more interactive network with and within society. According to Heeks, [25] the five main advantages are that governance becomes more cheap, quick, effective, qualitative and innovative.
Additionally, e-governance also creates new possibilities for in-volving the citizens in governmental services [29], and taking the needs of the user into account is proven to positively affect the de-ployment of the governmental processes [15]. Rømen and Svanæs, [39] recommend applying a user-centered design approach, per-forming usability tests and involving users with wide range abili-ties. This way, accessibility will be achieved more completely by addressing the actual problems that real people experience with real systems, which is what accessibility should be about [39].
As e-governance copes with many stakeholders that have differ-ent interests, jargons and backgrounds, the design process becomes complex. Pontico et al. [36] mention final users, clients and the design team as three rough categories of stakeholders. The final users, who are "normal citizens", lay most of the pressure on the performance of an e-governance service, as their procedure must succeed in order to comply with a personal need. Examples are re-questing a Visa that must be available in time, but also confidential data that is handled in a procedure. Clients are mostly people that fit in the categories of managers, commercials and domain experts. Clients also intend to satisfy the need of successfully managing a procedure, in which failures can have disastrous consequences. Fi-nally the design team that consists of people like a project manager,
3
https://www.w3.org/
4
https://www.w3.org/standards/webdesign/accessibility
developer and graphical designer, is considered to be a stakeholder as this team is responsible for the design process.
As this research focuses on the accessibility of e-governance, the organizational processes that affect this must be taken into account. Several engineering methods can be found in literature and are proven to lead to excellence regarding e-governance. One frequently occurring and approached method is the e-governance engineering methodology (EGE) [25], that roughly consists of four stages:
(1) Planning: stakeholder identification, governance issues, scop-ing the process.
(2) Definition: define process architecture, define and collect information about indicators, analyze process performance for improvements, business and technology architecture. (3) Implementation: development, redesign, manage
transi-tions.
(4) Evaluation: monitor performance, report, audit, feedback, embed system for improvement.
According to Saxena, [40], this method contributes to designing components for the delivered software, that matches a correspond-ing governmental process.
2.3
Dutch accessibility regulations for
e-governance
As mentioned in the Introduction, the Dutch government has set two requirements for e-governance websites, applications and doc-uments. In the upcoming subsections 2.3.1 and 2.3.2 these require-ments are explained.
2.3.1 The Web Content Accessibility Guidelines. The first re-quirement is to comply with the Web Content Accessibility Guide-lines 2.0 [14] on levels A and AA. From July 2018, this is a legal obligation. The WCAG carry requirements for the accessibility on the web, in order to optimize the overall user experience [38]. "On the web" includes websites, web-applications and digital files. The guidelines are provided by the Web Accessibility Initiative5(WAI) and mainly consist of general guidelines and success criteria reflect-ing the accessibility of web content. Alignreflect-ing with the WCAG on conformance levels (A, AA and AAA) is obligatory in the majority of countries in Europe, Asia, Oceania and North and South America [7]. According to the EN301549 [21], conformance level A and level AA of the WCAG 2.0 must be satisfied in the European Union. To understand the construction of the guidelines, a summary of the WCAG lifetime is given.
The first proper WCAG guidelines, the WCAG 1.0, were formu-lated in the late 1990’s. Nonetheless, in 2000 the WCAG 1.0 was rated as outdated and a second version was constructed: the WCAG 2.0 [38]. Characteristics of both versions in terms of structure and measure are shown in Table 1.
5
https://www.w3.org/WAI/
Table 1: WCAG version comparison WCAG 1.0 WCAG 2.0 # guidelines 14 (individual) 12 (grouped)
# criteria 65 61 measure priority levels: 1. Must satisfy 2. Should satisfy 3. May address conformance levels: A AA AAA
The major differences with the WCAG 1.0 are that in the WCAG 2.0 the guidelines are no longer technology-specific and are grouped into four Principles of Accessibility, namely:
(1) Perceivable: user is able to perceive relevant information. (2) Operable: user is able to operate the interface successfully. (3) Understandable: user must be able to understand both
pre-sented information and operation of the interface. (4) Robust: user must have access to content, interpreted by a
wider variety if user agents.
The 12 guidelines that are covered by WCAG 2.0 are divided into these Principles of Accessibility. The success criteria of the guide-lines are formulated as sub-guideguide-lines, that apply to specific system elements [38], [14]. In order to comply with one a guideline, all corresponding success criteria must be met. Unfortunately, both versions of the WCAG are proven to be insufficient for guarantee-ing web accessibility, and the requirements are to a large extent not even reliably testable [8], [12], [13]. Combining the WCAG 1.0 and the WCAG 2.0 would still only identify 38% of the accessibility problems [39]. Two examples that represent the average guideline are:
2.4.10Section Headings: Section headings are used to organize the content.
3.3.2Labels or Instructions: Labels or instructions are provided when content requires user input.
On first sight, one would say that these guidelines provide clearance on how to make accessible web-content. However, whether section headings, labels or instructions are applied does not tell anything about their quality. For example, a label can be wrong, irrelevant or not clear to the user. Most of the guidelines are similar to the examples given above, implying that one could measure them with a "yes" or "no". Nonetheless, there are certain guidelines that provide more clearance, such as a color-contrast ratio of at least 4.5:1 for text and its background (1.4.3) and nothing may flash more than 3 times per second (2.3.1) [14]. Sadly, clear guidelines such as these a rare species in the rather long list of accessibility guidance.
Of course, the weak formulation of the international accessibility guidelines is considered inconvenient, as validating web content is much harder when one cannot test its requirements properly. The requirements themself are however not the only weakness. Content provided by other resources than the webmaster could still cope with accessibility barriers, causing mismatch of conformance expectation and problems regarding the usability of the webpage, state Reid and Snow-Weaver, [38]. Reid and Snow-Weaver also mentioned that applying WCAG should evolve along with the tech-nological and usability-related developments in order to ensure web accessibility. This is not the case for the WCAG 2.0: it is technology
neutral. It is considered to be hard to fully guarantee the accessi-bility of a certain web technology, as not all user agents support all features. Due to the fact that it is simply not possible to provide support for every version of assistive technology or browser, new technologies can hardly be supported [38]. Moreover, Rømen and Svanæs, [39] state that the content of the guidelines should be based on validated empirical data, and be expanded with inclusion of the concept ofUsability for all, a component of the ISO Ergonomics for Human-Computer-Interaction6; both are not the case.
2.3.2 The Accessibility Statement. The second requirement is to include an accessibility statement on the concerned website or application. The accessibility statement explains to what extent the regarding website or application matches the WCAG, and what measures the organization will take or is taking in order to improve accessibility. By providing the accessibility statement, the organiza-tion is accountable for their accessibility measures towards both political desires and the users themselves. There is a format for the statement, in order to be able to compare it to other’s more easily. The recommended tool for composing an accessibility statement7 guides the organization through the process. The output is an HTML-file the organization can place on her website or application herself. Mostly, the accessibility statement is accessible by a hyperlink in the footer of the website, and consists of a well-structured web-page. In order to keep the accessibility statement up-to-date, it is recommended by the government to renew the statement yearly [2]. However, as mentioned in the Introduction, not even half of the concerned organizations has an accessibility statement.
2.3.3 Roadmap for web-accessibility. The Dutch government provides a road-map for web accessibility [2]:
(1) Assessment: checking the organization’s view on accessi-bility, the presence of an accessibility statement, involved parties and external systems, the Content Management Sys-tem (CMS) and reports on previously performed accessibility tests.
(2) Measures: based on the assessment, the organization must determine a plan for improving accessibility of the digital channel, for example the implementation of tools that en-hance accessibility like a pdf-checker. During this step, the digital channel must be checked in terms of the WCAG 2.0. (3) Accessibility statement: after determining what measures are planned to be performed, they will be formalized or adjusted in a statement, as explained in Section 2.3.2. (4) Implement measures: the defined measures will be
imple-mented and subsequent results included in the accessibility statement.
(5) Iterate: as accessibility is not considered to be a one-off project, an agile-method must be applied to continuously improve and align the accessibility with the fast changing digital world. In other words: return to step 1.
According to the Dutch government, following the above mentioned steps should guarantee web accessibility. However, as mentioned, the WCAG is not considered to be properly testable. "Testable"
6 https://www.iso.org/obp/ui/#iso\protect\kern+.2222em\relaxstd\protect\kern+ .2222em\relax52075\protect\kern+.2222em\relaxen 7 https://www.toegankelijkheidsverklaring.nl/ 3
does not necessarily imply "machine testable", which is the case with the WCAG: several requirements can be verified by applying automated tools, but most of the requirements ask for human testing [38]. Anyways, following the road-map is recommended, in order to at least follow the WCAG 2.0 as far as possible, and place an accessibility statement, as these are legal obligations.
2.4
Design Patterns in e-governance
As proposed and described by Pontico et al., [36], user-interface design patterns are easier to apply than guidelines are. Many guide-lines are ambiguous and only experts are able to apply them cor-rectly. However, even for experts it could be hard to apply guidelines that meet expected outcomes. To overcome the vagueness and re-quired expertise in the case of applying guidelines, the concept of design patterns was introduced. In short, a design pattern is a way of organizing knowledge, in this case of some feature that is going to be designed.
Due to the fact that there are many recurrent elements appearing in e-governance applications and the divergent interests of the stakeholders, UI patterns actually help the benefice of an application [36]. By reinvesting design knowledge into other projects, time and effort are being saved. Also, the designs of the applications throughout the company will not only be guaranteed of accessible contents, the applications will also be consistent in terms of design. Applying patterns is seen as a way to materialize an abstract concept of some criterion of quality that is implementable as a pattern. According to García et al., [23] a tuple of three elements form such a pattern, including a problem (1), a context (2) and a solution (3). García et al. add that UI patterns can among other things be used for ensuring usability, through evaluating functional requirements represented as UI components. They can be provided by a catalogue that should be easy to navigate through and in such way that their actual use is being suggested.
As proposed by Pontico et al., [36] a pyramidal structure orga-nizes UI patterns efficiently by distinguishing several categories of patterns. The basis of the pyramidal structure consists of UI design rules recommended in HCI design, refered to as "Golden Rules". The top layer is filled with screen flow patterns that represent a sequence of screens or components belonging to a procedure. Sec-ondly, there are page level patterns that represent the layout and disposal of a page or several UI components, like a form. A third category covers the displaying and interactions of the UI elements that belong to higher-level UI components, like a field that belongs to a form.
Figure 1: The pyramid-model as visualized by Pontico et al., [36]
2.5
Universal Design
Universal design (UD) is a term invented by Mace, [28]:
Universal design is the design of products and environments to be usable by all people, to the greatest extent possible, without the need for adaptation or specialized design. (p. 1)
Applying the principles that match UD would result in products and environments that fit the needs of a wide variety of users, in which a disability is considered as just one of the many charac-teristics one could possess [28]. However, Mace was an architect, which could cause thoughts of irrelevance towards the accessibility of web-applications. Chisholm and May, [16] clear this up, stat-ing that web practitioners have an affinity for architecture. This vision is underpinned by the fact that in both fields people’s abili-ties, interactions and participation in communities is affected. One of the results of focusing on UD, according to Mace, is that one stopped workingaround HTML and started working with HTML. UD is considered to be a discipline that should be part of any product, application or site.
2.6
ARIA
One way to provide accessible web content is to use Accessible Rich Internet Applications (ARIA) [17]. Such applications allow assistive technologies such as screen-readers to provide clear meaning to the user. This is mainly done by enhancing the syntactic contents of pages [20]. Developers include semantic information to their web pages that is being exposed to the browser. Examples include roles of widget types, widget states and drag-and-drop properties.
As described by the Consortium et al., [17] there are two types that can be implemented as ARIA: ARIA-roles and ARIA-attributes. The roles are included inside theHTML markup as an attribute and define some type of purpose. In the format role="RoleName" the role of an element can be identified. In the following example, a banner and a checkbox are defined.
1 < h e a d e r role =" b a n n e r "> 2 3 < span role =" c h e c k b o x " 4 aria -c h e c k e d=" true " 5 t a b i n d e x=" 0 " 6 id=" s i m u l a t e d c h e c k b o x "> 7 </ span >
When implementing ARIA into theHTML of a webpage efficiently, there are a few rules that should be followed:
(1) If possible, use nativeHTML element, as these already have built-in accessibility means. This implies that there is no need to include an ARIA-attribute.
(2) Do not change the semantics of a nativeHTML element. (3) All elements must be usable with the keyboard solely, which
can be realized by using native HTML, ARIA-attributes or thetabindex property
(4) Do not use the presentation role or hidden-attribute on focus-able elements, in order to avoid users focusing on nothing. (5) Interactive elements must have an accessible name. 4
2.7
Design Heuristics
Besides the road-map provided by the government, there are also road-maps, steps, heuristics and many more ways to develop and evaluate the accessible web. Evaluating user interfaces can be done automatically, empirically, formally and informally [32]. Automati-cally implies that usability measures will be computed by running some program on the UI. Empirically implies the opposite: testing the interface with real users. Formal evaluation is done by models and formulas that calculate usability measures. Lastly, informal evaluation regards rules of thumb and general skill. As mentioned by Nielsen, [32] automatic tests do not work properly and formal methods are hard to apply and do not scale well. Empirical methods require recruitment of users that can be costly and the participants mostly need to be guided during the tests. This leaves out the infor-mal methods of usability inspection, or combining several methods (such as cognitive walkthroughs and consistency inspection) to retrieve most useful test results. Nielsen states that the most infor-mal method is the heuristic evaluation, which involves usability specialists to judge elements of a system in terms of the extent that it follows predefined principles. Such principles are called the heuristics and are considered to be rules of thumb, more than spe-cific guidelines. Additionally, Nielsen formulated 10 heuristics for user interface design, that should improve the usability and there-fore the accessibility of a system. Nielsen is considered to be an acknowledged usability expert [10] and the heuristics listed below are widely applied. Furthermore, these heuristics can be extended and adjusted to fit in specific usability and accessibility desires, for example regarding video games [35].
(1) Visibility of system status: the user should always be in-formed about what is going on, implying the provision of appropriate feedback within reasonable time.
(2) Match between system and the real world: language and concepts should be familiar to the users, as real-world con-ventions must be followed. Information should appear in a sequence that is logical to the user.i
(3) User control and freedom: undo and redo actions should be supported, so that the mistakes can be undone.
(4) Consistency and standards: consistency is desired in terms of words, concepts, actions e.d., so that the user is not con-fused on elements meaning the same thing.
(5) Error prevention: preventing problems must be supported by the system, like a confirmation option before committing an action.
(6) Recognition rather than recall: by making objects, ac-tions and opac-tions visible, the memory load of the user can be minimized. Instructions should be visible or easy to retrieve. (7) Flexibility and efficiency of use: the system should be usable for both experienced and inexperienced users, which could be done by providing multiple ways of using a system element.
(8) Aesthetic and minimalist design: irrelevant or rarely needed information should not be included in dialogues that are visible, as they take the relative visibility of the relevant information away.
(9) Help users recognize, diagnose and recover from er-rors: in case of error messaging, such messages should be
expressed in plain language and precisely indicate the prob-lem in order to suggest a solution.
(10) Help and documentation: a system should be usable with-out documentation, but in some cases it is necessary to pro-vide help and documentation. If available, such information should be easy to find and should provide stepwise processes that instruct the user.
3
RESEARCH METHOD
This study aims at improving the accessibility of Dutch e-governance by means of providing accessible UI components. As mentioned in Section 2.4, an effective way to do so is to standardize system elements. Hence, creating a conceptual toolkit containing acces-sible UI components will be the main purpose of this study. This toolkit should provide basic UI components that are accessible in terms of governmental requirements and design heuristics, as the governmental requirements alone turned out not to be sufficient. Furthermore, more understandable guidance is desired, as govern-mental organizations mentioned the lack of understandable and unambiguous guidelines [2]. Therefore, the UI toolkit will consist of two parts: (1) accessible UI components for e-governance and (2) a set of understandable Golden Rules that replace the not-so-understandable WCAG 2.0 requirements.
An existing e-governance application will be used as a casestudy. The casestudy will give more insight on realizing accessibility in e-governance and supports decision making for the design of the components. This way, a well-grounded set of components can be created and evaluated. Summarized, the approach for the research method implies the following steps:
(1) Analyzing an existing e-governance application, as part of the research method
(2) Listing frequently occurring existing e-governance compo-nents
(3) Defining Golden Rules for web-accessibility (4) Creating the UI-toolkit
(5) Evaluating the UI-toolkit
3.1
CASESTUDY: Blogboek
Involved company: Gemboxx
Gemboxx8is a Dutch organization, connected to Innovum Hold-ing B.V.9, that performs the main activity of realizing flexible, ef-ficient and make-able software for (local) governments. Such IT-enhancement enables improvement of the services provided by the government towards its citizens and companies. However, within the Netherlands, multiple governmental IT-projects failed enor-mously [1] and therefore Gemboxx provides a platform that enables governmental organizations to configure software independently, intoboxxes. Furthermore, Gemboxx’s vision strives for collabo-ration among organizations, so that they can complement each others needs [1]. At the moment, Gemboxx does not pay proper attention to accessibility regulations or measures; the UI-designers just do something. In order to improve the organizational processes and UI-related decisions, Gemboxx benefits from the definition
8
http://gemboxx- ictoplossingen.nl/
9
http://www.innovum.nl/
of UI-components that are both in compliance with governmen-tal regulations and design heuristics. Expectedly, this reduces the amount of time spent on each UI-design for separate projects by implementing the UI-components into theboxxes.
Involved application: Blogboek
Blogboek10is an online tool developed by the Inklus foundation11, that allows parents to have insight in ahulpvraag (the concept of a request for help) of their child [46]. Multi-disciplinary health-care professionals are involved and support the process of caregiving. Paperwork is replaced by digital documents, like diagnosis, appli-cation forms and reports. Together, these features allow the parent to gain insight over and give direction to the process of caregiving regarding their child. The tool fits the ideology of the concept of a retreating role of the government, yet involving the government: health-care, education and more domains that participate are regu-lated by the government but work together with citizens to provide the best care possible. Furthermore, it eliminates the problem of limited caregiving-budgets, motivated by the fact that a more self-steering parent results in a cheaper caregiving process. Moreover, a more joint decision-making between parents and professionals has shown a positive effect on the usage and costs of health-care regarding care-intensive children [22]. Figure 2 shows a screenshot of the Blogboek application’s homepage.
Figure 2: A screenshot of the Blogboek homepage
As described by van Ulzen and van der Pal, [46] parents are able to sign up on the Blogboek website, invite professionals originating from domains like health-care and education, and gather goals and tasks from different treatment plans. Subsequently, the involved professionals and caregivers can keep track of the progress made. Also information and media can be shared on the platform. Blog-boek shows added value by its digitized caregiving process, for example by connecting two professionals working on the same goal, who update each other by means of the platform. Time is saved and a higher information-value is achieved. Blogboek has also won the national prize of youth-care by the Nederlands Jeugd Instituut [4].
10
https://blogboek.com/blogboek/
11
http://www.inklus.nl/
Gemboxx will be developing a new version of the Blogboek ap-plication. As a casestudy, the Blogboek application will be checked on accessibility. In order to get a proper insight on the accessibil-ity of blogboek, there will be taken a look at the application from different perspectives that are covered in the Related Work:
(1) The government: by means of the WCAG checklist [14], including items related to ARIA-usage.
(2) The user: results form a previously performed user test [46] will be analyzed.
(3) Design standards: the design heuristics of Nielsen, [33]. After blogboek is analyzed in terms of accessibility, Gemboxx will take the improvements into account whilst developing a new(er) version. The upcoming sections show en evaluation of the Blogboek application in terms of governmental requirements, user-centered design tests and famous design heuristics.
According to the Government
In order to comply with the governmental requirements, it should be sufficient to follow the road-map described in Section 2.3.3. As there is no accessibility statement to be found on Blogboek, checkpoints regarding its content are left out. The WCAG Checklist was filled in the most objective way possible. By using an existing excel sheet12 containing all criteria, the Blogboek application was analyzed. Only the relevant level A and level AA requirements were taken into account. All success criteria were rated as a "yes", "no" or "na" (not applicable), as the format of the checklist suggests. In case one or more success criteria fails, the guideline is considered not to be validated with the regarded Blogboek system element.
Figure 3 and Figure 4 show the outcomes of analyzing the dataset as output of the checklist in Python. As seen in the Figures, Blog-boek fails the WCAG 2.0 at multiple subjects. For example, a re-occurring issue concerns the color contrast-ratio. At many places in the application the color contrast-ratio was not high enough to pass the requirements that avoid visually limited users. None of the guidelines from theRobust principle were met, half of the guidelines from theOperable and Understandable principle were met and not even half of the guidelines were met for thePerceivable principle were met. The full analysis including screenshots of the regarding system elements are included in Appendix A.
According to The user
By talking to stakeholders and performing user-tests, a user-test-report [43] was constructed covering the outcomes. Most of the user-tests regarded the content of Blogboek itself, and its applica-tion as a communicaapplica-tion tool. As for this study only the accessibility of the system is relevant, all other aspects are be left out. The test group consists of 100 users appearing in two roles: parents and professionals. A total of 35 families with about 2-3 professionals involved in each family, tested the application during a test-period of 4 months. In order to monitor the behavior of the participants, one of the founders was added to every test-case. 7 different types of questionnaires were sent by mail to the participants. The ques-tionnaires covered various aspects of the system, such as signing on, inviting other users, the added value to the caregiving-process and
12
http://www.accessibility- checklist.ch/?file=AccessibilityChecklist- 20- en.xls
Figure 3: Pie-chart showing conformation of criteria for each priority, in which the priority slices indicate the pro-portion of each priority
Figure 4: Pie-chart showing conformation of criteria for level A and level AA, failing parts in red and conforming parts in green
the progress-profile. The overall impression of the participants was predominantly positive and described as "beautiful, clear, simple and calm". The report contains a summary that also answers the question "Is Blogboek user-friendly?", in which the usability, acces-sibility, user experience and interaction are taken into account. The summary concludes that Blogboek does comply as user-friendly, as its layout was considered to be nice and personal. The report also mentions that there are points of improvement regarding the us-ability, and not much more can be found in the user-tests regarding accessibility.
According to Design Heuristics
As seen in the Related work, Nielsen, Nielsen is considered to be a widely known usability expert, and the 10 famous design heuristics are considered to be reliable, Blogboek is analyzed in terms of
these heuristics. The full analysis of the heuristics, including an explanation for each heuristic, can be found in Appendix B. 7 out of 10 heuristics were rated as ’yes’, which implies that the heuristic was met on most of the testable cases. (1) Visibility of system status, (2) Error prevention and (3) Help users recognize, diagnose, and recover from errors are the heuristics that were not met. The visibility of system status (1) should promise that a system keeps the users informed about what is going on with the system [32]. In case something is requested from the user, there is a badge next to the component where the action is required. Despite this clearance towards the user, the user cannot see at what place exactly he finds himself within the application. The colors used for text and background in the sub-menu-tabs are too similar (also failing the contrast-ratio of the WCAG 2.0), causing the "active" menu-tab not to being clearly visible. Also, there are not breadcrumbs on Blogboek, so the user cannot see at what page exactly he finds himself and how he got there. The two other heuristics that were not met regard errors. Preventing errors (2) is about designing the system in such way that it prevents a problem from occurring in the first place. On Blogboek, when filling in a wrong value in some form-field, the label becomes red-colored. There is no further explanation provided nor are there any suggestions given that guide the user towards giving the right input. Most of the form-fields are not explained separately,implying that there could be ambiguity about the input expected by the system. (3) Help users recognize, diagnose, and recover from errors is not met either, as the there almost are no error-messages; most input is accepted to fit the idea of a "free form", as mentioned by one of the founders of Blogboek. However, in case of wrong input (for example when creating an account and filling the birth-date), the label of the form turns red. There is no further explanation or suggestion on how to give the right input in several cases. There are no error codes but neither plain language.
4
CREATING A TOOLKIT
In order to provide accessible components that are directly imple-mentable, a catalogue appearing as a toolkit will be created. This toolkit aims at webdesigners and developers that work for or at e-governance organizations. In order to fill a toolkit with acces-sible UI components, first an analysis on existing e-governance applications will be made. This way, the most frequently occurring components can be listed. Next, the Golden Rules and the com-ponents will be created as accessible UI-comcom-ponents, provided by means of anHTML-document.
4.1
Listing existing components
By navigating through a set of existing e-governance websites and applications, a set of components can be defined that are widely used in the user interfaces of e-governance. 8 websites and appli-cations were analyzed in terms of the components that appear on
them, namely those of the Rijksoverheid13, the Overheid14, the mu-nicipalities of Amsterdam15and Utrecht16, the Politie17, DigiD18, Kika19, Blogboek20, Gemboxx’s Regieboxx for "Sociale Zaken en Werk"21and DUO22. These websites contain both services that solely provide information and allow the user to log on to in order to perform certain actions, such as filling an income statement.
By navigating through these websites and analyzing the pages that appear on them, a final list of the most frequently occurring components is composed. Most frequently equals three or more occurrences on the above mentioned governance websites and applications.
List of components:
• Buttons, with text and/or icon – Button: add a new item – Button: edit an item – Button: delete an item – Button: download item – Button: upload item – Button: save item
– Button: navigate to an item – Button: navigate to an item large – Button: cancel action
– Icon: Facebook – Icon: Twitter – Icon: Notification-bell • Cards
– Card: containing textual information – Card: title, textual information and a button – Card: title, textual information and an image – Card: contact information
– Card: title-panel with buttons, textual information – Card: collapsable card wit title-panel, buttons and textual
information • Lists
– List: collapsable items – List: static items – List: dropdown
– Card: collapsable card with a list of two columns • Bars – Bar: navbar – Bar: menu • Other – Searchbar – Tooltip – Footer
The component-list contains components that fit the categories of the pyramidal structure of e-Government UI analysis described in Section 2.4: page level patterns, basic component patterns and
13 https://www.rijksoverheid.nl/ 14 https://www.overheid.nl/ 15 https://www.rijksoverheid.nl/ 16 https://www.utrecht.nl/ 17 https://www.politie.nl/ 18 https://www.digid.nl/ 19 https://www.kika.nl/ 20 https://www.blogboek.com/ 21 https://www.sozawe-nw-fryslan.nl/ 22 https://www.duo.nl/
screen flow patterns. Pontico et al. [36] also suggests to use wire-frames when developing UI-patterns, therefore wirewire-frames, includ-ing a description, are constructed for all of the listed components and can be found in Appendix C. However, the wireframes will solely function as a visual enlightenment of the list and as illus-tration while developing the component. The reason for this is the goal of the toolkit: to provide accessible components that are directly implementable, so not just as a pattern or wireframe. The toolkit should function as a helping hand for a designer involved in the development of e-governance websites and applications. Fur-thermore, the wireframes help to understand the components and make it easier to realize them, as they function as a proper example. Figure 5 shows a wireframe, transforming to a HTML-component.
4.2
Defining Golden Rules
Aiming at developing accessible web, the pyramidal model of Pon-tico et al. [36] is approached again: the bottom-layer of fundamen-tal Golden Rules mentioned in Section 2.4. Furthermore, apply-ing Golden Rules to any application is recommended in Human-Computer-Interaction design [41]. The UI-toolkit contains a page with Golden Rules. These Golden Rules will contain understandable guidelines in such way that following the Golden Rules will comply with the governmental standards and design heuristics of Nielsen [33]. For example, the requirement of making functional elements of a webpage accessible by keyboard [14], can be met by only using nativeHTML elements, or defining a role for the element. Such action is then formulated into a Golden Rule.
4.3
Creating UI components
Each component will consist ofHTML code, co-responding CSS code and a description, which are the necessary attributes for a design pattern [36]. The components will be based on Bootstrap classes, Version 3.3. This version is chosen as it is yet supported by the plat-form "Atalanta" in use by Gemboxx. Bootstrap is an open source toolkit for development inHTML, CSS and JavaScript, taking away the need for manualCSS classes or implementation of JavaScript-libraries. When applying bootstrap, all global and fundamental components inHTML become responsive automatically, and there are predefined accessibility measures included [11]. The Bootstrap components’ webpage23includes some documentation and exam-ples of ARIA-usage (explained in Section 2.6, which make some of the Bootstrap components accessible. Surprisingly, not all the components contain ARIA-attributes and surely not all the prede-fined components are accessible following the WCAG 2.0 rules. For example, the color-contrast-ratio of the predefined button classes do not conform the WCAG 2.0 requirements. In other words, ad-justment of the Bootstrap components is desired when realizing accessible e-governance UI components that are based on these bootstrap components. Fortunately, easy and stable ways are of-fered by Bootstrap that allow customization of the platform [34]. In this case, it is necessary to extend theCSS classes with properties that make the regardedHTML-component accessible, such as the background-color. Of course, also the Bootstrap HTML must be supplemented with correct ARIA-attributes and most importantly: the bootstrap-components will be combined and adjusted to fit the 23
https://getbootstrap.com/docs/3.3/components/
components in the list of most frequently occurring e-governance UI-components.
By taking into account the Golden Rules whilst developing the accessible components, accessibility should be guaranteed. As men-tioned previously, the components will consist of a title,HTML code and extendedCSS class(es), constructed by the following approach:
(1) Shortly describe the purpose of the component.
(2) Search for relevant Bootstrap component(s) and createHTML code (custom / bootstrap / both) similar to the wireframe design, while following the Golden Rules.
(3) ExtendCSS when necessary to conform to the golden rules. As a more dynamic way of applying components in software de-velopment, there is one intelligent component added: an intelligent color-contrast approach, represented as a button-shape. Intelligent components are essential as they minimize the amount of steps for a the web-developer or web-designer [30]. This intelligent com-ponent contains of a background and foreground of which the colors can be picker from a color-picker. By clicking a color in the color-picker, the background or foreground can be set, and the co-responding color-code is shown. The colors can be changed or swapped easily, but most importantly the contrast-ratio of the chosen colors is calculated and shown in square. The color of the square, which can be red, orange or green, with a subsequent mes-sage shows the developer or designer if the chosen colors can be used or not. By moving the cursor or slider in the color-picker, the color of the background or foreground can be changed until the square colors green. The added value of this component is that the developer or designer does not need to calcluate the contrast-ratio himself, and it gives him a live-view of the usage of two colors as text and background. Figure 6 shows a screenshot of the intelligent component with example values, Figure 7 shows an example of a component as it appears in the toolkit.
4.4
Composing the toolkit
As mentioned by Pontico et al., [36], a catalogue of UI patterns that strive for accessibility should be user-centered itself too. However, in this case, the toolkit only functions as a representation of a possible way in providing web-designers and web-developers with accessible components. The toolkit will be provided as an HTML-document with a page for each of the categories listed Section 4.1. This makes it easier to evaluate the components and the concept of the toolkit itself. Furthermore, the golden rules can be more easily implemented as just another page in the toolkit. The conceptual toolkit can be found on http://www.sodity.nl/colorcontrast.html, Appendix D shows a screenshot of the toolkit on the page "buttons".
5
EVALUATION
This section covers the evaluation of the composed toolkit.
5.1
Method
A highly recommended method for evaluating a tool or technology is the Technology Acceptance Model (TAM), founded by Davis, [18], [44]. This model involves several design features that influence the perceived usefulness and perceived ease of use (also known as the usability). Davis, [18] explains the perceived usefulness as the user’s belief on enhancing his job performance by using a
Figure 5: From wireframe to HTML-component: a Card with a title, textual information and a button
Figure 6: Intelligent component with color-picker
Figure 7: Final component appearance in the toolkit, with collapsible code-preview
particular system. The perceived ease of use is explained as the degree of physical and mental effort that is decreased by using a particular system. Together, these two factors form the user’s attitude or motivation towards using a system that determines the user’s actual use of the system.
As theHTML-document is an example representation of the toolkit, there is no need to take the perceived ease of use into account when doing the evaluation. Moreover, a study by Van der Heijden, [44] concludes that perceived usefulness in the context of utilitarian systems, where there are external goals, is more important and central to predicting user’s intention for using a system. External goals in this case focus on the concept of the toolkit, instead of the usage of the toolkit itself. Hence, the evaluation is done in terms of usefulness. Furthermore, usefulness is 1.5 times more important than the ease of use in predicting actual use, and predicts around 36% of the actual reported usage in general [18].
The TAM is used as quantitative research, and additional ques-tions are used a qualitative research. There will be a distinction made in the results. The following hypothesis holds for the quanti-tative part:
Applying accessible UI-components, represented in a conceptual toolkit is useful to web-designers and web-developers. The hypothesis is accepted when the average likert-value of the questionnaire explained in the next subsection, is more than 5, as from this scale-point the respondent somewhat agrees with the statement.
5.2
Questionnaire design
A questionnaire developed by the TAM-founder Davis [18] is proven to be able to measure the usefulness of a system and will be partly used as an instrument for the evaluation [44]. This questionnaire applies to user acceptance evaluation of tools and techniques in general.
A Likert-scale is used as scale, since it is the most commonly used type of instrument for measuring the usefulness of a system [31]. As confirmed by Johns, [26] data retrieved from Likert items are significantly less accurate when there are less than five or more than seven scale points used. Additionally, an odd amount of scale-points offers a neutrality point, which is preferred by respondents, and a seven-point scale offers more options to chose from and would deliver higher quality of data [26]. The TAM-based statements determine a value, equal to the likert-scale-point varying from 1 to 7 in which each number co-responds a level of agreement. 1-3 coversstrongly disagree, moderately disagree and somewhat disagree, 4 stands forneutral and 5-7 covers somewhat agree, moderately agree and strongly agree.
As the toolkit functions as a conceptual system from which its elements should be integrated into other systems, the questionnaire is enriched with several additional questions besides rating the TAM-based statements. One multiple-choice question (yes / no / other) regarding the extent to which the participant believes that intelligent components will enhance web-accessibility. Four open questions follow that require some input of the participant on (1) their experience with web-development and web-design, (2) the possibilities of integrating UI-components, as proposed, in their own development-environments, (3) whether they miss anything
in the toolkit and (4) some other remarks that did do not fit the other questions.
A pilot evaluation showed that some parts required little adjust-ments before performing the ’real’ evaluations. As an improvement of the toolkit, more textual explanations and a table showing the used colors and reasons for these choosing these colors were added. Secondly, some adjustments in the formulation of open questions was desired. Reformulating into more specific questions would re-trieve more specific information from the participants. The final questionnaire can be found in Appendix E.
5.3
Participants
The participants involved in the evaluation are web-designers and web-developers that have a proper understanding of working with HTML and CSS on the web. The participants are randomly selected out of a list of web-designers and web-developer in the near envi-ronment, with varying experience.
Starting with 4 participants as a baseline, the number of partici-pants are supplemented until there are no new aspects mentioned by the participants. In the end, 8 participants are part of the con-ducted study, as the 8th participant did not outline any new aspects. From now on, the participants are referred from p1 to p8. p1 to p6 are experienced webdesigners (more than two years of experience in the field), and p7 and p9 are less experienced webdesigners (less than two years of experience in the field, or only educational ex-perience). A more detailed description of the participants can be found in the brief table in Appendix F.
5.4
Set-up
The questionnaire, containing both TAM-based statements to be rated and additional questions in a Google Form24. First, the partic-ipants were approached by sending them a message with a request to join this study. When agreed, the Google Form is send to them. After reading a short introduction, the participant is asked to take a look at the toolkit, that can be navigated to by means of a provided link. Firstly, the multiple-choice question about the intelligent component is asked, for which the participant is asked to try out the component. Secondly, the set of TAM-based statements are provided and the participant is asked to rate them, based on the likert-scale. Finally, the participant is guided to the open questions.
5.5
Results
The results of 8 participants involved in the evaluation process can be split up into two parts: (1) the outcomes of the TAM-based statements and (2) the outcomes of the additional questions.
5.5.1 Quantitative. Figure 8 shows for each of the TAM-elements the average score of the 8 participants. The average score of all TAM-elements measured among all participants is 5.03, which im-plies that the hypothesis is accepted on the edge.
5.5.2 Qualitative. Applying of UI components is common knowl-edge among web-developers and web-designers, conformed by all participants mentioning they have used them. However, they do not actively think about accessibility measures and in most cases just do what they think is necessary, when it comes to choosing a color 24
https://www.google.com/forms/about/
1: strongly disagree 2: moderately disagree3: somewhat disagree 4: neutral 5: somewhat agree 6: moderately agree 7: strongly agree
7-point Likert scale
TAM-element 5.3 Improves performance 4.9 Saves time 4.4
Enables to accomplish tasks more quickly
5.1
Supports critical aspects
5.0
Enhances effectiveness
5.1
Increases productivity
5.1
Makes the job easier
5.4
Is overall useful
Score averages per TAM-element
Figure 8: Diagram showing the results of the evaluation, with the applied likert-scale on the horizontal axis and the TAM-element on the vertical axis
or writing a piece of HTML-code. A lack of front-end guidance in their current workaround was mentioned byp2, p3 and p5, the Golden Rules were considered to be a nice set-up for that. However, these Golden Rules were experienced a bit general and could be matched with specific components.
The toolkit was considered rather complete, but a few partici-pants (p2 and p7) mentioned that they missed a mobile development category. Despite the fact that such components are made respon-sive, specific guidance for mobile development is desired, regarding the accessibility measures. Also, in cases where the component works responsively, there could be more guidance on how to make them act responsively. Another aspect missing were animations and effects, like possible withJQuery libraries.
The intelligent component was considered to be useful by almost all of the participants (p1-p5). 75% of them claimed that they would use such components for increasement of the accessibility of their delivered software. The other 25% mentioned that they think the intelligent components could be helping, yet one should keep in mind that changing the designer’s workaround could also create frustration.p4 even mentioned that designers would already have a proper feeling for things like color-contrast, and therefore intelli-gent components could be unnecessary.p1 and p2 recommended that intelligent components could be implemented as a browser plug-in or extension.
6
DISCUSSION
From the results of the evaluation it became clear most web-designers and web-developers do not realize the importance of web-accessibility nor the presence of grounded rules. As one of the participants men-tioned that designers would already have enough skills to provide accessible components, there seems to be a lack of realization. The
extent to which governmental ICT fails in terms of accessibility causes to think that the skills are not there, but the problem seems to be that most designers and developers think they do have the skills or pay sufficient attention. E-governance applications are being used throughout society and thus involve multiple types of users. Varying ages, IT-affinity, education-levels and other factors influence the desires and skills of the users. Thus, more aware-ness of web-accessibility is desired within e-governance. Hopefully, there will be more attention payed to web-accessibility since the legal obligation applies, in terms of the more strict law.
The results also showed that two individual TAM-elements did not pass the required value of5; the element concerning time saving, and the element concerning accomplishing tasks more quickly. This came as a surprise, as one of the purposes of the toolkit was to save the designer’s and developer’s time. A logical outcome of reusing software components [47]. It turned out that most participants do not keep themselves busy with accessibility or think they already do so. This could explain why these elements, regarding time, scored below5: applying the toolkit and following the Golden Rules whilst doing their job will appear as an extra task. Having to work with the toolkit will, in that sense, only cost more time.
When taking a deeper look into the pyramid model of Pontico et al., [36] the three top layers can be divided into sub-categories that each represent a certain type of that layer. For example, at the level of the basic components, there is a distinction made between conditional activation fields, download links or buttons, mandatory fields, non-textual objects, pre-formatted form fields and typography. The UI components, that are most likely to by expanded with more components, could have been categorized into such sub-categories to create a more specific UI-component catalog. The current toolkit contains category-titles that are solely based on a list of frequently occurring components, without further explanation. As the toolkit is only evaluated on its usefulness, it could have been better to also pay attention to its usability as it could affect the way the toolkit is interpreted by the participants. Also, when extending the existing components, it could make navigating and searching through a large amount of components more comfortable and consistent.
One could say that web-accessibility concerns everything on the web that is approached by users. This study solely aims at governance, and the accessible components created occur on e-governance websites and web-applications. However, this scope does not necessarily imply that these components only occur on the web of e-governance. Therefore, the components could also be applied for other disciplines, for example e-commerce, to enhance the web-accessibility of other domains. However, e-governance does focus on primary aspects such as health-care and education, which is more essential than buying a new piece of clothing online. E-governance services include aspects that every citizen must use, like requesting a valid ID. There should be taken into account that e-governance is a domain of its own, distinguishable from other domains on the importance of processes that take place.
As a final discussion point, the methods for providing web-accessibility could have been taken more into account when evalu-ating the toolkit. The evaluation showed that a set of Golden Rules guides web-designers and web-developers through developing ac-cessible web. However, the quality of these Golden Rules, in terms of their origin in Nielsen’s design heuristics [33], reformulated WCAG 11
guidelines and other web-accessibility methods such as ARIA, were not taken into account. Hence, a solid conclusion on the quality of the Golden Rules can not be made.
7
CONCLUSION
In conclusion, with regard to the research question:RQ: How can the accessibility of Dutch e-governance websites and applications be enhanced by applying UI components in their development?, this study has shown that applying UI-components in e-governance development, most likely will improve the accessibility of Dutch e-governance. This may be concluded as applying accessible UI-components, represented in a conceptual toolkit is useful to web-designers and web-developers. If web-web-designers and web-developers apply these accessible components, the systems that roll out and are based on them will be accessible.
As covered, there are roughly two requirements for a Dutch e-governance application or website, namely aligning with chapter 9 of EN301549, which equal to the WCAG 2.0, and providing an accessibility statement. By taking a look at the WCAG 2.0 in detail, one will notice that most of the guidelines are vague, and turning them into Golden Rules made them more clear for designers and developers. For providing web-accessibility, the Government offers a road-map. As mentioned, this road-map contains 4 steps that are meant to iterate over. Nielsen’s heuristics are proven to be reliable standards and guidance for enhancing usability and accessibility, and are also taken into account in the golden rules. Combining the WCAG 2.0 with design heuristics offers a reader-friendly list of guidance. Finally, applying ARIA-attributes ensures that screen-readers are useful, as they pick the ARIA-attributes for explaining semantics and functionality to its users. Thus, applying at least the obligated WCAG 2.0 and design heuristics in the form of Golden Rules and ARIA should be taken into account when developing for the accessible Dutch e-governance.
Overall, the UI-toolkit was considered as an effective method for enhancing accessible e-governance. Applying components in general turned out to be common knowledge among web-designers and web-developers, and such a toolkit would take away the effort of struggling with complexly formulated guidelines. Intelligent components have potential to get used and stimulate accessible-web-development.
8
FUTURE WORK
The WCAG 2.0 is being extended for the first time since 2008, by the WCAG 2.1, halfway 2018 [27]. This new version is not yet advanced and therefore not in use yet. Reid and Snow-Weaver, [38] mention that the applying the WCAG should evolve along with the the technological and usability-related developments in order to ensure web-accessibility: this could be the breakthrough. New success criteria, principles, levels or other changes must be taken into account when applying UI-components, as the components will most likely need to be updated themselves. There should be kept an eye on the regulations, so that the components are aligned with the law.
In this study, the delivered components are based om Bootstrap 3 components. The main reason for choosing Bootstrap 3 as a base, is that Bootstrap 3 is currently supported by the Grexx platform, the
platform that Gemboxx develops its software on. From the moment that Bootstrap 425will be supported, there could be a revision on the components. For example the button-classbtn btn-danger in Bootstrap 3 comes with a color-ratio that is too low to conform to the WCAG 2.0 standards, but in Bootstrap 4 this specific button comes with a sufficient color-ratio. However, not all Bootstrap 4 components are yet accessible; there is still some revision required on theCSS that is applied, for example on some other buttons. As there are also other platforms that provide reusable components, there should be taken a look at other platforms to base the compo-nents on other types of compocompo-nents, or combine them into a set of accessible components.
As mentioned in the Discussion, the Golden Rules need to be researched more in terms of their quality and power of guaranteeing web-accessibility. Also, applying the toolkit to other domains is a proper subject for future work.
Finally, as a future work recommendation there should be an extension of the intelligent components. Intelligent components could appear in many more forms and ways than the proposed contrast-ratio: complete templates or pages could be constructed by using intelligent components. Additionally, as seen in the evaluation results, there could be researched how the intelligent components could be implemented in browser plug-ins and extensions. When doing this, there should also be taken a look at the existing plug-ins and extensions regarding web-accessibility.
9
ACKNOWLEDGEMENTS
I would especially like to thank Frank Nack for being an excellent supervisor. Additionally, I would like to thank all the participants who were willing to join the evaluation process and Gemboxx for her enthusiasm.
REFERENCES
[1] [n. d.]. GemboxxGemboxx ICT-projecten . http://gemboxx-ictoplossingen.nl/. ([n. d.]).Accessed March 21, 2018.
[2] [n. d.]. Ministerie van Binnenlandse zakenWat is Verplicht? https://www. digitoegankelijk.nl/beleid/wat- is- verplicht. ([n. d.]).Accessed March 21, 2018. [3] [n. d.]. Ministerie van Binnenlandse zakenWet digitale overheid. https://www.
digitaleoverheid.nl/voorzieningen/identificatie- en- authenticatie/eid/wet- gdi/. ([n. d.]).Accessed April 22, 2018.
[4] [n. d.]. Nederlands Jeugd InstituutNationale Jeugdzorgprijzen 2014. https://www. nji.nl/nl/Download- NJi/Rapport- clientjury- Nationale- Jeugdzorg- Prijzen- 2014. pdf . ([n. d.]).
[5] 2013.Protocol stranding levende grote walvisachtigen (1 ed.). Vol. 1. Ministerie Economische Zaken.Accessed June 21, 2018.
[6] 2015. https://nos.nl/nieuwsuur/artikel/2029208-mislukte-ict-projecten-en-andere-ict-missers.html. Mislukte ICT-projecten en andere ICT-missers (Apr 2015). https://nos.nl/nieuwsuur/artikel/ 2029208- mislukte- ict- projecten- en- andere- ict- missers.html
[7] 3PlayMedia. [n. d.]. WCAG 2.0: Bringing Web Accessibility into the 21st Century. ([n. d.]).
[8] Fernando Alonso, José Luis Fuertes, Ángel Lucas González, and Loïc Martínez. 2010. On the testability of WCAG 2.0 for beginners. InProceedings of the 2010 International Cross Disciplinary Conference on Web Accessibility (W4A). ACM, 9. [9] Mehdi Asgarkhani. 2005. The Effectiveness of e-Service in the Public Sector: A
Local Government Perspective.. InECEG. 17–26.
[10] Lisa Benson, Dean Elliott, Michael Grant, Doug Holschuh, Beaumie Kim, Hyeon-jin Kim, Erick Lauber, Sebastian Loh, and Thomas C Reeves. 2002. Usability and instructional design heuristics for e-learning evaluation. InEdMedia: World Con-ference on Educational Media and Technology. Association for the Advancement of Computing in Education (AACE), 1615–1621.
[11] Snig Bhaumik. 2015.Bootstrap Essentials. Packt Publishing Ltd.
25
https://getbootstrap.com/docs/4.1/getting- started/introduction/
[12] Giorgio Brajnik, Yeliz Yesilada, and Simon Harper. 2010. Testability and validity of WCAG 2.0: the expertise effect. InProceedings of the 12th international ACM SIGACCESS conference on Computers and accessibility. ACM, 43–50.
[13] Giorgio Brajnik, Yeliz Yesilada, and Simon Harper. 2012. Is accessibility confor-mance an elusive property? A study of validity and reliability of WCAG 2.0.ACM Transactions on Accessible Computing (TACCESS) 4, 2 (2012), 8.
[14] Ben Caldwell, Michael Cooper, Loretta Guarino Reid, and Gregg Vanderheiden. 2008. Web content accessibility guidelines (WCAG) 2.0.WWW Consortium (W3C) (2008).
[15] Angèle LM Cavaye. 1995. User participation in system development revisited. Information & Management 28, 5 (1995), 311–323.
[16] Wendy Chisholm and Matt May. 2008.Universal design for web applications: Web applications that reach everyone. " O’Reilly Media, Inc.".
[17] World Wide Web Consortium et al. 2014. Accessible rich internet applications (WAI-ARIA) 1.0. (2014).
[18] Fred D Davis. 1985.A technology acceptance model for empirically testing new end-user information systems: Theory and results. Ph.D. Dissertation. Massachusetts Institute of Technology.
[19] Pieter Derks. 2014. (2014). https://www.youtube.com/watch?v=hziRCWhUmCA Accessed June 21, 2018.
[20] Iyad Abu Doush, Faisal Alkhateeb, Eslam Al Maghayreh, and Mohammed Azmi Al-Betar. 2013. The design of RIA accessibility evaluation tool. Advances in Engineering Software 57 (2013), 1–7.
[21] The ETSI, CEN, and GENELEC. 2015. Accessibility requirements suitable for public procurement of ICT products and services in Europe. InProceedings of the 12th international ACM SIGACCESS conference on Computers and accessibility. European Standard ETSI.
[22] Alexander G Fiks, Stephanie Mayne, A Russell Localio, Evaline A Alessandrini, and James P Guevara. 2011. Shared decision-making and health care expenditures among children with special health care needs.Pediatrics (2011), peds–2011. [23] F Javier García, María Lozano, Francisco Montero, Jose Antonio Gallud, Pascual
González, and Carlota Lorenzo. 2007. A controlled experiment for measuring the usability of webapps using patterns. InEnterprise Information Systems VII. Springer, 257–264.
[24] Wouter Hamstra and René Notenbomer. 2011. . GemeenteOplossingen. [25] Richard Heeks. 2001.Understanding e-governance for development. Institute for
Development Policy and Management Manchester.
[26] Rob Johns. 2010. Likert items and scales.Survey Question Bank: Methods Fact Sheet 1 (2010), 1–11.
[27] Andrew Kirkpatrick, Joshue O Connor, and Michael Cooper. 2018. Web content accessibility guidelines (WCAG) 2.1.WWW Consortium (W3C) (2018). [28] Ron Mace. 1997. What is universal design.The Center for Universal Design at
North Carolina State University. Retrieved Retrieved November 19 (1997), 2004. [29] AJ Meijer, GJ Brandsma, SG Grimmelikhuijsen, and GDA Werner. 2009. Waarde
van e-participatie voor integrale dienstverlening. (2009).
[30] Hafedh Mili, Odile Marcotte, Anas Kabbaj, et al. 1994.Intelligent component retrieval for software reuse. InProceedings of the Third Maghrebian Conference on Artificial Intelligence and Software Engineering. 101–114.
[31] Tomoko Nemoto and David Beglar. 2014. Likert-scale questionnaires. (2014). [32] Jakob Nielsen. 1994. Usability inspection methods. InConference companion on
Human factors in computing systems. ACM, 413–414.
[33] Jakob Nielsen. 1995.10 usability heuristics for user interface design.Nielsen Norman Group 1, 1 (1995).
[34] Christoffer Niska. 2014.Extending Bootstrap. Packt Publishing Ltd.
[35] David Pinelle, Nelson Wong, and Tadeusz Stach. 2008. Heuristic evaluation for games: usability principles for video game design. InProceedings of the SIGCHI Conference on Human Factors in Computing Systems. ACM, 1453–1462. [36] Florence Pontico, Marco Winckler, and Quentin Limbourg. 2008.Organizing
user interface patterns for e-Government applications. InEngineering Interactive Systems. Springer, 601–619.
[37] Devendra D Potnis. 2010. Measuring e-Governance as an innovation in the public sector.Government Information Quarterly 27, 1 (2010), 41–48.
[38] Loretta Guarino Reid and Andi Snow-Weaver. 2008. WCAG 2.0: a web accessibility standard for the evolving web. InProceedings of the 2008 international cross-disciplinary conference on Web accessibility (W4A). ACM, 109–115.
[39] Dagfinn Rømen and Dag Svanæs. 2012. Validating WCAG versions 1.0 and 2.0 through usability testing with disabled users.Universal Access in the Information Society 11, 4 (2012), 375–385.
[40] KBC Saxena. 2005. Towards excellence in e-governance.International Journal of Public Sector Management 18, 6 (2005), 498–513.
[41] Ben Shneiderman. 1997. Designing the User Interface: Strategies for Effective Human-Computer Interaction (3rd ed.). Addison-Wesley Longman Publishing Co., Inc., Boston, MA, USA.
[42] John M Slatin and Sharron Rush. 2002.Maximum accessibility: making your web site more usable for everyone. Addison-Wesley Longman Publishing Co., Inc. [43] Sanne-lot van Ulzen. 2011. Testrapport Blogboek. (2011).
[44] Hans Van der Heijden. 2004. User acceptance of hedonic information systems. MIS quarterly (2004), 695–704.
[45] Liza van Lonkhuyzen and Derk Stokmans. 2017. Hoe de overheid 100 miljoen uitgaf aan drie ict-mislukkingen.NRC (Dec 2017). https://www.nrc.nl/nieuws/ 2017/12/01/het- systeem- is- niet- beschikbaar- a1583436
[46] Sanne-Lot van Ulzen and Sylvia van der Pal. 2015. Blogboek: geef ouders de eigen regie over het zorgproces, met steun van professionals.Tijdschrift voor gezondheidswetenschappen 93, 2 (2015), 51–52.
[47] Kamen Vitanov, Michael Shenfield, and Brindusa Fritsch. 2005. System and method for executing wireless applications using common UI components from a UI repository. (Sept. 1 2005).US Patent App. 10/787,948.
Appendices
A
WCAG REPORT
WCAG 2.0 Accessibility Check
Sodfa Shafik, may 2018
2 of 14
