Generating Accessible Webpages from Models

Abstract

Despite significant efforts to promote web accessibility through the adoption of various standards and tools, the web remains inaccessible to many users. One of the main barriers is the limited knowledge of accessibility issues among website designers. This gap in expertise results in the development of websites that fail to meet accessibility standards, hindering access for people with diverse abilities and needs. In response to this challenge, this paper presents the ACG WebAcc prototype, which enables the automatic generation of accessible HTML code using a model-driven development (MDD) approach. The tool takes as input a Unified Modeling Language (UML) model, with a specific profile, and incorporates predefined Object Constraint Language (OCL) rules to ensure compliance with accessibility guidelines. By automating this process, ACG WebAcc reduces the need for extensive knowledge of accessibility standards, making it easier for designers to create accessible websites.

1. Introduction

The World Wide Web Consortium (W3C) has transformed the way we access various essential services, such as education, health, commerce, banking, and remote work, facilitating multiple activities in today’s society and providing people with disabilities with greater autonomy to conduct online transactions, improving their quality of life, and strengthening sustainability [1]. However, despite the fundamental principles of the web, such as universality and accessibility, many people, especially those with disabilities, still face significant barriers due to personal limitations or inaccessible digital environments. Ensuring digital accessibility is crucial to achieving the United Nations Sustainable Development Goals (SDGs), particularly those related to quality education (SDG 4), reducing inequalities (SDG 10), and promoting sustainable cities and communities (SDG 11). In this regard, the Web Content Accessibility Guidelines (WCAG) [2], developed by the W3C, provide a structured framework to ensure that web content is perceptible, operable, understandable, and robust, thus promoting inclusion and strengthening social and economic sustainability.

Since 1999, the Web Accessibility Initiative [2], a branch of the W3C, has been working to create recommendations and standards that ensure web accessibility. This includes the Web Content Accessibility Guidelines [2], with its latest version 2.2 published in 2022 as an official recommendation. As a result of this initiative, various technological tools have been developed to validate the accessibility criteria [3]. However, since these tools alone are insufficient, manual evaluation remains essential to ensure that a website is fully accessible. In addition, it is highly recommended that users with different types of disabilities participate in this process, or if this is not possible, disability simulators should be used, for example, to simulate different types of color blindness, and that access to the website is gained with the assistive technologies used by people with disabilities, such as a screen reader used by blind people.

Accessibility refers to the characteristics that allow an environment, product, or service to be used comfortably, safely, and equitably by all individuals, particularly those with disabilities [2]. This concept applies across various contexts, including educational institutions, urban environments, information systems, and transportation and tourism services. In the web domain, accessibility analysis aims to evaluate and validate sites to ensure compliance with the established guidelines. While automated tools enable quick assessments, they do not always yield complete results, as they may overlook certain errors or generate false positives, necessitating complementary manual evaluations [4].

Accessibility is often compromised because it is not prioritized within the software development cycle; it is frequently validated only at the end of the process [3]. This oversight implies that the diverse functional needs of potential users are not considered during the design stage. Therefore, it is crucial to adopt effective approaches that facilitate the integration of accessibility standards and promote awareness among website designers. By doing so, accessibility can become a priority quality attribute during the early stages of development. A study by [5] indicated that one of the main reasons inaccessible websites persist is the lack of knowledge and experience among website designers regarding these standards.

For many website designers, ensuring accessibility is a fundamental yet time-consuming task, particularly because it is not considered as a core quality requirement in many contemporary projects, especially by smaller teams, in smaller companies, and in less developed countries. To mitigate these risks and ensure that accessibility principles are correctly applied from the outset, tools such as Source Code Generators are employed [6]. These tools enable automatic code generation in situations where the logic is repetitive, optimizing productivity and facilitating the consistent integration of accessibility components. With these code generation tools, website designers can incorporate accessibility standards more efficiently, ensuring that the final products are inclusive and accessible to all users.

Automatic code generation, using approaches such as model-driven architecture (MDA) and model-driven development (MDD), has been proven to be effective across various domains. For instance, the proposal in [7] applied MDA to automate the creation of educational applications, whereas Ref. [8] used MDD to implement security mechanisms in critical systems. Both studies highlight the efficiency of these methods in automatically generating code and optimizing the development of complex applications, thereby improving accessibility and reducing errors.

According to a systematic review by [9], several studies have agreed that the MDD approach is beneficial for creating accessible software. This approach allows for the integration of accessibility during the early stages of the software lifecycle, enabling a focus on designing business logic, without excessive concern for underlying frameworks or programming languages. In addition, the automatic transformation of models into different programming languages reduces the need to focus on implementation details to ensure accessibility.

Furthermore, Ref. [10] emphasized the importance of including both functional and non-functional software requirements during the initial phases of development for the automatic generation of code from Unified Modeling Language (UML) models. In the realm of mobile applications, Ref. [11] used MDD to automatically generate cross-platform graphical interfaces. These studies demonstrate that while MDA and MDD are promising solutions for enhancing productivity, they also present challenges, such as in regard to customization and the efficient integration of all the software requirements into the model.

Despite the significant benefits of model-based development, such as time optimization and the reduction in manual errors, limitations can also arise. The proposal in [12] points out that errors in automatic transformations can lead to defective or non-functional code, which will affect the quality of the final product. These issues may stem from incorrect interpretations of models or limitations in transformation tools. Therefore, it is essential not only to correct errors in the initial models, but also to involve programming language experts to conduct thorough testing of the generated code. This ensures that the functionality of the resulting code meets the established requirements and helps to avoid critical failures in the later stages of development. In addition, this approach allows website designers to identify areas where automated tools may fail and adjust the transformation processes to minimize errors.

Among the challenges faced by companies adopting MDD are the selection of appropriate tools and the training of staff on accessibility [9]. Ref. [13] emphasized that, in addition to choosing the right method, it is crucial to train website designers in regard to testing and ensuring compliance with standards, such as ISO/IEC 25010 [14]. Sometimes, the automatically generated code is not optimal, requiring modifications to meet the quality and accessibility requirements, as noted by [15,16]. While this may increase costs and workloads, it is essential to ensure that the final software is accessible and complies with the legal regulations in many countries.

Furthermore, Ref. [10] highlighted that greater effort is required during the model architecture construction phase. On the other hand, Ref. [17] emphasizes the need to separate generated code from non-generated code, meaning the code that the programmer will later include, as this lack of separation can complicate future maintenance. Ref. [18] also mentioned that using models can increase the number of artifacts, along with their relationships and dependencies, which adds to the complexity of the development.

Given this reality, and to address the identified problems, the objective of this research is to develop an automatic code generator for accessible webpages, based on the WCAG 2.2 standard and UML models. In this context, the research focuses on the following question: How can web accessibility features be efficiently integrated from the beginning of the software development cycle to optimize the automatic generation of accessible HTML code?

This proposal aims to improve the process of creating accessible webpages by incorporating accessibility criteria from the early stages of the design process to final implementation, following an MDD approach and ensuring that the generated HTML code complies with the WCAG 2.2 standards defined in the profile. Research on web accessibility, especially in regard to a model-driven development approach, is crucial given the challenges website designers face when creating accessible web applications and the critical importance of accessibility in ensuring that websites can be easily and quickly accessed by people with various types of disabilities.

For the construction of the ACG WebAcc software, follow a structural process that comprises the following steps: (1) defining the accessible UML profile, (2) UML modeling, (3) generating accessible HTML code, and (4) accessibility validation and testing.

Throughout this document, the sections are structured as follows: Section 2 presents the fundamental concepts of web accessibility, model-driven development (MDD), the UML profile, and also provides an analysis of related work. Section 3 describes the materials and methods, detailing the construction phases of the proposal and the tools used, while Section 4 presents the development of the ACG WebAcc software. Section 5 presents the results obtained, followed by a discussion in Section 6. Section 7 deals with the limitations and future work. Finally, Section 8 compiles the main conclusions and findings from the study.

2. Background

2.1. Web Accessibility and the WCAG 2.2

Since its inception, the web has been designed following the principles of universality and accessibility, as emphasized by its creator, Tim Berners-Lee, guaranteeing access to all users, regardless of their personal abilities or the technology they use to browse the web.

