Generating Accessible Webpages from Models
Round 1
Reviewer 1 Report
Comments and Suggestions for AuthorsThe submitted manuscript proposes generation of accessible web pages from models. The idea has practical implications, as it may simplify the creation of own websites. A new tool is introduced that enables the automatic generation of accessible HTML code through a Model-Driven Development approach. UML diagram are used as the primary specification. The paper is in general well written and understandable, its contribution are clear. Some improvements are recommended to improve its quality.
Detailed comments:
#1 The presented approach does not consider all guidelines from the different levels of the WCAG 2.2 standard. Therefore, a question arises: what is the real tool's practicality? And how to create models that can be really useful?
#2 What about the responsivity of the generated web pages? I think this aspect is especially important nowadays, as different sizes of device’s screens are user by the individuals.
#3 The proposed approach does not concentrate on mobile screens. With respect to comment #2 or the scalability parameters – is it possible at all to create a web site that could be displayed on small screens?
#4 As the paper has strong practical implications, it is recommended to provide here some more illustrations. In the current version of the paper, only one generated website is presented, furthermore it is not scaled appropriately, but it looks like a little bit outdated (the menu bar is twice as wide as the rest of the content).
#5 Modern websites should first and foremost have good design. Which design principles (including UX design rules) are applied to generate user-friendly solutions? User experience (as for the ones who will use the website) needs to be also addressed much more in the paper.
#6 Which metrics are used to evaluate the generated websites? Although internet speed is good in most places, loading time is still an important issue.
#7 English writing, typing and style needs to be revised (e.g. “in-cluding” in line 946).
#8 Some text is not translated into English:
“. La traduc- 220
ción automática de diagramas UML a código orientado a objetos es muy conveniente, ya 221
que elimina la posibilidad de errores humanos.” 222
#9 The references seem to be incomplete.
#10 Figure 6 is hard readable.
Comments on the Quality of English Language
English writing, typing and style needs to be revised.
Author Response
Comments 1 The presented approach does not consider all guidelines from the different levels of the WCAG 2.2 standard. Therefore, a question arises: what is the real tool's practicality? And how to create models that can be really useful?
Response 1: Not all WCAG success criteria can be automated. A selection of criteria that can be automated was made in the IEEE Access article, which surveyed web development and design experts.
The objective of this work was to develop a tool capable of validating the technical feasibility of generating accessible HTML code from rich UML models that directly integrate these criteria. The tool is useful because it ensures, from the design point of view, compliance with a minimum accessibility baseline corresponding to essential AA level criteria, which are mandatory in most countries.
Furthermore, it provides the web developer with a structured starting point, automatically generating HTML code that meets these criteria, which reduces errors, saves time, and improves the initial quality of the web product.
Comments 2: What about the responsivity of the generated web pages? I think this aspect is especially important nowadays, as different sizes of device’s screens are user by the individuals.
Response 2: In this initial version of the tool, the main focus was on implementing automatable WCAG 2.2 accessibility criteria based on templates. However, we recognize that adaptability must be integrated into future development phases to ensure a more comprehensive solution.
As part of new section Limitations and Future Work, we propose incorporating responsive design mechanisms into the automatic generation of accessible web pages, considering that adaptability to different screen sizes is essential in today's web environments. In this regard, the automatic inclusion of a responsive stylesheet, which utilizes relative units, media queries, and flexible design best practices, could be considered within the code generation process.
Comments 3: The proposed approach does not concentrate on mobile screens. With respect to comment #2 or the scalability parameters – is it possible at all to create a web site that could be displayed on small screens?
Response 3: In this initial version of the tool, the primary focus was on implementing automatable WCAG 2.2 accessibility criteria from templates. However, we recognize that adaptability should be integrated into future development phases to ensure a more comprehensive solution.
Comments 4: As the paper has strong practical implications, it is recommended to provide here some more illustrations. In the current version of the paper, only one generated website is presented, furthermore it is not scaled appropriately, but it looks like a little bit outdated (the menu bar is twice as wide as the rest of the content).
Response 4: In response to your observation, we have included additional example pages: one featuring a form and another displaying a table with general data. We have also improved the visual quality of all screenshots, ensuring they are presented at an appropriate size. Additionally, direct links to the online versions of these pages have been added to facilitate full access to the multimedia content. Finally, the design of the menu bar has been revised to ensure its proportions are consistent with the overall page layout.
Regarding the accessibility criteria considered, this first prototype was mainly based on the functionality of the web, so that, following the principles of web accessibility, it is important that the content is usable by the majority of people, especially those who pose some type of disability, such as visuals, intellectuals, motors or hearing. Many of these people can only navigate with disabled features or through screen readers, so that a clear semantic structure and understandable navigation are prioritized.
However, to improve the design of the web page, it is included in the code generation process with some default styles that contemplate the theme of color contrast, related to Criterion 1.4.3 – Contrast (minimum) [Level AA] of WCAG. This criterion is the minimum contrast between the text and the background, which mainly favors people with low vision, color blindness, major adults with progressive vision loss, and those who navigate in conditions of poor lighting or with low brightness screens. The adequate contrast will significantly improve the legitimacy and usability of the content for these groups.
In summary, the prototype implemented a series of key accessibility criteria, among them: 1.1.1 Non-text Content; 1.2.1 to 1.2.5 (accessible audiovisual content); 1.3.1 Information and Relationships; 1.4.3 Contrast (minimum); 2.4.2 Page Titled; 2.4.4 Link Purpose; 2.4.6 Headings and Labels; 3.1.1 Language of Page; y 4.1.2 Name, Role, Value.
Comment 5: Modern websites should first and foremost have good design. Which design principles (including UX design rules) are applied to generate user-friendly solutions? User experience (as for the ones who will use the website) needs to be also addressed much more in the paper.
Response 5: We agree that good design and user experience (UX) are essential elements in the development of modern websites. However, it is important to clarify that the primary focus of this article is on web accessibility, specifically on the automatic generation of accessible HTML code from templates, in accordance with selected WCAG 2.2 criteria; therefore, it does not address usability issues.
It should be noted that, in many cases, people with disabilities prefer or need to disable CSS styles to interact more clearly and directly with a web page's content. This is especially true when visual styles interfere with the use of assistive technologies, such as screen readers, or when they hinder keyboard navigation. For this reason, accessible design must prioritize the correct semantic structure of HTML content, beyond its visual presentation. In this context, the automatic generation of structured code compliant with WCAG 2.2 is especially valuable, as it ensures that information is understandable and navigable even in the absence of styles. In terms of design, a style sheet addressing color contrast has been incorporated by default into the HTML code generation process, in line with WCAG Criterion 1.4.3 – Contrast (Minimum) [Level AA]. This criterion defines the minimum levels of contrast required between text and background, particularly benefiting people with low vision, color blindness, older adults with progressive vision loss, as well as users browsing in low-light conditions or on low-brightness screens. Adequate contrast significantly improves the readability and usability of content for these groups.
Comments 6: Which metrics are used to evaluate the generated websites? Although internet speed is good in most places, loading time is still an important issue.
Response 6: In this research, the evaluation focused exclusively on compliance with the accessibility criteria established by WCAG, as this was the main objective of the article. To this end, automated validation tools were used and tests were conducted with screen readers to verify the correct interpretation of the content by assistive technologies. No performance or general usability metrics were included, as these are beyond the scope of this work.
Comments 7: English writing, typing and style needs to be revised (e.g. “in-cluding” in line 946).
Response 7: The hyphenation error in the word "in-cluding" (line 946) was corrected. In addition, the entire document was reviewed to identify and correct similar errors, ensuring clearer, more coherent writing. Advanced grammar and style correction tools were also used to improve the text's flow.
Comments 8: Some text is not translated into English: “. La traducción automática de diagramas UML a código orientado a objetos es muy conveniente, ya 221 que elimina la posibilidad de errores humanos.” 222
Response 8: The text was translated: “The automatic translation of UML diagrams into object-oriented code is very convenient, thereby eliminating the possibility of human errors”. In line 225.
Comments 9 The references seem to be incomplete.
Response 9: We have reviewed all references cited in the manuscript and completed the missing references, corresponding to the DOI, URL and access dates.
Comments 10 Figure 6 is hard readable.
Response 10: Because Figure 6 has some multimedia components, we have added a link below the image name that redirects to the full version of the page.
Author Response File: 
Author Response.docx
Reviewer 2 Report
Comments and Suggestions for AuthorsThe authors in their manuscript presented an approach based on Model-Driven Development (MDD) and UML for automatic generation of accessible HTML pages compliant with WCAG. In my opinion, although the concept of integrating content accessibility from the modeling stage is valuable, the solution seems outdated. Currently, lightweight front-end frameworks (e.g. React), accessibility testing in CI/CD pipelines (e.g. aXe, Lighthouse) and component-based UI approach are preferred. There are no references to modern tools and practices, such as ARIA roles, responsive design (including one page design, long page design, hero image, etc.) or integration with design systems. In my opinion, the proposed solution may be difficult to implement in real projects. In addition, the ACG WebAcc application generates simple web pages. This tool is suitable for prototyping and learning WCAG accessibility principles, but not for building modern, dynamic websites. It is more suitable for education or creating small, static pages. Please comment.
Detailed notes:
1) The authors put forward the following thesis in their abstract: "One of the main reasons why websites do not comply with accessibility standards is limited knowledge of accessibility issues among software developers." - I do not agree with this thesis. To the best of my knowledge and years of practice, the main reason why websites do not comply with accessibility standards is the lack of knowledge and ignorance of website administrators and editors, not programmers. There are no major problems with the programming layer (back-end). Problems with maintaining accessibility at a high level lie with content editors and website administrators (front-end). Please comment.
1a) Is there a need to include Sir Timothy John Berners-Lee in the abstract? The abstract is a place for materials and methods, research results, and conclusions. Please comment.
2) In scientific articles, especially in the field of computer science or software engineering, acronyms are commonly used as keywords. Using acronyms alone as keywords can be problematic, however. In a scientific article, it is better to provide them in full with the acronym in parentheses, so that there is no doubt about their meaning. And it is good to add words that indicate the context. For consideration. Please comment.
3) Despite the interesting approach, the article has several limitations. First, there is no comparison with existing tools – there is no clear answer as to how ACG WebAcc differs from other tools that generate code from models (e.g. Acceleo, WebRatio). There is also no formal validation of the tool’s usability by end users (e.g. programmers or accessibility testers), which limits the assessment of its practical value.
3a) Second, the accessibility tests are based solely on static pages and an automatic validator (Tingtun Checker), without taking into account dynamic interactions or ARIA /Accessible Rich Internet Applications/. There is also no analysis of the tool’s technical limitations, e.g. what about responsiveness, JS frameworks, or export outside of HTML. Finally, the article requires some linguistic refinement in places – there are repetitions and minor stylistic errors, which may make it difficult for international reviewers to receive. More details below.
4) The authors wrote in the introduction: "However, since these tools alone are insufficient, manual evaluation by an expert remains essential to ensure that a website is fully accessible." (line 48) - it seems to me that something is missing here. In audits of content accessibility for people with disabilities, what is important is not the opinion of an expert or the result of code validation, but the opinion of a person with a disability. A full WCAG audit is an audit performed by people with disabilities, an expert, and appropriate tools. Please comment.
5) The application described in the manuscript – ACG WebAcc – focuses exclusively on the automatic generation of accessible HTML code compliant with WCAG 2.2, using the MDD approach and UML with accessibility profiles. The system generates static HTML pages and performs accessibility validation using tools such as Tingtun Checker. However, other content formats, such as PDF, office documents, or multimedia not embedded/embedded in HTML, are not included in this tool. The application does not generate or verify the accessibility of PDF files, which must also meet WCAG requirements in the context of e.g. text alternatives, structure tags, tagging or support by screen readers. The developed solution therefore has some limitations. Please comment.
5a) There is no separate Limitations and further research section, which was useful in this article.
6) There is some minor chaos in the article. I mean the way some abbreviations and acronyms are written, e.g. HTML5 is used once, and HTML 5 (with a space) is used once; or – WCAG is used once, and Wcag is used another time (see Figure 2). The way of writing should be standardized. Please comment.
6a) There is a reference to Figure 7 in line 437. There is a reference to Figure 4 in line 428, but I cannot find a reference to Figure 3. The reference to Figure 3 is only in line 453, i.e. under Figure 4. It seems that this is an error and the numbering of figures (references to figures) is mixed up. Figures 3 and 4 are glued together. The whole thing is a bit confusing. Please comment.
6b) Have all acronyms and abbreviations been included in the Abbreviations section?
7) What is the potential for commercialization of the developed tool? It seems that it is only able to generate single, simple, static sites. Meanwhile, advanced web applications managed via CMS, not FTP, are currently expected. Please comment.
8) After reading this study, the question arises - why and for whom was this application created? In my opinion, it has a model, educational application - a prototype. Not knowledge of innovation and implementation potential. Maybe I'm wrong. Please correct me. Please comment.
Detailed notes: On the one hand, the authors have done some work – the ACG WebAcc tool automates the generation of accessible HTML from UML models and integrates specific WCAG rules. This can be helpful for programmers with little experience in WCAG. On the other hand, AI-based tools (LLM GPT) can already generate WCAG-compliant HTML based on prompts and without UML models; they can automatically analyze and fix accessibility errors in existing code; they can also process PDF, DOCX or presentation files and assess their compliance with WCAG, which ACG WebAcc cannot do. In addition, LLMs are flexible and contextual and are not limited to rigid model rules. Additionally, few people write code from scratch today. Most websites are created based on ready-made prefabs, including CMS systems. If a similar tool were developed based on AI, it would be more versatile, more modern and could actually support the full spectrum of digital accessibility, not just HTML. All this makes the developed application seem outdated. The key question is therefore: What is innovative about it? How does it outperform AI and applications based on LLM GPT AI? What is new in this article? Please comment.
9) Consequently, in my opinion, it is necessary to expand the Discussion section with considerations on the differences, similarities, advantages and possibilities of the developed ACG WebAcc tool compared to other tools and techniques, especially AI.
Author Response
Comments 1. The authors in their manuscript presented an approach based on Model-Driven Development (MDD) and UML for automatic generation of accessible HTML pages compliant with WCAG. In my opinion, although the concept of integrating content accessibility from the modeling stage is valuable, the solution seems outdated. Currently, lightweight front-end frameworks (e.g. React), accessibility testing in CI/CD pipelines (e.g. aXe, Lighthouse) and component-based UI approach are preferred. There are no references to modern tools and practices, such as ARIA roles, responsive design (including one page design, long page design, hero image, etc.) or integration with design systems. In my opinion, the proposed solution may be difficult to implement in real projects. In addition, the ACG WebAcc application generates simple web pages. This tool is suitable for prototyping and learning WCAG accessibility principles, but not for building modern, dynamic websites. It is more suitable for education or creating small, static pages. Please comment.
Response: Currently, there is no tool that generates web pages considering OCL accessibility constraints predefined in a UML-based design model. In our article published in the high-impact journal Universal Access in the Information Society (UAIS) in 2022, we already presented a systematic review addressing this issue.
A recent search of the journal Universal Access in the Information Society (UAIS) found a total of 3,387 articles published in the last 6 months related to the topics of WEB ACCESSIBILITY AND Model-Driven Development. Similarly, a search today in Google Scholar for publications that include the term "UML" from just 2025 (four months), yields several thousand results; and a search for "model-driven development" returns nearly 300 publications. This demonstrates a growing and ongoing interest in this line of research.
It is important to emphasize that the primary objective of this article is academic. However, we have taken your suggestion into account and consider it pertinent to include in the future work section that the tool can be improved by incorporating additional restrictions for generating ARIA-compliant code.
Likewise, the inclusion of certain WCAG 2.2 accessibility criteria related to responsive design could be considered. It should be noted that these criteria are very limited; in WCAG 2.2, for example, only criterion 1.4.10: Reflow is explicitly considered. This criterion states that content must be displayed without loss of functionality and without the need for two-dimensional scrolling for vertically scrolling content with a width equivalent to 320 CSS pixels, and for horizontally scrolling content with a height equivalent to 256 CSS pixels. https://www.w3.org/WAI/WCAG22/Understanding/reflow.html. In fact, for example, a blind person does not visually interact with the screen, so visual design is irrelevant to their browsing experience. In many cases, they use browsers with style sheets disabled, accessing only textual content through screen readers. This reinforces the importance of a semantic and accessible HTML structure, beyond the visual aspects of the design.
Regarding the statement: “Currently, lightweight front-end frameworks (e.g., React), accessibility testing in CI/CD pipelines (e.g., aXe, Lighthouse), and component-based UI approaches are preferred,” it is worth noting that the use of UML models is not exclusive to these current technologies. In fact, it is possible to model applications based on frameworks such as React or Angular and subsequently generate compatible code from these models. There are model-driven development (MDD) approaches that integrate both paradigms, as evidenced in recent work, for example:
https://www.researchgate.net/publication/342455789_A_Model_Driven_Approach_for_Generating_Angular_7_Applications . This demonstrates that UML modeling can complement the use of modern frameworks, providing benefits such as increased maintainability, reusability, and automated generation of accessible components.
The first version of our prototype generates only static HTML code. However, as a future line of work, we plan to expand the tool to allow the generation of code compatible with different front-end frameworks. This would be achieved by extending the current UML profile or complementing it with specific profiles that consider the modeling specifics of each framework.
Regarding accessibility testing, although some of the tools mentioned by the reviewer, such as aXe or Lighthouse, could have been used, we chose Tingtun Checker because it is an online solution that does not require installation, thus facilitating its use during the development phase.
In this first version, our prototype generates only static HTML code. As future work, we plan to expand the tool to generate code compatible with different front-end frameworks, either by extending the current UML profile or complementing it with specific profiles that include the modeling specifics for each framework.
Regarding accessibility testing, although tools like aXe or Lighthouse, which you mentioned, could have been used, we chose Tingtun Checker because it's an online tool that doesn't require installation, making it easier to use during development.
Finally, we consider that in the future the tool could be converted into a command-line application (CLI app) that receives a UML file and automatically generates accessible code without a graphical interface, thus allowing its integration into CI/CD pipelines.
Detailed notes:
Comments 1. The authors put forward the following thesis in their abstract: "One of the main reasons why websites do not comply with accessibility standards is limited knowledge of accessibility issues among software developers." - I do not agree with this thesis. To the best of my knowledge and years of practice, the main reason why websites do not comply with accessibility standards is the lack of knowledge and ignorance of website administrators and editors, not programmers. There are no major problems with the programming layer (back-end). Problems with maintaining accessibility at a high level lie with content editors and website administrators (front-end). Please comment.
Response 1: To avoid potential ambiguities in the interpretation of the term "software developers," we have chosen to replace it with "website designers," as we believe this expression more accurately reflects the professional profile we are referring to in the context of this article. The change has been applied to the abstract and the body of the text to maintain terminological consistency.
Comments 1a) Is there a need to include Sir Timothy John Berners-Lee in the abstract? The abstract is a place for materials and methods, research results, and conclusions. Please comment.
Response 1: The reference to Timothy John Berners-Lee in the summary has been removed. Based on these considerations the summary has been modified.
Summary
Despite significant efforts to promote web accessibility through 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 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 tool, 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, following 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.
Comments 2. In scientific articles, especially in the field of computer science or software engineering, acronyms are commonly used as keywords. Using acronyms alone as keywords can be problematic, however. In a scientific article, it is better to provide them in full with the acronym in parentheses, so that there is no doubt about their meaning. And it is good to add words that indicate the context. For consideration. Please comment.
Response 2: He has revised this section and, in accordance with its recommendation, has replaced the acrónimos aislados per los términos completos seguidos del acrónimo entre paréntesis. Additionally, we add additional key words that provide a better thematic context and facilitate understanding and understanding of the article.
Keywords: Web Accessibility, Model-Driven Architecture (MDA), Model-Driven Devel-opment (MDD), Model-Driven Engineering (MDE), UML profile, HTML (HyperText Markup Language), Object Constraint Language (OCL), Web Content Accessibility Guide-lines (WCAG), Automatic Code Generation(ACG).
Comments 3. Despite the interesting approach, the article has several limitations. First, there is no comparison with existing tools – there is no clear answer as to how ACG WebAcc differs from other tools that generate code from models (e.g. Acceleo, WebRatio). There is also no formal validation of the tool’s usability by end users (e.g. programmers or accessibility testers), which limits the assessment of its practical value.
Response 3: We would like to clarify that the main objective of this work is not to present the tool as a final or commercial product, but rather to demonstrate that it is possible to generate accessible HTML code from a model based on the proposed UML profile. This profile has been previously validated through surveys administered to web designers and developers, as detailed in our article published in IEEE Access.
As for tools such as Acceleo or WebRatio, while they are capable of generating code from models, their approach is general and they do not consider checking for accessibility-related restrictions within the models.
Furthermore, we consider it important to highlight that the tool does not present any difficulties in use, as its operation is based on a very simple process: the user supplies a file with the UML model and receives a file with the generated HTML code as output. Given its level of simplicity, it could even be implemented as a command instead of requiring a graphical interface.
Comments 3a) Second, the accessibility tests are based solely on static pages and an automatic validator (Tingtun Checker), without taking into account dynamic interactions or ARIA /Accessible Rich Internet Applications/. There is also no analysis of the tool’s technical limitations, e.g. what about responsiveness, JS frameworks, or export outside of HTML. Finally, the article requires some linguistic refinement in places – there are repetitions and minor stylistic errors, which may make it difficult for international reviewers to receive. More details below.
Response 3a: The code generated by the tool is static and does not include ARIA elements, so its incorporation is not relevant in the context of this work. Regarding responsive design, it is important to clarify that the WCAG only specifically addresses this aspect in criterion 1.4.10: Reflow. Since this criterion is not part of the scope of our proposal, responsive design was not considered in the development of the prototype; it could be considered as future work.
Comments 4. The authors wrote in the introduction: "However, since these tools alone are insufficient, manual evaluation by an expert remains essential to ensure that a website is fully accessible." (line 48) - it seems to me that something is missing here. In audits of content accessibility for people with disabilities, what is important is not the opinion of an expert or the result of code validation, but the opinion of a person with a disability. A full WCAG audit is an audit performed by people with disabilities, an expert, and appropriate tools.
The paragraph in question has been modified:
Response 4: 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, or if this is not possible, use disability simulators, for example, to simulate different types of color blindness; and access the website with assistive technologies used by people with disabilities, such as a screen reader used by blind people.
Comments 5. The application described in the manuscript – ACG WebAcc – focuses exclusively on the automatic generation of accessible HTML code compliant with WCAG 2.2, using the MDD approach and UML with accessibility profiles. The system generates static HTML pages and performs accessibility validation using tools such as Tingtun Checker. However, other content formats, such as PDF, office documents, or multimedia not embedded/embedded in HTML, are not included in this tool. The application does not generate or verify the accessibility of PDF files, which must also meet WCAG requirements in the context of e.g. text alternatives, structure tags, tagging or support by screen readers. The developed solution therefore has some limitations. Please comment.
Response 5. A new section called Limitations and Future Research Lines has been added:
The content of this section is detailed below:
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, automatic generation has 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 in 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 formats other than pure HTML. While these features are not necessary to demonstrate the objective of the work—to validate 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 with 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 integration with modern content management systems (CMS).
As part of future work, we propose incorporating responsive design mechanisms into the automatic generation of accessible web pages, considering that adaptability to different screen sizes is essential in today's web environments. 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.
The first version of our prototype generates only static HTML code. However, as a line of future work, we propose expanding the tool to allow the generation of code compatible with different front-end frameworks. This would be achieved by extending the current UML profile or complementing it with specific profiles that consider the specific modeling requirements of each framework.
Regarding 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 allow the automatic generation and validation of accessible code to be incorporated into continuous integration and deployment processes.
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 you 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.
Comments 6. There is some minor chaos in the article. I mean the way some abbreviations and acronyms are written, e.g. HTML5 is used once, and HTML 5 (with a space) is used once; or – WCAG is used once, and Wcag is used another time (see Figure 2). The way of writing should be standardized. Please comment.
Response 6: HTML5 and HTML 5 were changed to HTML, and Wcag to WCAG.
Comments 6a) There is a reference to Figure 7 in line 437. There is a reference to Figure 4 in line 428, but I cannot find a reference to Figure 3. The reference to Figure 3 is only in line 453, i.e. under Figure 4. It seems that this is an error and the numbering of figures (references to figures) is mixed up. Figures 3 and 4 are glued together. The whole thing is a bit confusing. Please comment.
Response 6a: The content was modified "These models are based on the WebAcc profile, the profile description can be found in [25]." It is a reference but not an image.
Added Reference to Figure 3. ACG WebAcc prototype OperatingDiagram, on page 10.
Comments 6b) Have all acronyms and abbreviations been included in the Abbreviations section?
Response 6b: The following ACRONYMS have been included
W3C World Wide Web
MDD Model-Driven Development
HTML HyperText Markup Language
SDGs United Nations Sustainable Development Goals
UML Unified Modeling Language
OCL Object Constraint Language
WCAG Web Content Accessibility Guidelines
OMG Object Management Group
SEO Search Engine Optimization
ACG Automatic Code Generation
ARIA Accessible Rich Internet Applications
UN United Nations
DSL Domain-Specific Language
GUIs Graphical User Interfaces
REST Representational State Transfer
MDA Model Driven Architecture
CIM Computation Independent Model
ISM Implementation Specific Model
LAM Learning Activity Mechanisms
DSL Domain Specific Language
MVC Model View Controller
ATL Atlas Transformation Language
AI Artificial Intelligence
Comments 7. What is the potential for commercialization of the developed tool? It seems that it is only able to generate single, simple, static sites. Meanwhile, advanced web applications managed via CMS, not FTP, are currently expected. Please comment.
Response 7: The objective of our proposal is not commercialization, but rather to demonstrate that HTML code can be generated that meets WCAG accessibility criteria, provided that accessibility constraints are properly integrated into the UML design model. It may be suggested that commercial model-driven code generation tools should include something similar, and if they use UML as their modeling technology, then they could freely reuse the created UML profile, which is open source.
We recognize that the tool is currently geared toward generating simple, static websites and does not compete with more advanced commercial CMS-based solutions or modern deployment flows such as those that replace the use of FTP. However, we believe that the main contribution lies in demonstrating that model-driven development approaches can incorporate accessibility from the early stages of the design, something that is not typically present in many current tools.
In this regard, we suggest that commercial model-driven code generation tools consider incorporating similar mechanisms. Since the developed UML profile is open source, it can be freely reused by other solutions that use UML as a modeling technology, thus facilitating the integration of accessibility as part of the automated development process.
Comments 8. After reading this study, the question arises - why and for whom was this application created? In my opinion, it has a model, educational application - a prototype. Not knowledge of innovation and implementation potential. Maybe I'm wrong. Please correct me. Please comment.
Response 8:
Why?: Because today, the majority of websites in the world do not comply with accessibility standards such as WCAG. This is demonstrated by recent studies such as the 2024 AccessibilityChecker.org study, according to which more than 80% of websites do not comply. https://www.accessibilitychecker.org/research-papers/the-state-of-web-accessibility-in-2024-research-report/
Even the European Union published its monitoring reports on the accessibility status of the websites of public bodies in member countries in February 2025, and there are still numerous accessibility non-compliances: https://digital-strategy.ec.europa.eu/en/news/web-accessibility-directive-monitoring-reports-2022-2024
Whom?: It has two main audiences:
1) Website creators who use UML models in website design. It is not possible to determine how many web designers use UML, but a 2024 study found more than 500 open-source software development projects on GitHub that use UML models using automated search techniques: https://sonar.ch/global/documents/330716. Furthermore, thousands of recent UML documents can be found using Google Scholar or other search tools.
2) Creators of tools for automatic HTML code generation from models or creators of extensions for such tools. Thanks to our work, these creators could adapt our proposal to their tool to generate more accessible HTML code. If their tool is based on UML models, they could directly reuse our open-source UML profile along with other profiles that already exist in the tool. Therefore, thanks to our work, innovation in the field of DRM tools could be achieved by incorporating our proposal or directly our UML profile to incorporate accessibility requirements into the design model before code generation.
Detailed notes: On the one hand, the authors have done some work – the ACG WebAcc tool automates the generation of accessible HTML from UML models and integrates specific WCAG rules. This can be helpful for programmers with little experience in WCAG. On the other hand, AI-based tools (LLM GPT) can already generate WCAG-compliant HTML based on prompts and without UML models; they can automatically analyze and fix accessibility errors in existing code; they can also process PDF, DOCX or presentation files and assess their compliance with WCAG, which ACG WebAcc cannot do. In addition, LLMs are flexible and contextual and are not limited to rigid model rules. Additionally, few people write code from scratch today. Most websites are created based on ready-made prefabs, including CMS systems. If a similar tool were developed based on AI, it would be more versatile, more modern and could actually support the full spectrum of digital accessibility, not just HTML. All this makes the developed application seem outdated. The key question is therefore: What is innovative about it? How does it outperform AI and applications based on LLM GPT AI? What is new in this article? Please comment
Response: First, we agree that the tool has a strong educational and prototype component. Our main objective has not been to compete with AI-based solutions, but rather to propose a methodological alternative that incorporates accessibility from the early stages of design, using a Model-Driven Development (MDD) approach. Unlike LLM-based tools like GPT, which act on already generated code or generate it from prompts, our proposal is based on integrating accessibility restrictions before a single line of code is written. We believe this proactive approach has significant value in certain development contexts.
Regarding your statement “AI-based tools (LLM GPT) can already generate WCAG-compliant HTML (…), they can automatically analyze and fix accessibility errors in existing code,” we believe this statement is still under debate within the accessibility community. Some leading experts in the field of accessibility disagree: https://adrianroselli.com/2023/06/no-ai-will-not-fix-accessibility.html, https://karlgroves.com/chatgpt-is-not-ready-to-handle-web-accessibility-remediation/
Therefore, it is not about "surpassing" AI, but rather offering a complementary, structured, and controlled approach that can be useful in scenarios where traceability, formal verification, or model reuse is important.
Regarding the argument about the limited use of code developed from scratch and the predominance of pre-made CMSs and templates, our approach may also make sense in these environments. Many CMSs allow users to incorporate content through built-in HTML editors. Experience shows that a good part of the accessibility problems on CMS-based websites stem from the HTML code that users enter manually. In these cases, pre-modeling complex content—forms, tables, or interactive sections, for example—could facilitate the generation of accessible HTML from a more structured environment.
In fact, it wouldn't be difficult to develop a CMS plugin that integrates our modeling approach, allowing accessible HTML to be generated within the CMS's visual editor. This would expand the tool's use beyond static sites, adapting it to modern workflows.
In short, the purpose of ACG WebAcc is not to compete with AI, but rather to offer a model-based alternative for integrating accessibility by design. The tool has potential as a support in educational settings and also as a complement to CMS environments, where many accessibility issues persist. The innovation of this work lies in the formalization of accessibility rules within a reusable, open-source UML profile, which can be integrated into other tools or processes.
Comments 9. Consequently, in my opinion, it is necessary to expand the Discussion section with considerations on the differences, similarities, advantages and possibilities of the developed ACG WebAcc tool compared to other tools and techniques, especially AI.
Response 9: The following content was added in Discussion
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 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 AccWebAcc profile is more intuitive and practical compared to other techniques, especially for users with little experience in 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 WCAG guidelines only explicitly address it 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.
Author Response File: Author Response.docx
Round 2
Reviewer 1 Report
Comments and Suggestions for AuthorsI appreciate the efforts of the authors to improve paper’s quality. I have no other comments.
Author Response
We sincerely appreciate your acknowledgment of the efforts made to improve the quality of the article. We value your comments throughout the review process.
Author Response File: Author Response.docx
Reviewer 2 Report
Comments and Suggestions for AuthorsThe authors responded to all my comments and suggestions for corrections, but in my opinion the article is chaotic. I accept all explanations, but I evaluate the manuscript critically. The article is definitely too long and chaotic for me, which makes it difficult to read.
Comments on the manuscript:
a) Some figures are of poor quality (e.g. Figure 5 – pixelation; Figure 6 – unnatural distortion – flattening). Perhaps this will be corrected at the production stage (manuscript typesetting).
b) Figure 7 – this is not a figure, it is a table containing HTML code – this should be corrected.
c) in my opinion the numbering of figures in the text is wrong, e.g. line 449 – it is written: "An operating diagram of the ACG WebAcc software is shown in Figure 7." – meanwhile Figure 7 presents: "HTML Code Extract from the Generated Home Page", although it is not a figure, but a table with code/text. As a result, there is a certain mess in the numbering.
d) the numbering of the figures is mixed up – first figure 3, then figure 4, right after it figure 7 (line 449), below it figure 4, and on line 466 figure 1. Figures 8-10 are above the text that refers to them – you can get lost. This gives the impression of chaos. A scientific article should present the phenomena described in a simple and orderly way. In this manuscript it is not.
e) for some reason the HTML code in the tables that are signed Figure 10 and 13 does not contain the opening section/tag BODY – why? – yes, there is a closing </body> (Figure/Table 13), but no opening – why?
Author Response
Comments 1 The authors responded to all my comments and suggestions for corrections, but in my opinion the article is chaotic. I accept all explanations, but I evaluate the manuscript critically. The article is definitely too long and chaotic for me, which makes it difficult to read.
Response 1: We sincerely appreciate your thorough review and the acknowledgment that we have addressed all comments and correction suggestions.
In response, we have carefully revised the content to improve clarity and coherence, reducing redundancies and enhancing the logical flow between sections.
Comments 2: Some figures are of poor quality (e.g. Figure 5 – pixelation; Figure 6 – unnatural distortion – flattening). Perhaps this will be corrected at the production stage (manuscript typesetting).
Response 2: Regarding Figures 5 and 6, only representative excerpts are included due to their length. In both cases, a link to the full version has been provided immediately after the figure title — for Figure 5, this corresponds to the complete UML model of the main page used as an example, and for Figure 6, it allows access to the full version of the referenced website.
Comments 3: Figure 7 – this is not a figure, it is a table containing HTML code – this should be corrected.
Response 3: Figure 7 does not correspond to a traditional figure, but rather to a screenshot of an HTML code snippet hosted on GitHub. To maintain consistency in the graphical presentation of the content, the label “Figure” is retained, as the “Table” label is generally used to display data organized in rows and columns. However, for greater clarity, the caption will be updated to “Figure 7. HTML Code Snippet,” and a direct link to the full HTML file will be included immediately after the caption, thereby facilitating access to the complete code. We appreciate the observation, as it contributes to improving the accuracy and clarity of the manuscript.
Comments 4: c) in my opinion the numbering of figures in the text is wrong, e.g. line 449 – it is written: "An operating diagram of the ACG WebAcc software is shown in Figure 7." – meanwhile Figure 7 presents: "HTML Code Extract from the Generated Home Page", although it is not a figure, but a table with code/text. As a result, there is a certain mess in the numbering.
Response 4: The line 449, which states "An operating diagram of the ACG WebAcc software is shown in Figure 7," has been removed. Additionally, we have corrected the order of the images so that the references properly align with their numbering, avoiding any confusion in the text.
Comment 5: d) the numbering of the figures is mixed up – first figure 3, then figure 4, right after it figure 7 (line 449), below it figure 4, and on line 466 figure 1. Figures 8-10 are above the text that refers to them – you can get lost. This gives the impression of chaos. A scientific article should present the phenomena described in a simple and orderly way. In this manuscript it is not.
Response 5: Line 449, which referred to Figure 7 and stated “An operating diagram of the ACG WebAcc software is shown in Figure 7,” was removed as it was an unintentional error. We have conducted a thorough review of the document to properly reorganize all figures and ensure they are presented in sequential order according to their first mention in the text. Regarding Figures 8 to 10, their placement was corrected by relocating them immediately after the paragraph where they are first mentioned. This adjustment improves readability and comprehension of the content, ensuring that the illustrations properly accompany the text that introduces them, in accordance with good practices in scientific writing.
Comments 6: e) for some reason the HTML code in the tables that are signed Figure 10 and 13 does not contain the opening section/tag BODY – why? – yes, there is a closing </body> (Figure/Table 13), but no opening – why?
Response 6: The omission of the opening <body> tag has been corrected in Figures 7, 10, and 13 by including it to ensure the structural consistency of the code snippet and facilitate its proper interpretation.
Author Response File: Author Response.docx
Round 3
Reviewer 2 Report
Comments and Suggestions for AuthorsBasically, the article requires many editorial corrections, especially the bibliography. In my opinion, it also has limited substantive value. However, it may find an audience interested in WCAG audits.
Author Response
Thank you for your comments and for taking the time to review our manuscript. We acknowledge that there were editorial issues to address, especially in the bibliography section, so we have conducted a thorough revision to improve both its clarity and formatting, following the guidelines established in the journal’s template.
While we understand your observation regarding the substantive value of the manuscript, we believe that the practical focus on WCAG audits may be of interest to a specific audience involved in web accessibility evaluation. Furthermore, this is a topic of considerable interest to the community of web designers and developers, given the growing importance of digital accessibility.
Additionally, we consider it important to highlight the relevance of Model-Driven Development (MDD) in our work. MDD provides a systematic approach that facilitates abstraction, improves software quality, and enables the automation of key development processes, thereby contributing to system efficiency and portability.
