Process Model for Continuous Testing of Web Accessibility

The lack of accessibility on websites can result in people with disabilities not accessing information online. Therefore, this research aims to create a process model for continuous web accessibility testing by adapting and customizing three methodologies: Deming cycle (Plan, Do, Check, Act), Website Accessibility Conformance Evaluation Methodology (WCAG-EM), and Total Quality Management. The process model is composed of four phases. The first phase (Plan) allows defining the accessibility problem, its importance, and the Web Content Accessibility Guidelines (WCAG) against which it will be evaluated. In addition, determine the current situation of the websites, the potential causes of accessibility problems, classify the success criteria by principles, guidelines, and levels of conformity, to elaborate the solution plan and the action plan. The second phase (Do) allows the execution of the action plan to correct the accessibility problems. In this phase, we should perform continuous testing with automatic evaluation tools, end-users, and experts to corroborate that the changes have had an effect. The third phase (Check) allows measuring compliance and non-compliance with the defined Key Performance Indicators (KPIs). This phase also explains the reasons for non-compliance. The fourth and last phase (Act) documents the solutions learned for inclusion in future developments. This research results in the process model for continuous web accessibility and its testing through a case study to corroborate its functionality and applicability. In conclusion, the proposed model allows continuous evaluation, monitoring, and feedback on compliance with accessibility rules, policies, and standards on websites with automatic evaluation tools, end-users, and experts. We plan to adapt the process model to different workgroups in future work, such as developing accessible mobile applications and producing accessible electronic documents.


I. INTRODUCTION
Digital transformation and technological innovations benefit people and improve their quality of life through access to information. Websites play a crucial role in digital transformation. However, the lack of accessibility on websites can make it difficult for people with disabilities to access content published on the Web. Therefore, websites must comply with accessibility standards.
Tim Berners-Lee, Director of the World Wide Web Consortium (W3C) and inventor of the World Wide Web [1], The associate editor coordinating the review of this manuscript and approving it for publication was Antonio Piccinno . states that ''the power of the Web is in its universality. Access by everyone regardless of disability is an essential aspect''. In addition, Shawn Lawton [2], leader of education and outreach activities at the W3C's Web Accessibility Initiative (WAI), states that ''accessibility is essential for developers and organizations that want to create high-quality websites and web tools, and not exclude people from using their products and services''. In addition, ''it gives advice on how to make content usable for people with cognitive and learning disabilities. This includes, but is not limited to: cognitive disabilities, learning disabilities, neurodiversity, intellectual disabilities, and specific learning disabilities'' [3]. Today the W3C is the leading source of information on universal web accessibility. The W3C has published the Web Content Accessibility Guidelines (WCAG) for the design and development of accessible web content [4]. Also, WCAG in some countries has been regulated as laws and policies for compliance on the websites [5]. These benefit all users who use the Web (illiterate, unsure or inexperienced users, the elderly, among others), not only people with disabilities.
The World Health Organization (WHO), in its 2011 World Disability Report, estimates that ''more than a billion people are estimated to live with some form of disability, or about 15 % of the world's population (based on 2010 global population estimates). This estimate is higher than previous World Health Organization estimates, which date from the 1970s and suggested around 10 %'' [6, pp. 7]. In addition, the number of people living with a disability is increasing in the population due to aging and the increase in chronic diseases [7], [8].
In this paper, we present a novel process model for continuous testing of web accessibility. This research is considered relevant because no known process model proposes continuous testing of web accessibility in organizations. Continuous testing of accessibility is essential to evaluate, correct errors, provide feedback from a systemic perspective, and provide universal accessibility on the Web. For which, this paper aims to propose a process model that encompasses the Deming cycle (Plan, Do, Check, Act) [9], Website Accessibility Conformance Evaluation Methodology (WCAG-EM) [10], and Total Quality Management (TQM) [11]. To arrive at the proposed model, we apply design science research by developing different artifacts.
The continuous testing process model that we propose, unlike other web accessibility methodologies, adapts the Deming cycle of continuous improvement, the WCAG-EM methodology, and TQM. The proposed process model in the ''Plan phase'' defines the accessibility problem and its causes. In addition, the WCAG-EM methodology determines the current situation of the websites according to the WCAG success criteria to elaborate the solution plan. In the ''Do phase'', the action plan is executed by assigning people responsible for each activity, resource, and start and end dates. For this, sufficient techniques, advisory, and failures must be reviewed to solve the accessibility problems. The ''Check phase'' measures compliance with the WCAG success criteria. The ''Act phase'' allows lessons learned to be documented for future bug fixes in subsequent iterations of the continuous testing cycle. Finally, in this phase, existing and new accessibility problems are identified for the next iteration.
This paper is divided into the following sections. Section II presents the background of the main concepts of the Deming cycle, web accessibility, and TQM. Section III presents the literature review on ''web accessibility and continuous testing'' and ''software and continuous improvement''. Section IV presents our new process model for continuous testing of web accessibility. Section V presents the case study to corroborate the functionality and applicability of our process model. Section VI presents the discussion. Section VII presents the limitations of this study. Finally, conclusions and future work are presented in Section VIII.