As noted by [19], functionality is synonymous with usability; therefore, accessibility also seeks to preserve and enhance the functionality of a system. Essentially, accessibility is the concept of designing user interfaces that are equally usable by all people, allowing for barrier-free interactions, regardless of their abilities.

Furthermore, compliance with these guidelines often improves the usability of web content for all users, which can lead to increased site traffic and, consequently, boost a company’s revenue, as users can interact with the content more easily and efficiently [20].

Today, there are various guidelines, standards, and regulations for assessing the accessibility level of websites. Among the most widely adopted are the Web Content Accessibility Guidelines (WCAG), which offer a comprehensive set of recommendations aimed at making web content more accessible.

When a website complies with the WCAG standards, it becomes accessible to a wider audience, including people with disabilities such as blindness, low vision, deafness, hearing loss, learning disabilities, cognitive limitations, reduced mobility, speech difficulties, photosensitivity, or combinations of these conditions [2].

WCAG 2.2 consists of 4 principles, 13 guidelines, 73 conformance criteria, and 3 levels of accessibility. These three accessibility levels are: A, which includes 30 criteria; AA, with 23 criteria; and AAA, with 20 criteria [2]. The 13 guidelines are organized around the 4 principles: perceivable, operable, understandable, and robust. These principles are further developed into guidelines, conformance criteria, and specific techniques to ensure web accessibility.

The perceivable principle states that information and interface components must be presented in a way that is accessible to all users. The operable principle indicates that interface elements and navigation must be functional and easy to use. The understandable principle ensures that both the information and potential interactions with the interface are clear and comprehensible. Finally, the robust principle requires that the content is sufficiently solid to be interpreted by a wide range of applications and technologies.

2.2. Model-Driven Development

MDD involves the creation of conceptual models of the software to be produced and the transformation of these models into more detailed ones that can be converted into code [21]. According to this definition, programmers can indeed be considered model-driven developers, as when they write a program in a language like Java, they do not expect it to execute directly, rather they expect it to be converted into the language of a virtual machine that can run the model [16].

The model-driven software development paradigm has gained attention from the software engineering community because it elevates software development to a higher level of abstraction, reducing the complexity and amount of documentation required in software projects through the creation of metamodels. This approach also allows for the consideration of various accessibility features from the WCAG [16].

The primary purpose of MDD is to minimize the costs and time associated with software application development, aided by various supporting tools, in the pursuit of improving application quality by separating the architectural design aspect. MDD ensures portability, interoperability across different platforms, and increased productivity [22].

2.3. UML Profiling

UML [23] is a general-purpose graphical language for software systems, supported by the Object Management Group (OMG), which enables the visualization, specification, construction, and documentation of a system. UML provides great flexibility and expressiveness when modeling systems; however, there are times when it is necessary to model and represent concepts from specific domains. In these cases, UML profiles [24] have been used to extend the syntax and semantics of the UML to model elements from other specific domains. One of the main objectives that profiles must fulfill is the inclusion of new features in UML models.

When designing webpages, a UML profile can be used as a key technique for extending the UML using stereotypes to model specific components of webpages, such as <<WebPage>>, <<NavigationClass>>, <<Menu>>, <<Form>>, <<Table>>, etc. [25].

In our proposal, the UML profile called WebAcc profile [26] is used as the foundation. This profile employs the OCL to specify rules attached to the defined stereotypes, aiming to ensure compliance with the web accessibility criteria outlined in WCAG 2.2.

2.4. Automatic Code Generation

An automatic code generator is a tool that produces the source code of an application from certain artifacts [6]. By generating code from specifications, models, or templates, it not only accelerates the development process, but also improves the quality of the final code by minimizing manual interventions [12]. UML based code generators can produce consistent code using standard programming practices; this code is generally more secure and easier to maintain than manually created code [27]. Code generators use class diagrams as the starting point to generate the basic structure of the code. The automatic translation of UML diagrams into object-oriented code is very convenient, thereby eliminating the possibility of human errors. Following a model-driven architecture (MDA) approach, the proposal in [28] uses the proprietary xGenerator tool for the automatic generation of Java code from UML models. The generated code is organized according to a variant of the Model View Controller (MVC) architectural pattern, thus facilitating the structured and efficient development of web applications.

2.5. Related Work

The automatic generation of HTML code and other programming languages has been studied through the use of various methods, particularly those based on MDA and MDD. These approaches have proved effective in optimizing application development from high-level models applicable across different domains.

Sebastián et al. [7] proposed a comprehensive model-driven architecture (MDA) approach for the automatic generation of HTML and JavaScript code in regard to language learning applications. By utilizing transformation languages, such as the Atlas Transformation Language (ATL) and Acceleo, they implemented a methodology that spans from the Computation Independent Model (CIM) to the Implementation Specific Model (ISM). The proposal has been validated through the modeling and complete automatic generation of source code for two Learning Activity Mechanisms (LAMs), which are used within methodologies such as Duolingo and Busuu, namely LAM Image–Audio–Text and LAM Audio–Text Options.

Herrera-Izquierdo et al. [29] proposed a generator that allows for the automatic creation of web applications and user interfaces with responsive functionality, using the Python language. However, this software does not accept UML models; instead, users must select the elements that they wish to include in the application, such as tables and methods.

Additionally, Ref. [10] discussed the challenges related to the automatic generation of code from UML diagrams, focusing their analysis on the limitations presented by these tools. While they acknowledge that MDA and UML-based approaches facilitate automation, they stress the importance of understanding the barriers that may arise when automatically generating quality code in complex environments.

In the domain of critical systems, Ref. [8] presented an approach for the automatic generation of security mechanisms applicable to safety critical systems. This MDD approach uses the UML to represent and transform security models, ensuring the automated implementation of these mechanisms into both software and hardware. This study underscores the importance of automatic code generation in systems where security requirements are stringent and must be implemented without human error.

The proposal by [30], called AccessMDD, focuses on creating mobile applications using MDD that natively incorporate accessibility features for users with visual disabilities, such as those who are blind or have low vision. This approach allows developers to generate accessible applications more efficiently by integrating the necessary guidelines into the model to ensure usability and accessibility from the outset.

Sabraoui et al. [11] used the MDD approach to develop mobile applications. In their proposal, they developed a Domain Specific Language (DSL) for the automatic generation of graphical user interfaces (GUIs) for multiple mobile platforms, such as Android. This approach enabled developers to automatically generate native code, demonstrating the flexibility of MDD in mobile environments, wherein the diversity of platforms complicates manual development.

The thesis by [31], developed at the University of Twente, presented a modeling approach for developing geospatial web applications based on Representational State Transfer (REST), using UML profiles. The work explored how models can guide the creation of efficient and scalable web services, while effectively integrating geographic data. Additionally, it discussed the advantages of using adapted UML profiles to accurately model the characteristics and requirements of these applications, thereby improving the development process and the quality of the final product. Although the approach was promising for enhancing software product quality through the use of profiles, it did not demonstrate the incorporation of accessibility features into the model.

Finally, Ref. [32] addressed the generation of behaviors for multi-agent systems in robotics, using MDD. Their research focused on robotic soccer and applied platform-independent models to create complex robot behaviors, automating the generation of platform-specific code. This approach demonstrated the viability of MDD for generating behaviors in dynamic and distributed scenarios, such as during robotic soccer simulations.

These studies demonstrate that the automatic generation of code, whether in HTML or in other programming languages and for different platforms, was successfully applied across various domains. MDA and MDD approaches are particularly promising for automating development processes, reducing errors, and increasing productivity, although they also face challenges, such as the need for customization and concerning the efficient integration of models.

The contribution of this study lies in the fact that it concerns the initial use of a profile that also incorporates accessibility features. This allows for the validation of the accessibility criteria defined in the profile from the outset, when creating the UML model. We also develop a code generation tool that takes the UML model as input and performs the necessary transformations to generate an accessible webpage.

3. Materials and Methods

In this study, an MDD approach was used to create the automatic ACG WebAcc code generator, developed in the Python programming language. This generator receives as input, a UML class diagram, based on the WebAcc profile [26] and, from it, generates the code of an accessible webpage in HTML. For the development of the ACG WebAcc generator, the experimental scientific method was applied, which implies an ordered sequence of actions. This approach is based on the analysis of 12 success criteria in the WCAG 2.2, whose indicators are related to various elements of a webpage, such as images, videos, audio, menus, links, definition lists, headings, paragraphs, content sections, forms, and tables.

The main objective of this research is to develop an automatic code generator for accessible webpages, based on the WCAG 2.2 standard and UML models. In this context, the research focuses on the following question: How can web accessibility features be effectively integrated from the beginning of the software development lifecycle to optimize the automatic generation of accessible HTML code? This proposal seeks to improve the process of creating accessible webpages by incorporating accessibility criteria during the early stages of the design process, following an MDD approach and ensuring that the generated HTML code complies with the WCAG 2.2 standards defined in the profile, in order to provide an inclusive experience for all users.

3.1. Process

To achieve the defined objective, a process composed of four stages that follows the MDD approach has been designed. This process involves: 1. the definition of the UML profile with accessibility requirements; 2. UML modeling; 3. the generation of accessible HTML code; and 4. validation and accessibility testing. The stages are detailed in Figure 1.

The process of this proposal begins with the definition of a UML profile that incorporates key accessibility elements, aligned with the WCAG 2.2, covering: 1.1 text alternatives, 1.2 time-based media, 1.3 adaptable, 2.4 navigable, 3.1 legible, and 4.1 compatible. These guidelines apply to various components, such as images, videos, audio, navigation menus, links, definition lists, headings, paragraphs, tables, and forms. The selection of these requirements is based on several principles, among which is the need to prioritize the A and AA level criteria, given that the AAA level criteria, although important, are not mandatory according to the legislation in many countries. In addition, this approach ensures that the selected criteria are easily integrated into the profile for automated review, following the techniques set out in the WCAG 2.2. The criteria corresponding to the key accessibility principles are also included, namely perceivable (P), operable (O), understandable (U), and robust (R), ensuring that the web design meets the accessibility standards during the modeling stage.

The second step is the design of the UML model using the defined profile. This model includes elements such as classes and relationships, and applies the stereotypes and restrictions of the WebAcc profile to these elements. It is crucial that the UML model reflects the accessibility features specified in the profile. For example, values are set for attributes related to textual alternatives, including titles and summaries in tables, URLs of video transcripts, and associations between text controls and labels in forms.

The third step consists of converting the UML elements into HTML. During this phase, the ACG WebAcc generator is used to create the HTML code from the UML model. It is crucial that the generated HTML meets the accessibility criteria defined in the profile to ensure that the final product is accessible. The transformer takes into account the stereotypes and restrictions related to accessibility during the generation of HTML, thus ensuring that the accessibility requirements established in the profile are properly integrated.

Finally, the last step is to use accessibility validation tools to ensure that the HTML complies with the selected guidelines from the WCAG 2.2. This process involves the use of automated assessment tools, such as Tingtun Checker.

3.2. MDD Support Programming Tools and Languages

Several tools and support languages can be considered for the automatic generation of accessible HTML code, based on a UML profile, in the context of MDD.

Papyrus 6.7.0 [33], a tool for the graphical modeling of UML applications, is an open-source project designed to be a component of Eclipse Modeling Tools and is based on the EMF UML2 metamodel. It can be used as a standalone tool or as an Eclipse add-on. Papyrus provides support for DSL. In addition, it is designed to be easily extensible, because it is based on the principle of UML profiles. UML profiles serve as a mechanism provided by the UML itself to extend its syntax and semantics to express concepts specific to a given application domain. Its advantages include extensive support for the UML and profile customization. It is also able to be integrated with other Eclipse components. It also offers support for UML profiling. Papyrus allows the user to work with the UML, which allows the user to create, edit, and view UML models.

The UML [23] is a graphical language that provides a set of notations and diagrams to model various aspects of a system. It facilitates communication between developers, analysts, and other stakeholders by offering a standard and clear representation of the system. In addition, the UML serves as a form of technical documentation, helping developers and other stakeholders understand the system in-depth. In our proposal, we use the UML to develop a profile based on the guidelines in the WCAG 2.2. This profile is applied during the creation of a UML model that incorporates the defined accessibility requirements.

The OCL [34] is a formal language integrated into the UML to specify constraints and conditions that software models must meet. Its main function is to provide an accurate description of the rules and constraints that cannot be directly expressed in UML diagrams. In regard to the proposed profile, the OCL rules are defined that specify the accessibility features in accordance with the WCAG 2.2.

HTML [35] is the standard language used to create and structure web pages. Using tags, HTML defines elements such as text, images, links, lists, tables, forms, and other components that make up a website’s content. HTML5, is the latest version, introduces important improvements in regard to semantics and accessibility, facilitating the creation of web content that is accessible and well structured. In our proposal, a HTML 5 code generator accessible in regard to the UML model is created.

Python [36] is a high-level, interpreted, general-purpose programming language, recognized for its simplicity, readability, and flexibility. Its clear and concise syntax facilitates the writing and understanding of the code. Python applies cross-platform, allowing the same code to run on different operating systems without requiring modifications. In our proposal, Python is used as a programming language to automate the process. By using Python libraries, it is possible to process UML models, apply transformations, and generate accessible and well-structured HTML content.

Tingtun Checker [37] is a tool used to evaluate the accessibility of websites, helping to identify problems that may affect users who have some type of disability. It provides reports on compliance with the WCAG criteria. In this article, we will present evidence using Tingtun Checker on the following webpages: https://kfordonez.github.io/AccPage/ (accessed on 10 February 2025), https://kfordonez.github.io/TableAccPage/ (accessed on 10 February 2025), and https://kfordonez.github.io/FormAccPage/ (accessed on 10 February 2025).

The Tingtun Checker tool evaluates website accessibility against the Web Content Accessibility Guidelines (WCAG) and other international standards. It performs a thorough analysis of certain aspects, such as color contrast, the use of alternative text in images, the structure of headings, and the accessibility of forms, videos, and tables, verifying that these elements are understandable for users with disabilities. In addition, it examines the navigability of the site via a keyboard and its compatibility with assistive technologies, reviewing the semantic structure of the HTML and the proper use of ARIA roles.

3.3. ACG WebAcc Prototype

The ACG WebAcc prototype focuses on evaluating the accessibility criteria defined in the WCAG 2.2 that have been selected previously and are illustrated in Figure 2. Firstly, it is essential that the system complies with criterion 1.1.1, which requires that any non-textual content has an appropriate textual alternative. This means that the software must identify image-type components and generate understandable text descriptions for visually impaired users.

In addition, criterion 2.4.2, which requires a descriptive title for each page, indicates that the software extracts and assigns titles to the generated pages, thus facilitating navigation and identification of the content. Similarly, criterion 3.1.1, which establishes the need to specify the language of the page, suggests that the system should include this information in the generated HTML code, allowing assistive technologies to interpret it correctly.

Criterion 1.3.1 highlights the importance of the clear and structured presentation of content, especially in forms and tables. Therefore, the software ensures that the organization of the information is logical and accessible. Criterion 2.4.6 promotes the use of appropriate headers, which requires the transformer to implement a clear hierarchy in the HTML, with the use of tags, such as <header> <nav> <main> and <footer>, improving the understanding and navigation of the content.

Criteria 2.4.4 and 1.3.1 are also important as they require links to be clear and the data structure to be accessible. This implies that the software creates descriptive links and ensures that the generated tables have headings and descriptions that allow for proper interpretation.

Finally, the criteria related to tables, forms, and time-based media related to videos and audio, such as 1.3.1, 4.1.2, and the criteria in 1.2.1 to 1.2.5, require that the transformer generates accessible forms and that the multimedia elements have adequate subtitles and descriptions. It is important that the software creates forms that include clear instructions and controls that are understandable and usable by all users.

The operation of the ACG WebAcc prototype is illustrated in the diagram in Figure 3, which presents the overall flow from uploading the UML model to generating accessible HTML code. This diagram provides a clear view of the tool’s main components, and the transformation process it carries out.

The user interface of the tool, represented in Figure 4, facilitates the interaction between the users and the system, enabling simple uploading of the UML file and the exploration of the generated output. This interface ensures an intuitive and efficient experience, minimizing the learning curve required by new users. To begin using the software, the user uploads the UML file using the “Upload File” option and selects the “Convert HTML” option. This process automatically generates a HTML file that complies with the WCAG, saving web designers time and reducing the chance of human error. In addition, the tool opens a new browser when the “Open browser” button is pressed that displays the results and creates a predesigned style sheet that enables the design to be customized, while maintaining accessibility.