II. BACKGROUND
This section presents the concepts necessary to understand the Deming cycle, web accessibility, and TQM.

A. DEMING CYCLE
The Deming cycle of Plan-Do-Check-Act (PDCA) is a methodology for continuous improvement [12]. The PDCA cycle involves identifying opportunities for improvement, proposing change solutions, then implementing them in practice, adjusting and evaluating the solutions before deciding whether to modify, abandon or maintain such changes [13]. The continuous quality improvement includes: 1) top management commitment, 2) empowering managers to understand and accept the long-term commitment to pursue quality improvement, learn from best practices and share experiences, 3) providing the necessary training and resources, 4) improving the process, with numerous solutions, and 5) using data to manage and feedback into the process [14]. In addition, Deming has emphasized the need to: ''Improve constantly and forever the system of production and service'' [15] and ''Cease dependence on inspection to achieve quality. Eliminate the need for inspection on a mass basis by building quality into the product in the first place'' [16].
The PDCA cycle can also be applied to software testing. To do this, first, define the objectives of the process, then develop and implement a plan to achieve those objectives, and, finally, verify whether the planned results are achieved. If not, must modify the plan until the goals are achieved. Each stage is described below [17]: • Plan. The main output of this stage is the software test plan. This plan should be adjusted as changes are made to the systems. The outline of a good test plan includes an introduction, the requirements, and the overall plan.
• Do. This stage describes how to design and execute the tests included in the plan. The test design should be built with procedures, scripts, matrices, test cases, expected results, test logs, etc. The test team is responsible for executing the tests using tools, resources, conditions, and requirements, among others, and is also the one who must ensure that the tests are performed according to the plan.
• Check. This stage includes assessing the progress of compliance with the test plan. It is important to make decisions based on accurate and timely data. Test metrics (such as number, type of defects, workload, and schedule status) are critical. The test report should include records of defects found, data reduction techniques, root cause analysis, conclusions, and suggestions for process improvement.
• Act. This stage of software testing involves designing appropriate measures to address results that did not foresee in the plan. These measures feedback into the plan. VOLUME 9, 2021 The PDCA cycle is a tool that can also use to manage processes and systems. The PDCA cycle is described by ISO 9001:2015 as follows [18]: • Plan. Establish the objectives of the system and its processes and the resources needed to deliver results by customers' requirements and the organization's policies and identify and address risks and opportunities.
• Do. Implement what was planned.
• Check. Monitor and (where applicable) measure processes and the resulting products and services against policies, objectives, requirements, and planned activities, and report the results.
• Act. Take actions to improve performance, as necessary.
Idem the PDCA cycle of continuous improvement applies to the software testing process [19]:  Figure 1 shows the principles, guidelines, success criteria, and conformance levels of WCAG 2.1.

2) WEBSITE ACCESSIBILITY CONFORMANCE EVALUATION METHODOLOGY (WCAG-EM)
For the evaluation of websites with WCAG 2.0, the W3C/WAI has developed WCAG-EM [10]. Website accessibility evaluators can make use of this methodology to obtain more reliable results and avoid common errors. This methodology has five interrelated steps, which can be seen in Figure 2.
Each step has an arrow to the next step and arrows to return to all previous steps. This flow illustrates how evaluators advance from one stage to the next and can return to any previous step in the process as new information is revealed to them during the evaluation process [10].

3) WEB ACCESSIBILITY EVALUATION METHODS
Evaluation methods define the procedures, evaluation tools, end-users, and experts who assist in evaluating websites. In a systematic literature review (SLR) carried out in 2019 [25], on web accessibility evaluation methods, it was determined that: ''1) automatic tools, 2) evaluation by experts and 3) user tests are the most widely used techniques according to the literature''. In another SLR carried out in 2020 [26], we synthesized the results of 23 papers on the accessibility of educational websites. We determined that the three methods used in the analyzed works are: ''1) automatic methods through software or online services 80 % of the selected works; 2) manual methods with validation by experts and real users 12 %; 3) the combination of both 8 %''.
On the other hand, should conduct evaluations with users [27] who make use of the websites utilizing formal or informal experiments. These experiments allow the evaluator to observe whether the user can easily navigate the website and their behavior. In addition, it can identify accessibility problems based on observations, interviews, questionnaires, user comments, etc.
The evaluation of the accessibility of websites must be carried out with automatic general and specific tools, users, experts, and people with disabilities to be objective [28]. Therefore, must conduct effective evaluations with end-users and web accessibility experts.