4. Generation of Accessible Webpages

To address the challenges faced by programmers and facilitate the coding process, the ACG WebAcc code generator has been developed, which, based on a UML model, enables accessible webpages to be created according to the WCAG 2.2. This generator automates repetitive coding tasks, while also addressing the details related to accessibility features that can be automated, resulting in a significant reduction in development time and, therefore, costs.

To demonstrate the functionality of the code generator, UML models were developed that represent various HTML elements of the UN website, including the menu, images, videos, audio, links, headings, paragraphs, tables, and forms. These models are based on the WebAcc profile; the profile description can be found in [26]. This section presents the results obtained after the application of the development process of the ACG WebAcc code generator took place, as described in Section 3.1.

4.1. Definition of the UML Profile with Accessibility Requirements

To define the UML profile including accessibility, the accessibility requirements were first identified by reviewing the principles in the WCAG 2.2, with the aim of determining the elements that the system should comply with. The principles selected were guideline 1.1 text alternatives, guideline 1.2 time-based media, guideline 1.3 adaptable, guideline 2.4. navigable, guideline 3.1 readable, and guideline 4.1 compatible.

The profile properly defines the <title> tag and <lang> attribute to improve web accessibility, making it easier for screen readers to understand the content. It includes alternative text for complex images, clear instructions in forms, and ensures the correct structuring of tables, forms, and multimedia content. All of these considerations comply with the WCAG 2.2 and are supported by restrictions in the OCS language to ensure accessibility. The profile description can be found in [26].

4.2. UML Modeling and Accessible Website Generation

In this section, the profile is implemented in specific UML models, ensuring that the stereotypes, labels, and restrictions previously established in the profile correctly represent the accessible elements of the interface and the structure of the website. The validation of the model is carried out through the execution of OCL rules, for which it will be necessary to enter the requested data in regard to the different attributes related to the criteria in WCAG 2.2. Subsequently, webpages are generated using the ACG WebAcc software.

4.2.1. Main Page Generation

This subsection describes the automatic generation of the homepage based on the input model. The process includes the transformation of structural and semantic elements into accessible HTML code. In this example, multimedia elements from the official United Nations website were selected to demonstrate the applicability and effectiveness of the proposed approach.

Figure 5 illustrates the UML model representing various elements of the UN homepage, including the main menu, images, links, audio, videos, titles, and paragraphs. To meet the accessibility requirements, the model requests several essential values.

Descriptive alternative texts are required for all non-decorative images, allowing visually impaired users to understand visual content. In addition, it is critical to include audio descriptions for videos and transcripts for audio content, ensuring that people with hearing and visual impairments can access the information.

The inclusion of a clear and descriptive title is necessary for users and search engines to immediately understand the subject of the content. The language of the page must also be specified using the lang attribute, which helps screen readers correctly pronounce the text.

In Figure 6, you can see a fragment of the webpage generated by the ACG WebAcc prototype, which incorporates various elements designed to improve accessibility and the user experience. These elements include images with descriptive attributes, which enable users to understand the visual content on the page.

Figure 7 shows a snippet of the generated HTML code that illustrates the structure resulting from the model transformation. This excerpt demonstrates how accessibility attributes and semantic elements are incorporated to ensure compliance with the WCAG, especially regarding the use of images, videos, links, and accessible menus.

In addition, the navigation menu has been structured in a way that facilitates access to different sections, ensuring that all users, regardless of their skills, can move around the site intuitively.

The inclusion of videos and audio is also significant, as subtitles and descriptions have been implemented to make the audio content more accessible.

Finally, a strategic link has been added at the top of the page that allows users to jump directly into the main content block, eliminating the need to navigate through repetitive information. Together, these elements contribute to creating an inclusive and user-friendly web environment, reflecting ACG WebAcc’s commitment to digital accessibility.

4.2.2. Generating a Page with a Table

This subsection focuses on the generation of a HTML page containing tabular data. The example used illustrates how the transformation process handles table structures, while maintaining accessibility and semantic correctness.

Figure 8 illustrates the UML model of a page containing a table. This model highlights the structure of the table, which includes key elements, such as headings, rows, and columns. To ensure that the information is organized in an accessible and understandable manner, several specific attributes are defined.

The captionTable attribute is used to provide a clear title that describes the contents of the table, helping users immediately understand its purpose. On the other hand, the summaryTable attribute provides an overview of the table, making it easier for users, especially those using screen readers, to understand its structure and the data.

The noRowstr and noColumnstd attributes indicate the number of rows and columns in the table, respectively. This information is crucial for screen readers, because it allows users to better understand the layout of the data.

In addition, the leftCollsHeaders and topRowHeaders attributes are used to identify the headers in the left columns and the rows at the top, which establishes a clear association between the data and the descriptions. This is essential for the correct interpretation of the table and significantly improves accessibility.

Figure 9 shows the generation of the UN web table, designed with a focus on accessibility and clarity. This table includes the main title that provides an overview of the content, enabling users to quickly understand the purpose of the information presented. In addition, it has a summary that provides additional context, facilitating the interpretation of the data for those who may need it.

The table is organized in a structured format, consisting of 3 columns and 18 rows. This provision allows for the clear and logical presentation of information, making it easier for users to follow. Each column is used to group related data, which helps users identify patterns and effectively compare the information.

In addition, the table includes a caption, which acts as a brief legend that explains the contents of the table concisely. This element is essential to improving accessibility, as it allows assistive technology users to immediately understand what the table is about.

Together, these elements ensure that the table is not only functional, but also accessible and understandable to all users, regardless of their capabilities.

Figure 10 shows a snippet of the generated HTML code for the table, demonstrating the process by which accessible code is automatically generated from the modeled elements defined in the UML profile.

4.2.3. Generating a Page with a Form

This subsection describes the process of generating an accessible webpage that includes a form, based on the defined UML elements and their associated properties. The goal is to demonstrate how form components are modeled and turned into accessible HTML code.

Figure 11 shows the UML model of the UN web form. This model emphasizes the importance of various attributes designed to improve the accessibility and usability of the form.

The instructionsForm attribute provides clear and concise guidelines that guide users on how to complete a form. These instructions are essential to ensure that all users understand the process to fill in the form and to reduce the possibility of errors.

The titleForm attribute is used to offer a descriptive title that indicates the overall purpose of the form, helping users quickly identify the information required.

Each form control is assigned an ID attribute, which is crucial for the unique identification of each element. This attribute enables elements to be referenced accurately, which is especially useful for screen readers.

In addition, the attribute is implemented in the labels (label) to establish a clear association with the corresponding controls. This partnership significantly improves accessibility by allowing assistive technology users to activate controls by simply selecting the tag, making it easier for them to interact with the form.

Figure 12 shows the generated webpage for a form. The title of this form clearly identifies its purpose, ensuring that users immediately understand its function. Additionally, the structure-related accessibility follows best practices, including properly labeled fields and a logical tab order, which facilitate interactions for all users, including those relying on assistive technologies.

The form presents a description that provides general instructions on how to complete the form. These instructions are important to facilitate user interactions, as they detail the steps to be taken and any specific requirements that users should consider, such as filling in mandatory fields.

In addition, it includes three text type input fields, each accompanied by clear labels that improve accessibility and usability, enabling users to easily understand what information is required. It also has a text area field for longer answers and a captcha that poses a simple mathematical question to verify that the user is human.

Finally, the form includes a submit button that enables users to submit their information after the form is complete. This button is essential for the functionality of the form, and its design should be clear and visible to ensure that users can easily access it.

A snippet of the generated HTML code is shown in Figure 13, which illustrates how the structural and semantic elements of a web form, defined in the model, are automatically transformed into accessible HTML code.

5. Results

This section presents step four in our proposal, which addresses validation and accessibility testing, wherein it is verified that the generated HTML page complies with the accessibility requirements established in the UML profile, according to the selected criteria from the WCAG 2.2. This process includes both automatic and manual testing, using specialized tools to assess the accessibility of the generated code. Automatic tests identify common problems, such as the absence of alt tags in images or inadequate keyboard navigation due to the lack of semantic tags, while manual tests enable the validation of more subjective aspects, such as the experience of users who have some type of disability or a review of the consistency of the content provided in regard to the different labels and controls. After testing, the necessary adjustments were made to the models and code to correct the problems detected, thus ensuring that the website is accessible and functional before deployment.

Table 1. Webpages generated by the ACG WebAcc prototype.

No.	Webpage	URL
1	Homepage	https://kfordonez.github.io/AccPage/ (accessed on 10 November 2024)
2	Page with a table	https://kfordonez.github.io/TableAccPage/ (accessed on 10 November 2024)
3	Page with a form	https://kfordonez.github.io/FormAccPage/ (accessed on 10 November 2024)

shows the links of the pages generated by the ACG WebAcc prototype.

The tool selected for accessibility validation was Tingtun Checker, as it provides detailed reports on the errors detected. By accessing this tool through a web browser, users can enter a URL and get a detailed analysis of the site’s accessibility.

Tingtun Checker’s analysis of the homepage revealed that out of a total of 74 elements analyzed, all of them passed in regard to the accessibility criteria, without failures or alerts in regard to the requirement for manual verification. This result is highly positive, indicating that the website adequately complies with the accessibility guidelines established by the WCAG. The absence of flaws suggests that the design and development practices implemented are effective, ensuring that the content is accessible to all users, including those who have some type of disability. The results can be found in Figure 14.

It can be highlighted that all the images have alternative text, which enables users of assistive technologies to understand the content. The videos also include subtitles, ensuring that people with hearing disabilities can access the information presented.

The structure of the lists in the main menu is adequate, with <ul> and <ol> elements containing only <li> elements, which reinforces the clarity in regard to the organization of the content. However, it would be advisable to change the names of the links in the menu that are set by default, in order to ensure that they relate to the purpose of each link.

Another positive aspect is the fulfilment of the criteria related to navigation and readability. The page has a link at the top to go to the main content section and, thus, allows blocks of repeated content to be avoided, facilitating a more fluid user experience. In addition, it ensures that all the links have discernible text and that those with the same name have a similar purpose, which reduces confusion. It is also noted that the document includes a title and that the <html> element correctly specifies the language attribute, contributing to better navigation and understanding of the content.

It is important to mention that the evaluated page does not have ARIA attributes. The HTML structure is already semantically correct, so there is no need to use additional ARIA attributes. HTML elements, such as <header>, <nav>, <main>, and <footer>, provide clear information about their function and their relationship on the page. In such cases, the use of ARIA attributes may be redundant and, if applied incorrectly, could complicate accessibility. Therefore, it is essential to prioritize well-structured and semantic HTML code, ensuring that the page is accessible without adding unnecessary complexity.

The accessibility analysis of the page with a table, using Tingtun Checker, as shown in Figure 15, involved 73 tests, checking 16 different rules, which were executed and passed, reviewing 9 WCAG compliance criteria: 1.3.1, 1.4.3, 2.4.1, 2.4.2, 2.4.4, 2.4.9, 3.1.1, 4.1.1, and 4.1.2.

The accessibility analysis showed that the webpages were in compliance with several criteria, but it is important to mention that they are static webpages in which neither ARIA elements nor dynamic code, only HTML, have been considered. This approach makes it possible to evaluate fundamental aspects of accessibility effectively. For example, all the cells in the table where attribute headers are used correctly refer only to other cells in the same table, improving navigation for assistive technology users. In addition, <th> elements are suitably related to their data cells, making it easier to understand tabular content.

Also, the webpage meets the criterion of sufficient color contrast, which ensures good readability of the text. A link has been included at the top of the page to target the main content to avoid blocks of repeated content, which improves the browsing experience. The page includes a proper title, and all the links are discernible and have clear purposes. It has also been verified that the language attribute in the <html> element is correctly specified and that the IDs are unique, thus contributing to better overall accessibility.

The accessibility analysis of the page with a form, using Tingtun Checker, as shown in Figure 16, reveals positive results in regard to several key aspects of the form. It has been verified that all the form elements have appropriate labels, thus complying with the accessibility standards. This is critical, as labels allow users, including those using assistive technologies, to easily understand what information needs to be entered into each field. Likewise, all the links present in the form have discernible text, which facilitates their identification and use, contributing to a better browsing experience. In addition, a link has been implemented at the top of the page that allows users to skip to the main content, improving the fluidity of navigation in regard to the form.

Another important aspect is compliance with the color contrast requirements, which ensures that the information presented is easily readable and accessible to all users, including those with visual impairments. It has also been confirmed that the document includes a <title> element, which is essential to facilitate navigation and identification of the content in the form. In addition, the unique identifiers for the active elements have been verified, which avoids confusion in terms of the interactions.

Table 2. WCAG 2.2 success criteria validated per page.

Principles	Guidelines	Validated Success Criteria	Homepage	Page with a Table	Page with a Form
1. Perceivable	1.1 Text Alternatives	1.1.1 Non-text Content	Yes	NA	NA
	1.2 Time-based Media	1.2.1 Audio Only and Video Only (Prerecorded)	Yes	NA	NA
		1.2.2 Captions (Prerecorded)	Yes	NA	NA
		1.2.3 Audio Description or Media Alternative (Prerecorded)	Yes	NA	NA
		1.2.4 Captions (Live)	NA	NA	NA
		1.2.5 Audio Description (Prerecorded)	Yes	NA	NA
	1.3 Adaptable	1.3.1 Info and Relationships	Yes	Yes	Yes
2. Operable	2.4 Navigable	2.4.2 Page Titled	Yes	Yes	Yes
		2.4.4 Link Purpose	YES	YES	YES
		2.4.6 Headings and Labels	YES	YES	YES
3. Understandable	3.1 Readable	3.1.1 Language of Page	YES	YES	YES
4. Robust	4.1 Compatible	4.1.2 Name, Role, Value	NA	NA	YES

Note: NA stands for “Not Applicable”.

sets out the WCAG 2.2 success criteria validated by Tingtun Checker for the three types of web pages evaluated: homepage, page with a table, and page with a form. The evaluation is divided into the fundamental principles of accessibility, which are perceivable, operable, understandable, and robust, each with the corresponding guidelines and criteria.

The perceptible principle ensures that users can access the content of the page through different senses, especially sight and hearing. Regarding guideline 1.1 text alternatives, the homepage meets success criterion 1.1.1 non-text content, indicating that suitable textual alternatives are provided for the non-textual elements, such as images, which is essential for visually impaired users, who rely on assistive technologies, such as screen readers. The page with a table and the page with a form do not have images; therefore, they were not validated with respect to this criterion.

Guideline 1.2 time-based media focuses on the accessibility of multimedia content, such as videos and audio, for people with hearing or visual disabilities. As for criterion 1.2.1 audio only and video only (prerecorded), in regard to the homepage, this criterion must be validated since it has an audio only file, which implies that the file has a textual transcription. As for subtitles and audio descriptions, the homepage meets the criterion 1.2.2 captions (prerecorded) and 1.2.3 audio description or media alternative (prerecorded) criteria, providing subtitles and audio descriptions for the videos. The page with a table and the page with a form do not have audio and video files; therefore, these elements have not been validated. In addition, in relation to the subtitle criteria for live video criterion 1.2.4 captions (live), none of the pages have synchronized videos that are played in real time. The page with a form and the page with a table do not have videos or audios; therefore, they were not validated with respect to this criterion.

Guideline 1.3 adaptable states that content must be designed in a way that can adapt to the diverse needs and contexts of users, ensuring that the browsing experience is accessible and flexible for everyone. In this sense, criterion 1.3.1 info and relationships has been validated and it is met in regard to all the pages evaluated, indicating that the structure of the page is well-organized and that the relationships between the different elements, such as text, images, and forms, are clear and understandable. This is crucial for users who depend on assistive technologies, such as screen readers, since the correct structuring of the information allows these systems to interpret precisely how the contents are related, thus facilitating navigation and an understanding of the content by people with visual or cognitive disabilities.

Regarding criterion 1.3.1 info and relationships, it was validated that the headers in the pages are used in a hierarchical and logical manner. The headers <h1>, <h2>, <h3>, etc., must organize the content in a coherent way, representing a clear structure that facilitates navigation. This allows users, especially those using assistive technologies, such as screen readers, to jump between sections efficiently.