C. TOTAL QUALITY MANAGEMENT
Today, TQM is an essential driver for the growth and success of organizations through their competitive improvement in local and international markets [29]. Therefore, TQM is the art of managing together to achieve excellence. Only by changing the actions of the management will the culture and activities of the entire institution be transformed [30]. In addition, technologies make it possible to offer high-quality services to users.

III. LITERATURE REVIEW
In the following literature review, published articles on software and continuous improvement are searched and analyzed. This review is conducted in two stages. In the first stage, reviewed articles on web accessibility and continuous testing. In the second stage, reviewed articles on software and continuous software improvement. The purpose of this study is to check if similar work to our proposal has been done.

A. WEB ACCESSIBILITY AND CONTINUOUS TESTING
The literature review on web accessibility and continuous testing was conducted using the following keywords: ''web accessibility'', ''continuous testing'', ''software accessibility'', ''app accessibility'' and the combination of these. Three  After applying the search strings in the scientific databases, no studies could be found as a result. This search allows us to determine that no similar work has been carried out.

B. SOFTWARE AND CONTINUOUS IMPROVEMENT
The literature review on software and continuous improvement was performed using search strings that included the following terms: (software* OR ''software testing'' OR ''software development'') AND (''continuous quality improvement'' OR CQI OR ''Deming cycle'' OR PDCA). These terms were searched for in the titles and abstracts of the articles. For this purpose, we created three equivalent query strings, one for the IEEE Xplore database, one for Scopus database, and one for the Web of Science database: We found three articles in the IEEE Xplore database, six in Scopus, and none in the Web of Science with these query strings. Of the nine articles, repeated three, and two were in the Chinese language, so discarded them. Of the remaining four, one did not refer to software testing, so it was also discarded, leaving the three articles that are summarized in Table 1. It should note that the application of the search string in the scientific databases was carried out on 24/06/2021.
In summary, in the literature review on software and continuous improvement, some authors can see that the PDCA cycle is used in continuous testing in software development. However, WCAG compliance is not considered in testing. Unlike the previous ones, our research focuses on developing a process model to continuously test the accessibility and create a quality culture in organizations by implementing the WCAG on their web pages. This research provides a framework for making web pages more accessible and usable by the maximum number of people and assessing the current state of websites in organizations. The process model for continuous testing of web accessibility uses the Deming cycle of continuous improvement to guide this process without losing sight of the organization's goals and TQM. In addition, it uses the WCAG-EM methodology to determine the current state of websites in terms of accessibility. The proposed process model becomes an iterative cycle of continuous improvement for the development, design, maintenance, and accessibility testing of web content and applications.

IV. NOVEL METHODOLOGY PROPOSAL
To achieve continuous testing of web accessibility, we propose the integration of the Deming cycle [9], [29], the WCAG-EM methodology [10] and TQM [34]. The map of the integration of the Deming cycle, the WCAG-EM methodology, and TQM can be seen in Figure 3.

A. PHASE I -PLAN
Planning focuses on identifying the objectives and the framework for deploying activities to achieve quality [35]. Therefore, planning for continuous testing of web accessibility involves organizing the process by developing the necessary actions to collect and evaluate information in an organized and structured way. In addition, must use quality principles to ensure the rigor of the process and greater objectivity in the results. This phase aims to define the project, analyze the current situation, analyze possible causes, and plan solutions.

1) DEFINE THE PROJECT a: DEFINE THE PROBLEM
The problem must contribute to a topic of current interest and relevance that presents unknowns that must answer. To this end, a review of the background of the research should be carried out and delimited the geographical and temporal space.

b: ANALYZE THE IMPORTANCE OF THE PROBLEM
According to Shawn Lawton, ''making the web accessible benefits individuals, businesses, and society'' [2]. Hence the importance of eliminating accessibility problems and providing people with disabilities equal rights in society [36]. In addition, web accessibility also benefits the elderly and people without disabilities [22]. In many countries, there are web accessibility laws and policies that regulate discrimination in accessing the information on the Web, service, or product by people with disabilities [5]. For this reason, if users with disabilities cannot access a website's content, they can file a digital discrimination lawsuit. These lawsuits occur more frequently each year and often cost institutions millions of dollars to resolve [37].