In addition, it was verified that the page with a form has clear labels appropriately associated with the respective fields, using the <label> element. This ensures that screen reader users can identify and understand the purpose of each form field (e.g., “Name” for the corresponding text field). There should also be clarity in regard to the relationship between visual and functional elements, such as images, buttons, links, and tables. Images must have adequate alt text, and buttons must be correctly described for users to understand their function. The content must follow a logical order, both visually and semantically, allowing users to navigate sequentially without confusion. In the page with a table, the existence of column headings (<th>) that were correctly associated with the data cells (<td>) was validated, and interactive elements, such as links and buttons, must be labeled clearly, with the possibility of navigating through a keyboard, without depending exclusively on a mouse.

The operable principle ensures that users can interact effectively with the interface, and under this principle, guideline 2.4 navigable, focuses on facilitating navigation and an understanding of the interactive content. Criterion 2.4.2 page titled is met in regard to all the pages evaluated, which means that each page has a title that reflects its content, which is essential for users to quickly understand what the page is about when navigating between them. In addition, criterion 2.4.4 link purpose is also met in regard to all the pages evaluated, ensuring that all links have a clear purpose and are easily understandable, facilitating efficient navigation, especially for users who rely on assistive technologies, such as screen readers.

Criterion 2.4.6 headings and labels is met in regard to all the pages evaluated, which means that appropriate headings and labels are used to facilitate user understanding and navigation, especially in regard to extensive or complex content, such as forms or tables. These elements structure the content so that users can access the information quickly and easily, regardless of the length or complexity of the page. Together, these criteria ensure that the interface is operable, and that navigation is clear and accessible to all users.

The understandable principle ensures that the information and interface are easy for users to understand, which is critical for ensuring an accessible user experience. In this context, criterion 3.1.1 language of page is met in regard to all the pages evaluated, which implies that the language of each page is correctly specified in the HTML code. This requirement is essential for users to understand the content, as it enables text elements to be presented in the appropriate language and in a consistent manner, which is particularly important for people who rely on technology assistance, such as screen readers, who need to know the language to perform proper pronunciation and translation of the content. In addition, the correct declaration of the language improves the general accessibility of the page, since it facilitates the adaptation of assistive technologies to the different linguistic contexts of the users. By accurately specifying the language of the page, it ensures that users, regardless of their native language or the system they use, can access and understand the content without barriers.

The robust principle ensures that content is compatible with a wide range of assistive technologies and devices. As for criterion 4.1.2 name, role, value, it has been validated in regard to the page with a form, which means that the interactive elements on this page, such as the form, are correctly labeled and accessible by assisted technologies.

This criterion seeks to ensure that the interactive elements of a webpage (such as buttons, links, and form fields) are accessible to people using assistive technologies. To meet this criterion without the use of ARIA attributes, it is essential to use semantic and well-structured HTML tags. This involves using elements such as <a> and <label> to automatically assign roles, and <label> tags associated with form fields to provide accessible names. At this point, it is important to mention that on the homepage and on the page with a table there are no interactive elements, so it has not been possible to validate these aspects in relation to this criterion.

Table 3. Summary of results per page from Tingtun Checker.

Page	Errors	Alerts	Accessibility Criteria Evaluated	Comments
Homepage	0	0	1.1.1 Images with alternative text 1.2.2 Elements <video> with subtitles 1.3.1 Direct content allowed in <ul> and <ol> 1.3.1 Elements <li> in <ul> or <ol> 1.4.3 Sufficient color contrast 2.4.1 Method to avoid repetitive blocks 2.4.2 Title in navigational documents 2.4.4, 4.1.2 Links with discernible text 2.4.9 Links with similar purpose and same name 3.1.1 Lang attribute in <html> 3.1.1 Valid value in lang of <html> 4.1.1 Unique values for ID attribute	- It is a static webpage in which neither ARIA elements nor dynamic code have been considered. - Some links in the main menu have the name “Section no”, which is not informative. This text can be modified directly in the HTML code, adjusting it to the specific purpose of each link in the page menu. - Videos with synchronized audio include textual transcriptions, which are recommended to be reviewed manually.
Page with a Table	0	0	1.3.1 All cells in a table that use the headers attribute must refer only to other cells in the same table 1.3.1 All <th> elements and elements with role=columnheader/rowheader must have data cells that describe them 1.3.1, 4.1.2 Elements with aria-hidden should not contain focused elements 1.4.3 The elements must have sufficient color contrast 2.4.1 The page must have a means of omitting repeated blocks 2.4.2 The document must have a <title> element to aid navigation 2.4.4, 4.1.2 Links must have discernible text 2.4.9 Links with the same name must serve a similar purpose 3.1.1 The <html> element must have a lang attribute 3.1.1 The lang attribute of the <html> element must have a valid value 4.1.1 The IDs used in ARIA attributes and tags must be unique 4.1.1 The value of the ID attribute must be unique 4.1.2 Elements must only use allowed ARIA attributes 4.1.2 Elements with aria-hidden=‘true’ should not be present in the body of the document 4.1.2 ARIA attributes must conform to valid values 4.1.2 ARIA attributes must conform to valid names	- Since the page is static and has no dynamic elements, ARIA attributes are not necessary. In this case, the accessibility of the page is ensured through the use of a well-defined HTML structure, using semantic tags, such as <header>, <footer>, <nav>, and <article>, which provide a clear context and facilitate navigation for users, especially those using assistive technologies.
Page with a Form	0	0	1.3.1, 4.1.2 Form elements must have labels 1.4.3 The elements must have sufficient color contrast 2.4.1 The page must have a means of omitting repeated blocks 2.4.2 The document must have a <title> element to aid navigation 2.4.4, 4.1.2 Links must have discernible text 2.4.9 Links with the same name must serve a similar purpose 3.1.1 The <html> element must have a lang attribute 3.1.1 The lang attribute of the <html> element must have a valid value 3.3.2 Form fields must not have multiple label elements 4.1.1 The IDs of active items must be unique 4.1.1 The IDs used in ARIA attributes and tags must be unique 4.1.1 The value of the ID attribute must be unique 4.1.2 Elements with aria-hidden=‘true’ should not be present in the body of the document 4.1.2 Input buttons must have discernible text	- These are static webpages where neither ARIA elements nor dynamic code have been considered.

presents a summary of the results generated by Tingtun Checker. The homepage presents a good structure in terms of accessibility, meeting the main accessibility criteria, without errors or alerts. Among the criteria evaluated, the appropriate use of alternative text in images (1.1.1), the inclusion of subtitles in videos (1.2.2), and the correct semantic organization in lists (1.3.1) stand out. The page also demonstrates sufficient color contrast (1.4.3) and contains a mechanism to avoid repetitive blocks (2.4.1). However, it was noted that some links in the main menu have names such as ‘Section no’, which are not informative for users, especially those using screen readers. It is recommended to edit the text in the HTML source code, so that each link reflects its specific purpose. In addition, although the videos include transcripts, a manual review would be useful to ensure that they are synchronized.

The page with a table also meets the basic accessibility criteria and has no errors or alerts. It was verified that the cells in the table that use the headers attribute only reference other cells in the same table (1.3.1) and that the row and column headers are well-defined. In addition, the links have discernible text (2.4.4) and the color contrast is adequate (1.4.3). Although Tingtun Checker evaluates the existence of ARIA attributes in HTML code, such as aria hidden, these are not necessary on a static page. Accessibility is mostly achieved thanks to a well-defined HTML structure, with semantic tags (<header>, <nav>, <main>, and <footer>), which facilitate navigation using assistive technologies without requiring additional Accessible Rich Internet Applications (ARIA) attributes.

The page with a form also meets the accessibility criteria and has no errors or alerts. This includes appropriate labels in the form fields (1.3.1) and sufficient color contrast (1.4.3). In addition, the page has a link at the top that goes directly to the main content of the page to avoid repetitive blocks (2.4.1) and a title in the document to improve navigation (2.4.2). In addition, each form field has a single associated label (3.3.2) to avoid confusion. Although ARIA attributes have not been used on this page, the HTML structure guarantees accessibility without requiring these elements, as it is a static website.

6. Discussion

This study presents an MDD approach that systematically incorporates accessibility features during the design of the conceptual models. First, a UML profile is developed to create accessible webpages, allowing the programming team to avoid a deep focus on non-functional requirements, such as accessibility. This ensures the quality of the site, thereby enabling a large number of users to access it without encountering issues. Additionally, it enhances the semantics by improving accessibility, allowing assistive technologies, such as screen readers, to quickly identify the main content of the page.

The WebAcc profile defines a set of stereotypes, constraints, and labeled values to represent the main properties of the model at the conceptual level, using the UML. We also use the OCL to specify the restrictions associated with the defined stereotypes, considering the Web Content Accessibility Guidelines (WCAG) 2.2. This prevents the arbitrary and incorrect use of these stereotypes.

Our proposal is based on the UML for two main reasons: (i) the UML is a well-known standard modeling language that is familiar to most database designers, allowing them to avoid learning a new notation, and (ii) the UML can be easily extended to adapt to specific domains with particular characteristics. Furthermore, our proposal employs the approach of transforming UML models into code through the creation of the ACG WebAcc software for the automatic generation of accessible HTML code.

The ACG WebAcc 1.0 prototype, created using the Python program, is designed to receive a UML model that is enriched with the values corresponding to the accessibility guidelines defined in the profile. This software automatically generates accessible HTML code, which not only saves time and effort, but also minimizes the risk of human errors when implementing accessibility practices.

In regard to the ACG WebAcc program, a specific code was incorporated to ensure the creation of an accessible webpage, using semantic sections such as <header> for the header, <main> for the main content, and <footer> for the footer. This structure not only improves content organization, but also facilitates navigation and an understanding of the content by all users, including those who use assistive technologies.

When generating the code for web forms, it was necessary to establish the respective associations between the <label> tag and the attribute, along with the ID of the <input> elements. Similarly, in tables, clear relationships were implemented between the headers and the corresponding rows or columns. These practices not only enhance accessibility, but also facilitate interactions and a comprehension of the content by all users, including those who use assistive technologies.

The automatic accessibility evaluation using the Tingtun Checker tool indicates compliance in several key areas, such as the use of alternative text for images (criterion 1.1.1), which allows users with visual impairments to understand visual content, and subtitles in videos (criterion 1.2.2), which are essential for users with hearing disabilities, enabling them to comprehend content without sound. This also benefits those who prefer reading over listening or are in noisy environments, as well as individuals whose native language differs from the spoken language in the video, contributing to a more inclusive and accessible experience for all users.

Additionally, the tool validated the existence of correctly structured lists (criterion 1.3.1), the presence of adequate color contrast (criterion 1.4.3), accessible navigation through discernible titles and links (criterion: 2.4.2, 2.4.4), and correct language attributes (criterion 3.1.1), which are essential for accessibility and SEO. It also confirmed the existence of unique identifiers (IDs) (criterion 4.1.1), which helps avoid confusion when interacting using assistive technologies, such as screen readers, that may misinterpret elements with duplicate IDs. However, manual review remains essential to address potential accessibility details that may not be automatically detected, such as the clarity of the content in links or textual alternatives, as well as the use of appropriate textual transcriptions.

The Tingtun Checker tool also confirmed various aspects of accessibility on the page with a table, highlighting that the table cells and their headers are correctly labeled (criterion 1.3.1), allowing for proper interpretation by screen readers. Furthermore, the color contrast meets the necessary standards for users with visual impairments (criterion 1.4.3), and the page includes a means to skip repetitive content (criterion 2.4.1), improving navigation. In addition, each link has discernible text (criterion 2.4.4), ensuring clarity and usability for all users, including those using assistive technologies.

Regarding the criterion related to language specification, the site complies through the use of the value of the lang attribute in the <html> element (criterion 3.1.1). Additionally, the use of multiple tags in form fields is avoided (criterion 3.3.2), which enhances clarity for users. On the other hand, there were three elements related to the uniqueness of identifiers (IDs), which are necessary to ensure that there are no conflicts in the code, in accordance with criterion 4.1.1 regarding the uniqueness of IDs in the active elements.

Finally, the site also met the criterion for ensuring that the aria hidden = ‘true’ attribute is not present in the document body, as this would prevent important content from being hidden from the users of assistive technologies (criterion 4.1.2). The criterion requiring input buttons to have discernible text (criterion 4.1.2) is also satisfied.

The results of this study underscore the importance of implementing accessibility practices during web development, demonstrating that the definition of stereotypes can significantly improve usability and inclusion for all users, especially those with disabilities. By structuring pages with semantic HTML code and clearly defining elements, such as the <title> tag and language attribute, better interactions with screen readers are facilitated. This supports previous findings indicating that proper identification of content is crucial for effective navigation in digital environments.

Furthermore, the incorporation of descriptive alternative text for images, the use of subtitles, and descriptions in videos and audio aligns with the WCAG 2.2 and highlights the need to provide access to visual and auditory information. This approach is fundamental not only for users with visual and auditory disabilities, but also benefits a wider audience by fostering content comprehension.

During the analysis of multimedia resources, it was noted that these pages did not contain live video streams. For this reason, the SC 1.2.4 captions (live) (level AA) criterion is not applicable in this context. The absence of such content exempts pages from meeting this specific requirement, as it only applies when multimedia material of that nature is included.

The accessibility analysis of the page with a form using the Tingtun Checker tool shows that most of the criteria are successfully met, suggesting that the page is accessible. Five elements related to forms were approved, such as the requirement that the form elements must have labels (criterion: 1.3.1, 4.1.2). In addition, the criterion for sufficient color contrast was approved, ensuring that elements are readable for users with visual impairments (criterion 1.4.3). The page also meets the requirement to provide means to skip repetitive blocks of content by placing a link at the top that directs the user to the main content of the page (criterion 2.4.1) and includes a <title> element to facilitate navigation (criterion 2.4.2). Regarding links, the criteria requiring links to have discernible text (criterion 2.4.4, 4.1.2) and that links with the same name serve a similar purpose (criterion 2.4.9) were successfully met.

When developing the accessibility tests, a manual evaluation was necessary to identify elements that the validation tool did not detect, such as the titleForm and instructionsForm attributes, which provide clear context and useful instructions for users when completing the form. Testing of the table was also necessary because of the existence of captionTable and summaryTable attributes, which offer detailed descriptions for screen reader users. Additionally, it is essential to verify that alternative text labels, links, and video transcriptions are clear and comprehensible to all users.

Our approach aligns with previous research by highlighting the importance of incorporating accessibility into web development and its incorporation during the early stages of the software development process. However, it differs in regard to its practical application of using a UML profile and OCL rules, allowing for the more comprehensive generation of accessible HTML code. Unlike other more limited proposals, our approach includes a UML profile that incorporates a set of accessibility guidelines from the WCAG 2.2 and the creation of a tool designed to generate accessible HTML code from a UML model. This model is fed with values established based on the attributes, according to the OCL rules defined in the profile. This methodology offers greater clarity and control over accessibility at each stage of development, thereby enabling website designers to implement accessibility standards more effectively and systematically.

Among the limitations of our approach, it is important to note that not all the guidelines from the different levels of the WCAG 2.2 have been considered. In this initial version, a preliminary selection of the accessibility guidelines was made for constructing the profile, focusing on those related to the principles of understandability, perception, operability, comprehensibility, and robustness, which could be easily automated in regard to the profile and code generator. However, as part of our future work, we plan to incorporate a broader set of guidelines into the WebAcc profile to facilitate the process of automatically generating accessible HTML code using the ACG WebAcc prototype. By enriching this profile with more guidelines, the tool’s ability to generate content that meets the latest and most diverse accessibility standards can be significantly improved, ensuring that webpages are usable by a wider variety of users, including those with visual, auditory, and motor disabilities.

Finally, it is important to recognize that, despite the efforts made, challenges may arise when implementing our approach. Limitations in developer training and a lack of awareness of web accessibility can hinder the effective application of the stereotypes defined in the profile. Therefore, we aim to promote a developmental culture that is more aware of the importance of digital accessibility.

Based on the analysis of various existing tools and approaches for generating accessible web content, key differences were identified in relation to the developed prototype, ACG WebAcc. Unlike model-based tools, such as ACELEO and WebRatio, which require a deeper knowledge of template customization or model transformations, ACG WebAcc allows designers and web developers to generate accessible code more easily, without the need to manipulate templates or have prior knowledge of accessibility standards. The survey conducted with designers and web developers, published in the IEEE Access journal, confirmed that the ACG WebAcc profile is more intuitive and practical compared to other techniques, especially for users with little experience of accessibility, which represents a significant advantage in educational environments and early adoption scenarios.