c: DEFINE CONTROL INDICATORS
Indicators help to assess whether corrections have been successfully implemented, as they measure the improvement or reduction of accessibility problems [38]. Therefore, the WCAG success criteria are our indicators for measuring and evaluating web accessibility. The accessibility problems found in the success criteria are defined as key performance indicators (KPIs). For executives and decision-makers, KPIs are considered strategic assessment tools to promote the achievement of excellence through knowledge discovery and evaluation [39]. KPIs are developed based on the causes of accessibility problems. For example, if it is discovered that images on websites have no alternative text, the KPI would be ''ensure that all img elements on websites have an alt attribute with a short description of the image''.

2) ANALYZE THE CURRENT SITUATION a: DEFINE THE EVALUATION SCOPE
The objective of this step is to define the scope of the evaluation. In addition, the conformance level (A, AA, AAA), accessibility support (web browser, assistive technologies, and other user agents), and additional evaluation requirements.

b: EXPLORE THE TARGET WEBSITE
This step is intended to allow the evaluator to explore the website to understand its functionality, use, and purpose better. It also allows the evaluator to identify the different pages, the technologies used, and the relevant functionalities.

c: SELECT A REPRESENTATIVE SAMPLE
The purpose of this step is to select a representative sample of the web pages to be evaluated. This sample will ensure that the evaluation results reflect the accessibility of the entire site with sufficient reliability. The most common selection methods are all websites of an organization, sampling, random selection, among others.

d: AUDIT THE SELECTED SAMPLE
The purpose of this step is to evaluate the sample of selected websites according to the WCAG and compliance levels  (A, AA, and AAA). In the results, we will indicate whether the sample as a whole or per website meets or does not meet the success criteria and conformance levels.

e: REPORT THE EVALUATION FINDINGS
The purpose of this step is to present in detail the accessibility report of the evaluated websites. The first sub-step defines the mandatory information to be included in the report. In the other four sub-steps, additional information can be presented to support the report (optional). The results obtained from this evaluation report are the web accessibility issues according to the WCAG success criteria that will work on in the following steps.

3) ANALYZE POTENTIAL CAUSES a: INVESTIGATE THE CAUSES OF THE PROBLEMS
According to Shawn Lawton [40], the techniques (Sufficient Techniques, Advisory Techniques) and failures for WCAG The objective of this sub-step is to group the common accessibility errors found. In addition, they are classified according to conformance levels (A, AA, and AAA).

4) PLANNING SOLUTIONS
A format for data collection has been designed for solution planning. The following sub-steps have been combined in this format: report the evaluation findings, analyze potential causes, and plan solutions. For each web accessibility problem, must find solutions. Therefore, the purpose of this sub-step is to list the web accessibility problems encountered and the solutions to be adopted as KPIs.

b: IDENTIFY PRIORITIES
The priorities have been defined on a scale of 1 to 3. The success criteria, with their levels of conformance, scale, and impact, are listed below: • High Impact. Web accessibility problems found in the success criteria with a conformance level A have priority 3. • Medium Impact. Web accessibility problems found in the success criteria with a conformance level AA have priority 2.
• Low Impact. Web accessibility problems found in the success criteria with a conformance level AAA have priority 1. The accessibility problems that have a high impact on the websites are colored red, medium impact yellow, and low impact green. Figure 6 shows the impact by conformance level and rating scale.

c: ELABORATE ACTION PLAN
The action plan is a document that allows the understanding of the success criteria with accessibility problems based on the KPIs. In addition, it will enable the assignment of responsibility for the fulfillment of each KPI with scheduled dates and human and financial resources. A format has been designed for the planning of activities. Figure 7 shows the data to be included in each of the columns by answering the following questions: 1) What? Meet KPIs, for which milestones must be established. For example, in 2 weeks, achieve 50 % compliance; in 4 weeks, achieve 75 %; in 6 weeks, achieve 100 %. 2) How? Apply WCAG techniques and failures that provide specific guidance to developers on how to develop accessible web content. 3) Who? Choose a person responsible for the execution of each planned solution. 4) When? Determine the range of start and end dates according to a schedule of activities to be executed.

5)
With what? Define the human, material and financial resources that will be involved in the website changes. 6) Why? Justify why the WCAG success criteria must be met. VOLUME 9, 2021 B. PHASE II -DO 1) IMPLEMENT SOLUTIONS a: EXECUTE ACTION PLAN Implement the planned changes. It is not enough to establish an action plan; it is necessary to monitor compliance with our solutions list continuously. In addition, it is essential in the execution of the action plan to perform acceptance tests that include the evaluation of the KPIs of interest (such as performance, security) and to assess whether the release candidate meets the established objectives [41]. It is also necessary to define strategies that provide solutions to problems that may arise during the plan's implementation. Figure 8 shows the process for executing the KPIs of the action plan. This process starts by analyzing the KPIs (see Figure 7) defined in the action plan. Then, they are resolved using the WCAG techniques and failures until the websites meet the WCAG success criteria.

C. PHASE III -CHECK 1) MEASURING RESULTS a: COLLECT AND EVALUATE RESULTS
Collect control data and evaluate the results. This is done through ongoing website evaluations to measure compliance with the accessibility problems listed in the Solution Plan. According to ISO/IEC 25000:2005 [42], software quality assessment is a ''systematic examination of the extent to which a software product is capable of satisfying stated and implied needs''. Therefore, the objective of this sub-step is to measure compliance with the KPIs and identify new accessibility problems generated by changes in the websites.

D. PHASE IV -ACT 1) DOCUMENTING THE SOLUTION a: PREVENT RECURRENCE OF THE PROBLEM
Summarize the process learned. The objective of this sub-step is to document all the solutions carried out to comply with WCAG recommendations on the websites. This stage will allow to solve similar accessibility problems and prevent them.

b: CONCLUSIONS
In this step, the accessibility compliance of the analyzed website is determined. In addition, if in the final results some accessibility problems persist and/or there are new ones that are not included in the action plan, phases I, II, III, and IV have to be repeated.

V. CASE STUDY
The purpose of this case study is to apply the proposed process model to an actual website to show the feasibility of our proposal. For this purpose, an accessibility study of the Human-Computer Interaction (HCI) website (https://hci.ucacue.edu.ec/) of the Catholic University of Cuenca (Ecuador), which publishes research results content, was carried out. The HCI web portal is developed in WordPress and uses a standard template for all its content. The process model for continuous testing of web accessibility can have an unlimited number of iterations, but in this case study, we only show one iteration of the process.

A. PHASE I -PLAN 1) DEFINE THE PROJECT a: DEFINE THE PROBLEM
The United Nations [43] in its Sustainable Development Goals (SDG) seeks the educational inclusion of people with disabilities on equal terms. Therefore, web accessibility contributes to the achievement of SDG 4 (''Ensure inclusive and equitable quality education and promote lifelong learning opportunities for all'') of the United Nations 2030 Agenda.
In Ecuador, according to statistics published by the National Council for the Equality of Disabilities with data from the Ministry of Public Health [44], there are 481,392 people with disabilities. In addition, there are 5,917 people with disabilities studying at Ecuador's universities and polytechnics schools. Ecuador's Higher Education Law [45] establishes that universities must implement universal accessibility requirements to promote access to higher education for people with disabilities.
SARS-COV2 has led public and private institutions to deliver most of their classes through online education. However, the lack of knowledge or interest of information technology professionals in the development of accessible software has meant that a large number of people with disabilities are unable to interact with the educational websites [46]. Therefore, this case study has two objectives: • Determine the level of accessibility of the HCI web portal with the WCAG 2.0 and a conformance level AA, as established by the Ecuadorian Technical Regulation in its second transitory.
• Determine the level of accessibility of the HCI web portal with the WCAG 2.1 and a conformance level AA.

b: ANALYZE THE IMPORTANCE OF THE PROBLEM
The United Nations in the Convention on the Rights of Persons with Disabilities (CRPD) defines access to information and communication, including the Web, as a fundamental human right [47]. In Article 21 -Freedom of expression and opinion, and access to information, it is stated that governments should urge ''private entities that provide services to the general public, including through the Internet, to provide information and services in accessible and usable formats for persons with disabilities'' [47].

c: DEFINE CONTROL INDICATORS
Ecuador, like other countries, in 2014 [48] adopted the recommendations of the WCAG 2.0 of the W3C. In addition, to control its compliance, the Ecuadorian technical regulation RTE INEN 288 ''accessibility to web content'' was created [49]. This regulation applies to the web content published on public and private sector websites that provide public services.  These websites must fully comply with a conformance level AA established in the NTE INEN-ISO/IEC 40500 standard. Considering that WCAG 2.1 includes WCAG 2.0 in its totality, this means that if a website complies with WCAG 2.1, it also complies with WCAG 2.0. In addition, the new versions of WCAG extend the success criteria of the previous versions. For this reason, we consider in our case study the success criteria of WCAG 2.1 as control indicators [22]. The accessibility problems found in the HCI web portal success criteria after the evaluation will be our KPIs.
Evaluating accessibility with automatic tools of the HCI web portal will allow us to find the accessibility problems by success criteria. These will be written as KPIs for the accessibility compliance of the web portal.