While there are AI-based solutions that automate the detection and correction of accessibility issues, these typically function as auditing or post-processing tools. In contrast, our approach focuses on generating accessible content from the outset, using a simplified and guided interface. Additionally, it is important to clarify that responsive design was not included within the scope of this work, since the WCAG only explicitly address this in criterion 1.4.10 (reflow), which was not considered at this stage of development. Future versions of the tool may integrate both responsive capabilities and ARIA support, which would further enhance its accessibility compliance.

7. Limitations and Future Work

Although the results obtained demonstrate the feasibility of generating accessible HTML code from UML models that incorporate a specific profile, it is important to recognize the current limitations of this proposal. First, the automatic generation was focused exclusively on static content, so dynamic interactions and the incorporation of technologies, such as WAI-ARIA (Accessible Rich Internet Applications), are not considered. These elements are essential to ensuring an accessible experience using modern web applications and, therefore, constitute a priority line of work for future research.

Second, the tool currently does not include integration with JavaScript frameworks, functionalities associated with responsive design, or exporting in regard to formats other than pure HTML. While these features are not necessary to demonstrate the objective of the work, validating the UML profile’s ability to produce accessible content, their incorporation would significantly expand the applicability of the proposal in real-world development environments. Finally, although this work does not include large-scale testing, a previous study evaluated the use of the proposed UML profile by web developers, most of whom highlighted its ease of use and understanding, as evidenced in the article published in IEEE Access. ACG WebAcc is primarily designed to generate accessible static HTML code from UML models. It is not intended for the creation of dynamic web applications or the integration with modern content management systems (CMSs).

As part of our future work, we propose incorporating responsive design mechanisms into the automatic generation of accessible webpages, considering that adaptability to different screen sizes is essential in today’s web environment. In this regard, the automatic inclusion of a responsive style sheet, which uses relative units, media queries, and flexible design best practices, could be considered within the code generation process.

Regarding its integration with CI/CD pipelines, the tool is projected to evolve into a command-line application (CLI app) that receives a UML file as input and automatically generates the corresponding code, without the need for a graphical interface. This functionality would enable the automatic generation and validation of accessible code to be incorporated into continuous integration and deployment processes.

When comparing ACG WebAcc with artificial intelligence-based tools, it is noteworthy that while technologies such as GPT-4 and GPT-4 Vision generate accessible code from textual descriptions or images of UML diagrams, ACG WebAcc adopts a proactive approach, integrating accessibility restrictions from the outset of the design process, using a specific UML profile. This approach allows accessible HTML code to be generated without manual intervention and facilitates the traceability of design decisions. Furthermore, as an open-source UML profile, it can be reused by other tools that use UML as a modeling technology. Finally, ACG WebAcc can be useful in environments where CMS systems and HTML editors are used, as it allows users to generate drafts of accessible code that can then be integrated into these systems. This is especially relevant because many accessibility issues on CMS-based websites stem from code manually entered into internal content editors.

8. Conclusions

The use of the ACG WebAcc code generator has enabled the creation of accessible webpages through the use of an MDD approach. This generator facilitates the implementation of features that ensure accessibility, making pages usable by all users, including those with disabilities. By prioritizing accessibility during web development, we aim to promote an inclusive and equitable digital environment in which everyone can interact with and benefit from content without barriers.

To efficiently integrate web accessibility features from the beginning of the software development lifecycle and optimize the automatic generation of accessible HTML code, it is essential to adopt an MDD approach. This method enables the creation of models that include accessibility guidelines from the initial stages of development, ensuring that these features are automatically translated into the relevant code during the generation phase. Additionally, training the development team on the WCAG and the implementation of accessibility techniques is crucial to ensure that these considerations are integrated into every design and coding decision.

Incorporating the UML profile into the creation of accessible webpages is an innovative approach that allows for the structuring and visual representation of the elements necessary to ensure accessibility. By defining stereotypes and OCL rules within the profile, clear guidelines can be established to guide web designers in implementing accessible features from the very beginning of the webpage development process.

It is important that accessibility be taken into consideration during the early stages of building a website. This highlights the significance of the current proposal, as the programming team does not need to focus extensively on the non-functional requirements, such as accessibility, which would greatly ensure the quality of the website and guarantee that a large number of users can access it without issues.

Automatic code generation from models is a key technique in software development that translates UML diagrams and other high-level models into the source code. This automatic process significantly improves productivity and consistency in the development process by reducing the margin of human error in regard to the design to implementation conversion.

For implementing our proposal, we determined that using semantic tags in the generated code, such as <header>, <nav>, <main>, and <footer> in HTML, not only facilitates content comprehension for users and search engines, but also enhances accessibility for the users of assistive technologies. Grouping content thematically with these tags promotes a clearer organization of the code, especially in larger projects. This semantic and structured approach not only optimizes the user experience, but also contributes to a more orderly and maintainable web development process.

Mechanisms for managing and verifying UML models are crucial for ensuring that they are correct, complete, and compliant with requirements, before proceeding to code generation. In this regard, the OCL rule validation tool in Eclipse plays a fundamental role, as it enables verification that the model meets all the constraints defined in the profile, in accordance with the established accessibility features. This ensures that the models not only adhere to the technical specifications, but also promote the creation of accessible and high-quality web applications, facilitating their effective implementation in the digital environment.

As an example, to showcase our approach, we modeled several webpages from the United Nations website, including the main page, and select specific elements for analysis, such as menus, images, videos, audio, titles, paragraphs, links, forms, and tables. The validation results from the Tingtun Checker tool indicated that these pages met the accessibility requirements defined in the profile. This process not only demonstrates the effectiveness of our approach, but also ensures that the content is accessible and usable by all users.

Validating the code generated by ACG WebAcc is vital to ensure its compliance with accessibility standards. In this case, we used the Tingtun Checker tool to verify that the code was error free and meet the WCAG 2.2 characteristics defined in the profile.

The accessibility analysis performed using the Tingtun Checker tool revealed that the evaluated pages met several essential standards, allowing for a more inclusive browsing experience. An adequate contrast between text and background colors was found, and all images had alternative text, benefiting users with visual disabilities. In addition, the page was fully navigable using a keyboard, providing access to users who cannot use pointing devices. The hierarchical structure of the headings and the use of semantic HTML elements, such as <header>, <main>, and <footer>, improved the organization and navigability of the content, especially for users who employ assistive technologies. The links were mostly descriptive, although some menu elements required adjustments to their default generated text to better reflect their purpose. Finally, the correct identification of the primary language as “en” and the inclusion of a title element are essential aspects that contribute to both accessibility and SEO.

Regarding the accessibility of multimedia content, the presence of subtitles was evident, but a manual evaluation is necessary to verify the coherence of this and the correct use of textual transcriptions. The forms are labeled correctly to improve usability and accessibility. Similarly, in tables, the use of <th> tags, scope attributes, and the establishment of a relationship between cells using ‘id’ and ‘header’, facilitates navigation and understanding for screen reader users.

The prototype was developed exclusively for academic purposes, with no intention of commercial use or distribution. Its importance lies in demonstrating the feasibility of generating accessible HTML code from UML models that incorporate specific accessibility constraints, which represents a significant contribution to the field of model-driven development (MDD). This approach aims to raise awareness among students, researchers, and developers about incorporating accessibility criteria from the early stages of the design process, thus promoting more inclusive practices in software engineering.

The benefits of our proposal are clear in regard to the generation of accessible HTML code and the creation of more inclusive digital environments. This approach highlights the importance of integrating the accessibility principles from the early stages of web design and development. By implementing a structured methodology that includes the use of a UML profile and the automatic generation of code, it is easier to comply with accessibility standards, allowing designers and developers to create webpages that are accessible to all users, including those with disabilities. Additionally, this approach not only improves the usability of web applications, but also promotes a culture of digital inclusion in the development field, benefiting the entire user community.

Automatic accessibility evaluation tools are important, but they do not guarantee a complete solution. These tools can detect common problems and suggest improvements, but do not replace manual reviews. Some accessibility barriers, such as the clarity of con-tent and the use of adequate textual transcriptions in videos and audio, require human evaluation to ensure that the page is completely accessible and intuitive for all users.