2) ANALYZE THE CURRENT SITUATION
The purpose of this stage is to analyze the current situation of the websites. For this purpose, the WCAG-EM methodology must be applied, which will result in a report of the findings of the analyzed websites. This report will make it possible to know the level of accessibility of the websites and to determine the accessibility problems for each success criterion to analyze their potential causes then. The WCAG-EM methodology has five steps and 20 sub-steps, of which five are optional. This methodology guides the evaluation of the accessibility of a complete website in a reliable way. Figure 9 shows the WCAG-EM methodology map with each of its steps and sub-steps.

a: DEFINE THE EVALUATION SCOPE
The target website for this evaluation is the HCI web portal (https://hci.ucacue.edu.ec/) of the Catholic University of Cuenca (Ecuador), using WCAG 2.1 with a conformance level A and AA.

b: EXPLORE THE TARGET WEBSITE
This step investigates HCI portal websites to overview their use, purpose, and functionality, as recommended in the WCAG-EM methodology. However, according to Velleman and Abou-Zahra, the results obtained in this step are usually refined in stages ''c: Select a representative sample and d: Audit the selected sample'' as the evaluator learns more about the target website [10]. The list of relevant pages selected in this research is the home page, sitemap, contact, general site information (pages with forms, tables, images, links, and so on). The functionalities found were access links to publications of research project results and software prototype download sites.

c: SELECT A REPRESENTATIVE SAMPLE
In this research, selected all web pages of the HCI portal. A total of 16 web pages were found. Before starting the evaluation, verified the validity of the URLs of the websites. The ID, title, and URL of the web pages are presented in Table 2.

d: AUDIT THE SELECTED SAMPLE
Many tools can help web developers make their website content more accessible [50]. In a very interesting comparative report [51] made on the results of the audit of automatic accessibility tools, the five tools that detected the highest number of accessibility errors are: SortSite (40 %), Tenon (34 %), AChecker (31 %), WAVE (30 %) and Axe (29 %). However, Sorsite, Tenon, and WAVE are paid, AChecker has disappeared, so we chose Axe as the best free option available at the moment of our analysis.  The accessibility evaluation of the HCI portal websites was performed with the pa11y 1 tool that includes two web accessibility analyzers: Axe 2 and HTMLCS. 3 Axe's evaluation results revealed 360 accessibility errors, 40 warnings, and zero notices on the 16 web pages analyzed. In addition, the evaluation of the HCI portal websites with HTMLCS allowed checking whether the HTML code meets the WCAG 2.1 success criteria. The results of the HTMLCS evaluation revealed 152 accessibility errors, 584 warnings, and 1,722 notices on the analyzed website. The results of the evaluation with Axe and HTMLCS are shown in Table 3.

e: REPORT THE EVALUATION FINDINGS
The evaluation report was extracted from the JavaScript Object Notation (JSON) format documents generated by pa11y from each evaluated website. The results determined that all the websites present a standard error in the success criterion ''1. 4   programmatically determined name (Accessibility problems. The heading structure is not logically nested. This h4 element should be an h2 to be properly nested)''. In the websites, found the highest number of noncompliance in the sufficient techniques. The results of the sufficient techniques found in the evaluated websites are available in our dataset in the IEEE DataPort 5 by success criteria.

b: ANALYZE COLLECTED DATA
In this step, the success criteria containing accessibility problems were classified by conformance levels A and AA. Considering that to comply with conformance level AA, we must first comply with conformance level A. Of the 32 success criteria with accessibility problems encountered, 16

4) PLANNING SOLUTIONS a: ELABORATE LIST OF SOLUTIONS
The solution plan allows developers to guide and verify compliance with each success criterion with its compliance levels. In the HCI web portal, found 32 accessibility problems in the WCAG 2.1 success criteria. It should emphasize that the errors, warnings, and notices detected with the Axe and HTMLCS evaluation tools are considered accessibility problems. For this, we determined a KPI for each success criterion for compliance. The solution plan by success criteria, problem causes, KPIs, and priority for the HCI web portal is available in our IEEE DataPort.

b: IDENTIFY PRIORITIES
Priorities are defined according to conformance levels A and AA. Success criteria with conformance level A are classified as priority 3 (red color), and success criteria with conformance level AA are classified as priority 2 (yellow color). The KPIs according to their priorities are available in our IEEE DataPort.

c: ELABORATE ACTION PLAN
In the action plan based on the KPIs (What?), determined the links for the understanding of the success criteria (techniques and failures) (How?). Then, determined the person responsible (Who?) for correcting accessibility problems for each success criterion (HCI web portal responsible). Also, the start and end dates (When?) for the fulfillment of each of the KPIs and the necessary resources (human and technological) (With what?) were defined. Table 4 shows the action plan for its implementation. This research is justified (Why?) in the first and second transitory of the Ecuadorian technical regulation RTE INEN 288 ''accessibility to web content''. In addition, making the web accessible benefits individuals, businesses, and society [2].

B. PHASE II -DO 1) IMPLEMENT SOLUTIONS a: EXECUTE ACTION PLAN
The HCI web portal is developed using the WordPress Eimear theme. This theme incorporates accessibility, thus enabling the development of more inclusive websites. Also, it has a built-in Accessibility Helper Sidebar for the navigation of people with disabilities. However, 32 accessibility problems have been found in the HCI web portal. For this reason, the action plan has been implementation, which has been carried out from June 1 to June 29, 2021. The correction of accessibility problems was carried out using the process for executing the KPIs of the action plan shown in Figure 8. First, we understood the techniques and failures of the WCAG 2.1 success criteria with accessibility problems. Then, considering the examples, we adjusted the HTML code of images, tables, contrast problems, and so on. In addition, websites were evaluated in parallel with automated online accessibility assessment tools as corrected issues. Also, at the end of the first iteration, the percentage of KPIs that had been resolved and the percentage of KPIs pending resolution were analyzed.   The four most common mistakes found that have been solved from the KPIs are the following: 1) In all images on the HCI web portal, an alternative text was put in the alt attributes. 2) All pages of the HCI web portal were checked for headings. For example, Heading <h1> should be used for main titles, followed by headings <h2>, then less essential headings <h3>, and so on. According to the results obtained from the execution of the action plan using the continuous testing process model in its first iteration, it could be seen that there are still accessibility problems. These are presented below by success criteria and conformance level: 1) 1.

VI. DISCUSSION
The W3C has created the WCAG-EM methodology for web accessibility evaluation. However, the results of some studies [53]- [56] in which this methodology is applied detail the accessibility problems encountered, statistical analysis, and possible solutions for the websites analyzed or a combination of these.
On the other hand, the SARS-CoV-2 pandemic has forced organizations to adapt to new business conditions by digitally transforming many processes [57]. This transformation is here to stay in organizations. Organizations have had to evolve and benefit from the expansion of the Internet and next-generation technology devices. With the increase of digital platforms, it has become imperative that web resources be fully accessible to people with disabilities [58]. Therefore, this article presents a process model for evaluating the accessibility of websites using the WCAG. It is a process model that allows any organization or entity to implement accessibility in their websites regardless of their dedication to reach a broader audience on the Web.
The process model for continuous web accessibility testing aims to constantly evaluate websites using the phases of the Deming cycle and TQM. This process model provides feedback and self-feeding from each of its iterations. Each iteration solves accessibility problems and redefines existing and new issues that are solved in a new iteration. In addition, it documents lessons learned from web accessibility problems.
The process model for continuous testing of web accessibility was corroborated for its applicability and functionality through a case study. The process model proposed after applying the case study on the HCI web portal made it possible to describe the steps to be carried out in each of its phases. This process model is composed of four phases. The first phase of the process model is the planning of the web accessibility evaluation. It contains four steps that are described below: 1) The first step of the planning allows us to define the accessibility problem you have in your web portals, its importance, and the version of the WCAG with which we want to evaluate it. 2) The second step allows to determine the current status of the websites. For this purpose, must apply each of the steps of the WCAG-EM methodology. This methodology will allow finding the accessibility problems in the analyzed websites. In the accessibility report, which is the last step of the WCAG-EM methodology, it is essential to define the accessibility problems found by principles, guidelines, and success criteria.
3) The third step allows determining the potential causes of accessibility found in the WCAG success criteria.
For this purpose, sufficient techniques, advisory techniques, and failures of the success criteria that have accessibility problems in the analyzed websites must be identified. The success criteria should then be classified by principles, guidelines, and levels of conformance. 4) The fourth step allows to elaborate the plan of solutions to the accessibility problems encountered on the websites. For this purpose, KPIs are formulated by success criteria based on the accessibility problems encountered. Also, the success criteria are prioritized according to the conformance levels A, AA, and AA. They are taking into account that the success criteria that have the most significant criticality and impact on the websites are those of a conformance level A. Finally, in this step, the action plan is drawn up, which must contain the KPIs, the links for understanding the success criteria (techniques and failures), the person responsible, the start and end date, and the human, financial and technological resources necessary for the fulfillment of each KPI. In addition, the rationale has motivated organizations to comply with web accessibility standards in their web portals. The second phase of the process model is to implement the action plan. It contains only one step, which is described below: 1) The execution of the action plan is aimed at meeting the KPIs. It is essential to understand the success criteria (techniques and failures) and take into account their examples to correct accessibility problems. Generally, a web portal uses a template that is reused for the design of each of its web pages. If this is the case when correcting an error on one web page, it must be fixed in the same way on the others. A good practice is the continuous testing of websites after changes have been made to check if the accessibility problem has been solved. Testing can be done with automatic evaluation tools, experts, end-users, assistive tools, among others. This helps to verify that the changes made are correct. The third phase of the process model consists of measuring the results. This contains only one step, which is described below: 1) Measuring results consists of determining the KPIs that have not been met. In addition, explain the reasons for non-compliance, including human, economic, technological, and others. The fourth phase of the process model consists of documenting the solutions. This phase contains only one step, which is described below: 1) Documentation of the solutions will allow similar accessibility problems to be corrected in future websites. In addition, the lessons learned in the previous phases will enable developers to make fewer accessibility errors in new website designs. The objective of this process model is for organizations to continuously test the accessibility of their websites to make them more accessible. The phases and stages of the proposed process model should be applied sequentially, as the results of one step are the basis for the next. In addition, using this process model on websites will avoid legal problems due to non-compliance with web accessibility regulations and violation of the rights of people with disabilities on the Web.

VII. LIMITATIONS OF THE STUDY
A limitation of this study is that the process model for continuous testing of web accessibility has only been applied to the case study of the HCI web portal. Therefore, this process model should be tested in different website scenarios to have a broader scope of the evaluation.
Another limitation is that the websites evaluated in the case study have not been tested with end-users. For a complete accessibility evaluation of the HCI web portal, it is necessary to check with end-users and experts.
Another limitation is evaluating the HCI web portal with two automatic tools (Axe and HTMLCS). The results of more evaluation tools could also be incorporated into the tests.

VIII. CONCLUSION AND FUTURE WORK
This research's objective was to create a process model for the continuous testing of accessibility in websites and its validation. The main results of this research are the creation and application of the process model for continuous testing of web accessibility in a case study. This process model is the adaptation of the Deming cycle, the WCAG-EM methodology, and TQM. The Deming cycle allows the organization the activities in each of its phases. The WCAG-EM methodology determines the current situation of the websites and their problems, and the TQM contemplates all the activities that must carry out until reaching the conclusions. The purpose of this process model is to meet accessibility standards on websites over time through continuous testing. In addition, this model is flexible to new versions of the WCAG. Also, it allows the accessibility of websites to be evaluated with automatic evaluation tools, end-users, experts, etc. In the same way, it allows to continuously evaluate, monitor, and provide feedback on compliance with accessibility rules, policies, and standards on websites.
After the development of the process model, verified its feasibility utilizing a case study. The case study was conducted on the HCI web portal, evaluated with the automatic evaluation tools Axe and HTMLCS, finding 32 accessibility problems in the WCAG 2.1 success criteria with conformance levels A and AA. These accessibility problems were considered KPIs to be solved in the Solution Plan and Action Plan. Considering the accessibility problems, we understood the techniques and failures of the success criteria and their examples, which solved the issues in the HTML and CSS code of the HCI web portal. The results showed that out of the 32 KPIs, solved 24 in the first iteration of the process model. These results corroborated the viability of the process model, as it improved the accessibility of the HCI web portal by 75 %. This verification was done by re-evaluating the HCI web portal with the same automatic evaluation tools applied at the beginning.
The implementation of accessibility in websites will make the services or products offered by organizations reach a more significant number of users. For this, programmers or website developers must work more closely with the WCAG to improve accessibility and usability [26]. This can be achieved by using the process model for continuous testing of web accessibility, which guides step by step and sequentially what is being done in each of its phases. This sequence links regulations, resources, and information. In addition, this process model can have an infinite cycle of iterations to keep websites accessible through continuous accessibility testing.
As future work, we plan to adapt the process model to different working groups according to their components and groups of people. In addition, as another future work we plan to adapt the proposed method for the development of accessible mobile applications. Also, as another future work we plan to create a process model for web accessibility compliance in electronic documents before their publication on the web.