Web page accessibility enhancement method and device, computer device and storage medium

Abstract

The application discloses a webpage accessibility enhancement method and device, computer equipment and a storage medium, and relates to the technical field of computers, and aims to solve the problem that in related technologies, when facing the dynamic semantics of a complex interactive component, inaccurate or redundant accessibility enhancement attributes are easily generated, and the overall accessibility of a webpage is reduced. The method comprises the following steps: obtaining an element to be processed in a webpage; extracting multi-dimensional accessible features of the element to be processed; determining a target element type of the element to be processed in an accessibility scene based on the multi-dimensional accessible features; generating corresponding accessibility enhancement attributes according to the target element type and the multi-dimensional accessible features; and injecting the accessibility enhancement attributes into a document object model node corresponding to the element to be processed, so that an assistive technology can access the element to be processed based on the accessibility enhancement attributes.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a method, apparatus, computer device, and storage medium for enhancing web accessibility. Background Technology

[0002] With the deepening of internet accessibility initiatives, ensuring that dynamic web pages and complex interactive components can be smoothly accessed by assistive technologies such as screen readers has become a key technical challenge. To address this, the World Wide Web Consortium (W3C) developed the ARIA (Accessible Rich Internet Applications) standard. Its core mechanism involves adding semantic ARIA attributes, such as role and aria-label, to HTML (Hypertext Markup Language) elements. This injects explicit accessibility semantic information into custom controls created by developers, compensating for the semantic accessibility deficiencies of these non-native controls. However, manually and precisely adding ARIA attributes to complex interactive components not only demands a high level of accessibility knowledge from developers but also incurs significant implementation and maintenance costs in large-scale projects.

[0003] To reduce this engineering burden, a method for generating accessible pages has been proposed in related technologies. This method first parses the Cascading Style Sheets (CSS) and Document Object Model (DOM) structure of the target page. Then, based on a set of predefined static rules (which typically match specific CSS class names, style properties, or tag types), it automatically identifies the DOM nodes that require accessibility enhancement. Finally, according to a preset attribute mapping configuration file, it batch-injects the corresponding ARIA attributes into these DOM nodes.

[0004] While the above methods can achieve a certain degree of automation, they are essentially based on a static rule matching mechanism. This makes them prone to generating inaccurate or redundant accessibility enhancement attributes when faced with the dynamic semantics of complex interactive components, which in turn reduces the overall accessibility of the webpage. Summary of the Invention

[0005] Based on this, a method, apparatus, computer device, and storage medium for enhancing web page accessibility are provided to solve the problem in related technologies that, when faced with the dynamic semantics of complex interactive components, inaccurate or redundant accessibility enhancement attributes are easily generated, which in turn reduces the overall accessibility of the web page.

[0006] In a first aspect, this application provides a method for enhancing webpage accessibility, the method comprising: Retrieve the elements to be processed from the webpage; Extract the multi-dimensional accessibility features of the element to be processed; the multi-dimensional accessibility features include at least two of the document object model structural features, visual features, interaction mode features and semantic features of the element to be processed; Based on the multi-dimensional accessibility features, the target element type of the element to be processed in the accessibility scenario is determined; Based on the target element type and the multi-dimensional accessibility features, corresponding accessibility enhancement attributes are generated; the accessibility enhancement attributes include at least one of role attributes, status attributes, and descriptive attributes used to assist access. The accessibility enhancement attributes are injected into the document object model node corresponding to the element to be processed, so that assistive technologies can access the element to be processed based on the accessibility enhancement attributes.

[0007] In some embodiments, obtaining the elements to be processed in the webpage includes: By traversing the document object model tree of the webpage, elements that do not meet the preset accessibility standards are identified as the first type of elements to be processed. Detect change events in the document object model tree, and in response to the change events, determine the changed elements as the second type of elements to be processed.

[0008] In some embodiments, if there are multiple elements to be processed, the method further includes, before extracting the multi-dimensional accessibility features of the elements to be processed: Perform an interactiveness prediction on each of the elements to be processed to obtain the corresponding initial prediction type; Based on the initial predicted type of each element to be processed and the visibility of each element to be processed within the current browser viewport, a differentiated processing priority is set for each element to be processed.

[0009] In some embodiments, determining the target element type of the element to be processed in an accessibility scenario based on the multi-dimensional accessibility features includes: The multi-dimensional accessible features are encoded separately to obtain multi-dimensional encoded vectors; The multi-dimensional encoding vectors are fused across modalities to obtain a unified semantic representation vector; Based on the unified semantic representation vector, the candidate element types and corresponding confidence levels of the element to be processed in the accessible access scenario are determined. The candidate element type with the highest confidence level is determined as the target element type.

[0010] In some embodiments, generating corresponding accessibility enhancement attributes based on the target element type and the multi-dimensional accessibility features includes: Based on the target element type and the multi-dimensional accessibility features, a comprehensive decision context is generated. The comprehensive decision context is matched with a preset attribute decision rule base; the rules in the attribute decision rule base define the state attributes or descriptive attributes that should be adapted for different element types and their associated context information. The accessibility enhancement attributes are generated based on the matched rules.

[0011] In some embodiments, injecting the accessibility enhancement attribute into the document object model node corresponding to the element to be processed includes: Obtain the existing accessibility attributes on the document object model node; Determine whether there is a semantic conflict between the accessibility enhancement attribute and the existing accessibility attribute; If semantic conflicts exist, the attribute injection scheme is determined according to the preset conflict resolution strategy; If there is no semantic conflict, the accessibility enhancement attribute is injected into the document object model node.

[0012] In some embodiments, after injecting the accessibility enhancement attribute into the document object model node corresponding to the element to be processed, the method further includes: Obtain the accessibility information corresponding to the document object model nodes after attribute injection; The accessibility information is compared with the semantic information expected based on the target element type and the multi-dimensional accessibility features; If the comparison is inconsistent, it is determined that the accessibility enhancement attribute injection has not achieved the expected effect, the accessibility enhancement attribute is removed, and the corresponding element to be processed is added back to the processing queue.

[0013] Secondly, this application provides a webpage accessibility enhancement device, the device comprising: The acquisition module is used to retrieve elements to be processed from a webpage. An extraction module is used to extract multi-dimensional accessible features of the element to be processed; the multi-dimensional accessible features include at least two of the document object model structural features, visual features, interaction mode features and semantic features of the element to be processed; The determination module is used to determine the target element type of the element to be processed in an accessibility scenario based on the multi-dimensional accessibility features. The generation module is used to generate corresponding accessibility enhancement attributes based on the target element type and the multi-dimensional accessibility features; the accessibility enhancement attributes include at least one of role attributes, status attributes, and description attributes for assisting access. An accessibility enhancement module is used to inject the accessibility enhancement attributes into the document object model node corresponding to the element to be processed, so that assistive technologies can access the element to be processed based on the accessibility enhancement attributes.

[0014] Thirdly, this application provides a computer device including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the web accessibility enhancement method of the first aspect described above.

[0015] Fourthly, this application provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the webpage accessibility enhancement method of the first aspect described above.

[0016] The aforementioned webpage accessibility enhancement methods, devices, computer equipment, and storage media extract and comprehensively utilize multi-dimensional features such as the DOM structure, visual characteristics, interaction patterns, and semantic context of the elements to be processed. This intelligently determines the target element type in an accessibility scenario and dynamically generates precisely matched accessibility enhancement attributes such as roles, states, and descriptions. Finally, these attributes are injected into the corresponding DOM nodes. This fundamentally upgrades accessibility enhancement from static rule-based mechanical matching to context-aware dynamic semantic adaptation, thereby providing accurate, real-time, and non-redundant accessibility support for complex interactive components, enabling assistive technologies to reliably access dynamic webpage content. Attached Figure Description

[0017] Figure 1 A flowchart illustrating a webpage accessibility enhancement method provided in this application embodiment; Figure 2 A schematic diagram of the architecture of a web accessibility enhancement system provided in this application embodiment; Figure 3 A schematic diagram of the structure of a web accessibility enhancement device provided in this application embodiment; Figure 4 This is a schematic diagram of the internal structure of a computer device provided in an embodiment of this application. Detailed Implementation

[0018] To make the objectives, technical solutions, and advantages of this application clearer, the application will be further described in detail below with reference to the accompanying drawings. The specific operational methods in the method embodiments can also be applied to the device embodiments or system embodiments. It should be noted that in the description of this application, "multiple" is understood as "at least two". "And / or" describes the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing together, or B existing alone. A connected to B can represent: A and B directly connected, or A and B connected through C. Furthermore, in the description of this application, terms such as "first" and "second" are used only for distinguishing the purpose of description and should not be construed as indicating or implying relative importance or order.

[0019] Before introducing the webpage accessibility enhancement method provided in the embodiments of this application, the technical background of this application will be described in detail below for ease of understanding.

[0020] Currently, webpage accessibility is a standardized webpage processing method used to help visually impaired people access the web. Among related technologies, accessibility page generation devices can enhance the ability of visually impaired people to browse pages through browser plugins, thereby improving accessibility. This accessibility page generation device first parses the Cascading Style Sheets (CSS) and Document Object Model (DOM) structure of the target page. Then, based on a set of predefined static rules (which are typically based on matching specific CSS class names, style properties, or tag types), it automatically selects the DOM nodes that need accessibility enhancement. Finally, according to a preset attribute mapping configuration file, it batch-injects the corresponding ARIA (Accessible Rich Internet Applications) attributes into these DOM nodes.

[0021] While the above methods can achieve a certain degree of automation, they are essentially based on a static rule matching mechanism. This makes them prone to generating inaccurate or redundant accessibility enhancement attributes when faced with the dynamic semantics of complex interactive components, which in turn reduces the overall accessibility of the webpage.

[0022] In view of this, this application provides a webpage accessibility enhancement method, apparatus, computer device, and storage medium to solve the problem in related technologies that when faced with the dynamic semantics of complex interactive components, inaccurate or redundant accessibility enhancement attributes are easily generated, which in turn reduces the overall accessibility of the webpage.

[0023] The technical solution provided in this application will be described in detail below with reference to the accompanying drawings and specific embodiments.

[0024] Figure 1 A flowchart illustrating a webpage accessibility enhancement method provided in this application embodiment includes the following steps: S101, retrieve the elements to be processed in the webpage; S102, Extract the multi-dimensional accessible features of the element to be processed; S103, Based on multi-dimensional accessibility features, determine the target element type of the element to be processed in the accessibility scenario; S104, Generate corresponding accessibility enhancement attributes based on the target element type and multi-dimensional accessibility features; S105, Inject accessibility enhancement attributes into the document object model node corresponding to the element to be processed, so that assistive technologies can access the element to be processed based on accessibility enhancement attributes.

[0025] In this application embodiment, the multi-dimensional accessibility features include at least two of the following: DOM features, visual features, interaction mode features, and semantic features of the element to be processed; the semantic features are used to characterize the functional semantics implied by the visual features of the element to be processed; the accessibility enhancement attributes include at least one of the following: role attributes, state attributes, and descriptive attributes for assistive access, which conform to the ARIA accessibility technical specifications and are intended to provide clear interaction semantics for assistive technologies.

[0026] Specifically, DOM features refer to information extracted from the DOM tree of a webpage that reflects the structural attributes of elements, including but not limited to: the element's tag name, such as... <button>(Button) <input> (Input box), the element's hierarchy depth in the DOM tree, the type and number of parent and child nodes, and the type of adjacent nodes (such as adjacent elements in a button group), and other structured information.

[0027] Visual features refer to information that reflects the final rendering effect of an element, obtained by calling the Application Programming Interface (API) provided by the browser, including but not limited to style information, layout information, and icon information.

[0028] For example, you can get the geometric position and size of an element within the current browser viewport by calling the getBoundingClientRect() method (which is the method to get the bounding rectangle information of an element); and you can get the final style information of an element after all CSS rules have been calculated by calling the window.getComputedStyle() method (which is the method to get the calculated style of an element), such as color, font, border properties, etc.

[0029] Interaction pattern features refer to information reflecting the usage patterns of elements obtained by binding event detectors to elements and collecting user interaction event data. For example, by detecting user events such as click, focus, and blur, and based on parameters such as the frequency and duration of event triggering, interaction pattern features such as historical click frequency and average focus dwell time can be calculated.

[0030] Semantic features refer to functional semantics that are inferred from the comprehensive analysis of the visual features of elements and have general meanings in user interface design languages. For example, a "red triangle" represents "warning," and a "shopping cart icon" represents "purchase function."

[0031] Then, the aforementioned multi-dimensional access features are input into a pre-trained analysis model. This model possesses cross-modal information fusion capabilities, enabling unified encoding and correlation analysis of features from different types and sources. Through internal logic processing, the model ultimately outputs the target element type of the element to be processed in an accessibility scenario, such as "button," "navigation link," "text input box," or "icon." This achieves intelligent mapping from raw features to standard accessibility semantic categories.

[0032] Next, the target element type and multi-dimensional accessibility features are used to generate specific and executable accessibility enhancement attributes through preset dynamic decision rules. These mainly include role attributes, i.e., the target element type, such as role="button"; state attributes, which describe the current state of the element to be processed, such as aria-expanded="true" (area expansion state attribute="true"); and description attributes, which provide the element to be processed with an accessible name, description, or relationship with other elements, such as aria-label="search" (accessibility label attribute="search").

[0033] Finally, the generated accessibility enhancement attributes are injected programmatically into the DOM node corresponding to the element to be processed. The injection operation can be atomic, such as adding attributes one by one by calling the element.setAttribute() method (the method for setting attributes of an element); or it can be a batch injection optimized for a large number of similar elements.

[0034] After attribute injection is completed, when visually impaired users access the webpage using assistive technologies such as screen readers, the assistive technologies can directly read and accurately parse the elements to be processed, thereby accurately identifying the element's role, knowing its status in real time, and clearly broadcasting its descriptive information, thus achieving successful access and smooth interaction with the elements to be processed.

[0035] By employing the methods described above, multi-dimensional features of the elements to be processed, including DOM structure, visual characteristics, interaction patterns, and semantic context, are extracted and comprehensively utilized to intelligently determine the target element type in an accessibility scenario. Based on this, precisely matching accessibility enhancement attributes such as roles, states, and descriptions are dynamically generated, and these attributes are ultimately injected into the corresponding DOM nodes. This fundamentally upgrades accessibility enhancement from static rule-based mechanical matching to context-aware dynamic semantic adaptation, thereby providing accurate, real-time, and non-redundant accessibility support for complex interactive components, enabling assistive technologies to reliably access dynamic web page content.

[0036] In some embodiments, it is exemplarily illustrated that obtaining elements to be processed in a webpage includes, but is not limited to: The initial scanning process begins during the initial loading phase of a webpage, after the browser has loaded the webpage and completed the initial construction and rendering of its DOM tree.

[0037] Specifically, the DOM tree corresponding to the webpage is traversed programmatically (e.g., depth-first or breadth-first algorithms) to obtain elements that do not meet the preset accessibility standards, which are then treated as the first type of elements to be processed.

[0038] The preset accessibility standards include, but are not limited to: whether image elements are missing the alt (alternate text) attribute or whether the attribute value is empty; interactive controls (such as...) <input> ,< / button> <button>) Is an accessible name missing (e.g., missing aria-label); are container elements with specific semantics missing the correct role; are custom controls composed of generic elements without semantics, such as... (Division) It consists of (span) and other elements, and does not use ARIA attributes for semantic enhancement.

[0039] During the traversal, DOM elements that do not meet one or more of the above preset accessibility standards will be identified as the first type of elements to be processed and added to the processing queue. These elements represent known accessibility defects that exist in the initial state of the page.

[0040] During the webpage's runtime phase, a preset dynamic detection mechanism detects DOM tree change events, and in response to these events, identifies the changed elements as the second type of elements to be processed and adds them to the processing queue.

[0041] For example, this dynamic detection mechanism is implemented based on the Mutation Observer API provided by the browser, and the specific steps are as follows: Create a MutationObserver instance and configure it to detect the following types of DOM tree change events: Child node change events: Detects insertion and removal events of child nodes.

[0042] Attribute change event: Detects changes to specific attributes on a node, such as changes to the values ​​of attributes like class (class name) and style (style). These changes include, but are not limited to, adding, deleting, or modifying attributes.

[0043] Character data change events: Detect updates to the content of text nodes, such as updates to textContent or inner HTML.

[0044] Then, the configured Mutation Observer instance is attached to the root node of the webpage's DOM. When a change event occurs, the Mutation Observer's callback function is triggered. Within the callback function, by analyzing the change event, the corresponding DOM element can be identified as the second type of element to be processed.

[0045] By combining the global traversal detection during the initial loading phase with the dynamic DOM tree change detection during the runtime phase, the accessibility status detection of static elements and dynamically generated elements such as user interaction and script loading on the webpage is fully covered. This ensures that throughout the entire page lifecycle, regardless of how the content changes, all elements that do not meet accessibility standards can be captured in a timely and automatic manner and included in the processing flow. This provides continuous and real-time accessibility enhancement for complex single-page applications and dynamic interactive webpages.

[0046] In some embodiments, exemplarily illustrated, if there are multiple elements to be processed, the method further includes, before extracting the multi-dimensional accessibility features of the elements to be processed: First, the interactivity of each element to be processed is pre-judged to obtain the corresponding initial pre-judgment type. This initial pre-judgment type includes at least interactive and static content. The interactivity prediction is based on limited information that can be quickly and directly obtained from the elements to be processed. This is to achieve a low-cost, rough classification of interaction potential, rather than precise semantic recognition. The information dimensions used for the prediction include, but are not limited to: Structural attributes: Analyze the DOM tag names of the elements to be processed. For example, < / button> <button>、 (Anchor point / link) <input> Tags such as "etc." usually indicate interactive functions; while (paragraph), Tags such as "static content" tend to be used for content that is static.

[0047] Basic visual and layout information: The size and position of the element to be processed are compared with the preset knowledge base of common interactive areas (such as header navigation area, main form area, floating operation button area), and the elements to be processed located in these interactive areas are pre-judged as interactive.

[0048] Basic interactive hints: By calling the `window.getComputedStyle()` method (window.getComputedStyle method), the key CSS of the element to be processed can be quickly read. For example, the `cursor:pointer` style indicates that the element to be processed is a clickable interactive control.

[0049] Then, based on the initial predicted type of each element and its visibility within the current browser viewport, differentiated processing priorities are set for each element. Specifically: Set elements within the current browser viewport that are initially predicted to be interactive as the highest priority for immediate synchronous processing. For example, input fields that are currently focused are directly related to the user's immediate actions and must be processed synchronously immediately to ensure zero-latency accessibility.

[0050] Set elements that are currently within the browser viewport but are initially predicted to be static content to the second priority (high). For example, a piece of text being read needs to be processed quickly to ensure the continuity of user information retrieval, but its scheduling weight is clearly lower than that of first priority elements, so it does not preempt the processing of key interactive resources.

[0051] Elements that are located outside the current browser viewport but are initially predicted to be interactive are set to the third priority (medium). For example, a main button on the page that has not yet been scrolled to may soon come into view, so it is placed in the buffer processing queue for asynchronous processing to maintain its ready state.

[0052] Elements located outside the current browser viewport and initially predicted as static content are set to fourth priority (low). For example, footer information at the bottom of the page has the least impact on the immediate user experience. The system collects these elements in batches and schedules them to a background task pool managed by Service Workers for asynchronous batch processing during system idle periods.

[0053] The processing order for the four priority levels is: First priority > Second priority > Third priority > Fourth priority. Processing of higher priority elements can interrupt or preempt the processing resources of lower priority elements.

[0054] Using the above method, the interactivity of elements is predicted based on structural attributes, basic visual and interactive cues. Combined with the visibility of elements within the current viewport, a differentiated four-priority processing mechanism is constructed. This mechanism enables intelligent task scheduling and resource allocation for elements to be processed. It can prioritize the zero-latency response of accessibility enhancement for key interactive elements within the user's viewport, while asynchronously and efficiently processing non-critical or non-viewport elements. This significantly improves the overall response performance and resource utilization efficiency of the accessibility processing system in dynamic web page environments, and optimizes the real-time interactive experience for users using assistive technologies.

[0055] In some embodiments, it is illustrated, for example, that the target element type of the element to be processed in an accessibility scenario is determined based on multi-dimensional accessibility features, including but not limited to: First, the multi-dimensional accessible features are encoded using a pre-trained analysis model to obtain multi-dimensional encoded vectors. The analysis model can be any pre-model with strong semantic understanding and multimodal processing capabilities, such as large language models, deepseek models, or Transformer models; the specific model depends on the situation and is not limited here.

[0056] The model internally includes encoder subnetworks specifically designed for different modal features. Specifically, these include: The DOM semantic encoder is used to convert DOM structural features and semantic features into a first semantic vector reflecting structural semantics and a second semantic vector reflecting functional semantics, respectively; the visual feature encoder is used to convert visual features into visual semantic vectors; and the interaction pattern encoder is used to convert interaction pattern features into behavioral pattern vectors.

[0057] Then, the multi-dimensional encoding vectors are fused across modalities to obtain a unified semantic representation vector.

[0058] Specifically, the analysis model uses a cross-modal attention fusion module to deeply fuse the multi-dimensional encoding vectors obtained above. This module allows for interaction and attention calculation between feature vectors from different modalities.

[0059] For example, visual semantic vectors (such as icon shape and color) can enhance the understanding of the second semantic vector (functional inference), jointly reinforcing the "shopping cart button"; at the same time, behavioral pattern vectors (such as high-frequency clicks) can ensure the interactivity inferred from the visual semantic vector and the first semantic vector. Through this process, a unified semantic representation vector is generated, which is a comprehensive encoding of the overall accessibility semantics of the element to be processed.

[0060] Finally, by analyzing the classification output layer of the analysis model and based on the unified semantic representation vector, the candidate element types and corresponding confidence levels of the elements to be processed in the accessible access scenario are determined, and the candidate element type with the highest confidence level is determined as the target element type.

[0061] Specifically, the classification output layer calculates the probability that the element to be processed belongs to each candidate element type based on its knowledge learned from massive amounts of labeled data. These candidate element types are a predefined set of standard accessibility roles, such as buttons, navigation links, text input boxes, images, titles, list items, and form areas. Each output probability value is the confidence score of that candidate element type. The candidate element type with the highest confidence score is then determined as the target element type for the element to be processed in an accessibility scenario.

[0062] Using the above method, multi-dimensional accessibility features are encoded and fused across modalities based on a pre-trained analysis model to generate a unified semantic representation vector. Based on this vector, the probability of the element to be processed belonging to each standard accessibility role is accurately calculated. Finally, the role with the highest confidence is determined as the target element type. This achieves intelligent and high-precision reasoning and classification of accessibility semantics for complex elements, significantly improving the accuracy and robustness of role recognition for dynamic web page components.

[0063] Optionally, when the probability distribution output by the analysis model is too dispersed, i.e., the maximum confidence level is less than a preset threshold (such as less than a certain value within the range of 60% to 80%, the specific threshold depends on the situation and is not limited here), it indicates that the model's judgment on the current element to be processed has a high degree of uncertainty. In this case, the following strategies can be adopted: (1) Delayed decision and context waiting: Mark the element to be processed as to be observed and put it back into the medium or low priority processing queue. The system will wait and collect more context information, especially richer user interaction behavior data (such as long focus dwell time, specific mouse movement trajectory), and restart the analysis process in subsequent cycles using updated features; (2) Conservative attribute strategy: Temporarily do not inject specific roles, or only inject basic accessibility enhancement attributes based on DOM tags to avoid misinterpretation; (3) Feedback learning sample recording: Record these low-confidence samples and their corresponding multi-dimensional accessible features in their entirety, and store them as error samples in the error sample library. The error sample library can be used for model fine-tuning, thereby continuously improving the overall performance of the system.

[0064] By using the above methods, the confidence threshold is used as a decision reliability threshold. When the uncertainty of the model judgment is high, strategies such as delayed decision, conservative attributes, or recording feedback are automatically triggered. This effectively avoids forcibly injecting potentially erroneous ARIA attributes when there is insufficient evidence, and reduces the risk of false augmentation. At the same time, by accumulating low-confidence samples and using them for subsequent model optimization, the system's ability to identify complex boundary cases is continuously evolved, enhancing the robustness and adaptability of the entire barrier-free augmentation system.

[0065] In some embodiments, it is illustrated by way of example that corresponding accessibility enhancement attributes are generated based on the target element type and multi-dimensional accessibility features, including but not limited to: The ARIA decision maker first fuses and analyzes the target element type with multi-dimensional accessibility features to generate a structured comprehensive decision context. This comprehensive decision context encapsulates the key states of the element to be processed at the current moment and within the current page environment.

[0066] For example, for an element to be processed that is identified as a "button", its comprehensive decision context might include: Type: "Button"; Content Status: "Visible text label is empty" (derived through analysis of visual features or DOM text nodes); Interaction Status: "Recent click frequency is high" (derived from interaction pattern features); Visual Semantics: "Icon means shopping cart" (inferred from semantic features); Layout Relationship: "Located within the product list container" (combined with DOM structure features and visual layout analysis); Change Context (used to indicate whether the element to be processed is newly added or has changed attributes).

[0067] Then, the comprehensive decision context is matched with the preset attribute decision rule library; the rules in the attribute decision rule library define the state attributes or descriptive attributes that should be adapted for different element types and their associated context information.

[0068] For example, rule A: if the element type is "button", then adapt role="button".

[0069] Rule B: If the element type is "button", and the overall decision context indicates that "the visible text label is empty" and "the icon meaning is recognizable", then adapt role="button" + aria-label="icon meaning" (e.g., aria-label="shopping cart").

[0070] Finally, based on the matched rules, accessibility enhancement attributes corresponding to the elements to be processed are generated. This process follows a pre-defined decision logic: Based on the matched rules, determine whether the target element type needs a descriptive attribute. If so, add the corresponding descriptive attribute, such as aria-label or aria-describedby (described by...), and its attribute value is dynamically inferred from the comprehensive decision context. If not, skip it.

[0071] Based on the matched rules, determine whether the target element type requires a status attribute. If yes, set the corresponding status attribute, such as aria-expanded; otherwise, skip the step.

[0072] By integrating the intelligently inferred target element type with multi-dimensional accessibility features, a structured comprehensive decision context is constructed. Based on this context, it is accurately matched with a preset attribute decision rule library, thereby dynamically generating accessibility enhancement attributes that are highly adapted to the element type, content, state, and environment and are precise and necessary. This achieves a closed-loop intelligent decision-making process from role recognition to attribute configuration, effectively avoiding attribute mismatch, missing, or redundant attributes, and ensuring that the auxiliary technology can obtain accurate and real-time component semantic and state information.

[0073] Furthermore, the decision-maker further optimizes the descriptive and state attributes based on the comprehensive decision context to achieve more accurate semantic communication.

[0074] For example, for frequently clicked "button" elements, the decision-maker can trigger additional prompting mechanisms (such as adding temporary CSS classes in development mode or recording diagnostic logs) on top of injecting role="button" to enhance the salience of their interaction.

[0075] If the button is adjacent to a form, its purpose can be inferred from the aria-label of the adjacent form, and an associated label for the "button" element can be generated, such as aria-label="Submit [Order Form]", instead of an isolated label.

[0076] If the element to be processed is dynamically inserted asynchronously (determined based on the change context), the decision maker can additionally set its aria-live (real-time region attribute) to "polite" to politely notify the assistive technology that new content has appeared, ensuring the accessibility of dynamic updates.

[0077] By combining the above methods with the comprehensive decision-making context, such as the specific interaction frequency, spatial layout, and dynamic loading method of the elements to be processed, the descriptive attributes and state attributes are deeply optimized and adapted in a scenario-based manner. This enables more accurate and context-relevant semantic information transmission and intelligent response to dynamic content updates, thereby significantly improving the completeness, relevance, and real-time performance of accessibility information in complex interactive scenarios.

[0078] In some embodiments, it is exemplarily illustrated that accessibility enhancement attributes are injected into the document object model node corresponding to the element to be processed, including but not limited to: Retrieve the existing accessibility properties on the DOM node corresponding to the element to be processed, and determine whether there is a semantic conflict between the accessibility enhancement properties and the existing accessibility properties. The semantic conflicts are mainly divided into two categories: Direct conflicts, for example, if the DOM node corresponding to the element to be processed already has role="link", but the system is preparing to inject role="button" based on analysis, then it is determined to be a role conflict.

[0079] Semantic redundancy or contradictions require more complex semantic understanding. The system evaluates the semantic relationship between two attribute values ​​through a lightweight semantic similarity calculation model (e.g., based on word vectors or sentence encoders).

[0080] For example, the DOM node corresponding to the element to be processed already has aria-label="Close Sidebar", while the system-generated aria-label="Close Menu". The semantic similarity between the two is calculated. If it is greater than a preset similarity threshold (such as greater than a certain value in the range of 80% to 100%, the specific threshold depends on the situation and is not limited here), it is judged as a semantic redundancy conflict.

[0081] If the DOM node corresponding to the element to be processed already has aria-expanded="true", while the system-generated aria-expanded="false", the two have directly opposite semantics, then it is judged as a semantic contradiction.

[0082] If there is no semantic conflict, the accessibility enhancement attribute will be injected into the corresponding DOM node; if there is a semantic conflict, the attribute injection scheme will be determined according to the preset conflict resolution strategy.

[0083] For example, for direct conflicts, a confidence-first principle is adopted: compare the confidence level corresponding to the target element type with the source weight of the existing accessibility attribute (e.g., whether it was manually set by the developer; if so, it is a high-weight source; if not, it is a low-weight source). If the confidence level is greater than the target threshold (the specific threshold depends on the situation and is not limited here), and the existing accessibility attribute is a low-weight source, then the existing accessibility attribute is overwritten with an accessibility enhancement attribute, or a supplementary attribute, such as aria-describedby, is injected for semantic clarification; otherwise, the existing accessibility attribute is retained, and this conflict is recorded as an item awaiting manual review.

[0084] For semantic redundancy conflicts, among two semantically similar attributes, retain the attribute with more complete and accurate information (e.g., a more specific sidebar is better than a general menu), or merge the two after removing duplicates.

[0085] For semantic conflicts, the injection is temporarily abandoned and the element to be processed is added back to the processing queue; or it is marked as a high-priority exception and reported to the monitoring system for review by the developers.

[0086] By using the above method, semantic conflict detection is performed with existing accessibility attributes before attribute injection, and the attribute injection scheme is determined based on the preset conflict resolution strategy. This ensures that the final injected accessibility enhancement attributes are semantically consistent with existing attributes and are free of redundancy. It avoids the system misjudging and overwriting the correct attributes manually set by the developer, and also solves the contradiction problem between multiple source attributes. This significantly improves the accuracy and security of accessibility enhancement attribute injection, and ensures the stability and reliability of the final webpage accessibility state.

[0087] In some embodiments, exemplarily illustrated, after injecting accessibility enhancement attributes into the document object model node corresponding to the element to be processed, the method further includes: Access the interface through the browser's assistive technology to obtain the accessibility information of the document object model nodes after attribute injection.

[0088] Specifically, after the accessibility enhancement attributes are injected, the system immediately, or after a very short delay, obtains the accessibility information of the element to be processed in the current accessibility tree through the browser's accessibility tree testing API. This information is presented in the form of a set of core key-value pairs, mainly including: role; name: the injected descriptive attribute, which is the main identifier for assistive technology broadcasting; state: the injected state attribute, describing the dynamic interactive state of the element. These key-value pairs define how assistive technologies (such as screen readers, screen magnifiers, etc.) will access the element to be processed.

[0089] Then, the accessibility information is compared with the semantic information expected based on the target element type and multi-dimensional accessibility features. This semantic information directly corresponds to the core key-value pairs: the role in the semantic information corresponds to the role, the label in the semantic information corresponds to the name, and the state in the semantic information corresponds to the state. For example, for an element identified as a submit button that lacks visual text, its expected semantic information is {role: "button", label: submit}, which is represented in the accessibility tree as {role: "button", name: "submit"}.

[0090] If the comparison is inconsistent, a misreading is determined, indicating that the accessibility enhancement attribute injection did not achieve the expected effect. For example, the expected semantic information is {role: "button", name: "Submit"}, but the actual accessibility information obtained is {role: "img", name: ""}. In this case, the system immediately performs a rollback operation: removes the injected accessibility enhancement attribute and adds the element to be processed back to the processing queue.

[0091] By using the above method, the actual accessibility information of elements is obtained and compared in real time with the semantic information expected by the system, realizing direct verification and closed-loop feedback of accessibility enhancement effects. Once a misreading that does not match the expected information is detected, the system can immediately and automatically roll back the injected attributes and add the element back to the processing queue, thereby ensuring the accuracy and reliability of accessibility enhancement attribute modification, effectively preventing assistive technology users from obtaining misleading information due to the injection of incorrect attributes, and improving the self-correction capability of the entire enhancement process and the final output quality.

[0092] In addition, the true accessibility role of the element to be processed can be determined based on the verification results, and then bound to the multi-dimensional accessibility features that triggered this error enhancement to form an error sample with feature-true label pairing, which is then stored in the error sample library.

[0093] The system periodically initiates a model fine-tuning process (e.g., after accumulating N error samples, where N is a positive integer, or at fixed time intervals). This process uses the accumulated error sample library as new training data to fine-tune or incrementally train the analysis model. During training, the neuron connection weights of each layer within the model (such as the feature encoder, cross-modal fusion layer, and classification output layer) are dynamically updated using the backpropagation algorithm.

[0094] For example, the verification process for the aforementioned accessibility enhancement effect mainly includes: a screen reader simulating access to the enhanced element to be processed, generating a voice output log (the content of which originates from the role, name, and state in the aforementioned accessibility tree). The verification module receives and parses the log, comparing it with the expected semantic information. If a semantic deviation is found (i.e., the actual broadcast does not match the expectation), this deviation, along with the original multi-dimensional accessibility features, is packaged into an error sample. The analysis model receives the error sample and adjusts its internal parameters and updates its semantic understanding ability based on the error sample. The decision-maker then obtains more accurate semantic input from the optimized analysis model, thereby generating more accurate accessibility enhancement attributes in the future. This process is repeated cyclically, constituting a complete perception-decision-verification-learning self-optimization system.

[0095] By combining the false alarm cases discovered in the verification process with the corresponding multi-dimensional features, error samples are formed and used for the periodic fine-tuning of the model. This allows the entire system to continuously learn from the error feedback in real-world applications, dynamically optimize its internal semantic understanding and classification capabilities, thereby gradually reducing the misjudgment rate of similar interference features and continuously improving the accuracy of accessibility role determination and attribute generation. This forms a closed-loop optimization system with self-iterative and evolutionary capabilities.

[0096] It should be understood that, although Figure 1 The steps in the flowchart are shown sequentially as indicated by the arrows, but these steps are not necessarily executed in the order indicated by the arrows. Unless otherwise specified herein, there is no strict order in which these steps are executed, and they can be performed in other orders. Figure 1 At least some of the steps in the process may include multiple sub-steps or multiple stages. These sub-steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these sub-steps or stages is not necessarily sequential, but can be executed in turn or alternately with other steps or at least some of the sub-steps or stages of other steps.

[0097] In some embodiments, such as Figure 2 The diagram shown is an architectural representation of a web accessibility enhancement system provided in this application, comprising: a DOM detection module, a feature extraction module, an analysis model, a decision maker, an attribute injection module, and an effect verification module, wherein: The DOM detection module is used to obtain the elements to be processed in the webpage and transmit the elements to the feature extraction module; The feature extraction module is used to extract multi-dimensional accessible features of the elements to be processed, and when there are multiple elements to be processed, it sets differentiated processing priorities for each element based on the initial predicted type of each element and the visibility of each element in the current browser viewport. The analysis model is used to obtain the multi-dimensional accessibility features of the current element to be processed according to the processing priority, and based on the multi-dimensional accessibility features, determine the target element type of the current element to be processed in the accessibility scenario, and transmit the target element type and the multi-dimensional accessibility features to the decision maker. The decision-maker is used to generate corresponding accessibility enhancement attributes based on the target element type and multi-dimensional accessibility features, and then transmit the accessibility enhancement attributes to the attribute injection module. The attribute injection module is used to determine whether there is a semantic conflict between the accessibility enhancement attribute and the existing accessibility attribute on the DOM node corresponding to the element to be processed. If there is a semantic conflict, the attribute injection scheme is determined according to the preset conflict resolution strategy; if there is no semantic conflict, the accessibility enhancement attribute is injected into the DOM node. The effect verification module is used to obtain accessibility information of the DOM node after the accessibility enhancement attribute is injected through the accessibility technology access interface provided by the browser, and compare the accessibility information with the semantic information expected based on the target element type and the multi-dimensional accessibility feature; if the comparison is inconsistent, it is determined that the accessibility enhancement attribute injection has not achieved the expected effect, the accessibility enhancement attribute is removed, and the corresponding current element to be processed is added back to the processing queue.

[0098] For specific limitations regarding the web accessibility enhancement system, please refer to the limitations of the web accessibility enhancement methods mentioned above, which will not be repeated here. Each module in the aforementioned web accessibility enhancement system can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in or independent of the processor in a computer device, or stored in the memory of a computer device as software, so that the processor can call and execute the corresponding operations of each module.

[0099] In some embodiments, such as Figure 3 As shown, a webpage accessibility enhancement device provided in this application embodiment includes: an acquisition module 301, an extraction module 302, a determination module 303, a generation module 304, and an accessibility enhancement module 305, wherein: Module 301 is used to retrieve elements to be processed in a webpage; Extraction module 302 is used to extract multi-dimensional accessible features of the element to be processed; the multi-dimensional accessible features include at least two of the document object model structural features, visual features, interaction mode features and semantic features of the element to be processed; The determination module 303 is used to determine the target element type of the element to be processed in an accessibility scenario based on multi-dimensional accessibility features; The generation module 304 is used to generate corresponding accessibility enhancement attributes based on the target element type and multi-dimensional accessibility features; the accessibility enhancement attributes include at least one of role attributes, status attributes, and description attributes for assisting access. Accessibility enhancement module 305 is used to inject accessibility enhancement attributes into the document object model node corresponding to the element to be processed, so that assistive technologies can access the element to be processed based on the accessibility enhancement attributes.

[0100] For specific limitations regarding web accessibility enhancement devices, please refer to the limitations of web accessibility enhancement methods described above, which will not be repeated here. Each module in the aforementioned web accessibility enhancement device can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in or independent of the processor in a computer device in hardware form, or stored in the memory of a computer device in software form, so that the processor can call and execute the operations corresponding to each module.

[0101] In some embodiments, a computer device is provided, which may be a server, and its internal structure diagram may be as shown below. Figure 4 As shown, the computer device includes a processor, memory, network interface, and database connected via a system bus. The processor provides computing and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system, computer programs, and database. The internal memory provides an environment for the operation of the operating system and computer programs in the non-volatile storage media. The database stores web accessibility enhancement data. The network interface communicates with external terminals via a network. When the computer program is executed by the processor, it implements a web accessibility enhancement method. The display screen can be an LCD screen or an e-ink screen. The input device can be a touch layer covering the display screen, buttons, a trackball, or a touchpad on the computer device casing, or an external keyboard, touchpad, or mouse.

[0102] Those skilled in the art will understand that Figure 4 The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the computer device to which the present application is applied. Specific computer devices may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.

[0103] In some embodiments, a computer device is provided, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to perform the following steps: Retrieve the elements to be processed from the webpage; Extract multi-dimensional accessible features of the element to be processed; the multi-dimensional accessible features include at least two of the following: document object model structural features, visual features, interaction mode features, and semantic features of the element to be processed; Based on multi-dimensional accessibility features, the target element type of the element to be processed in an accessible access scenario is determined. Based on the target element type and multi-dimensional accessibility features, corresponding accessibility enhancement attributes are generated; the accessibility enhancement attributes include at least one of the following: role attributes, status attributes, and description attributes used to assist access. Inject accessibility enhancement attributes into the document object model node corresponding to the element to be processed, so that assistive technologies can access the element to be processed based on the accessibility enhancement attributes.

[0104] In some embodiments, when the processor executes a computer program, it further performs the following steps: By traversing the document object model tree of the webpage, elements that do not meet the preset accessibility standards are identified as the first type of elements to be processed. Detect change events in the document object model tree and, in response to these events, identify the changed elements as the second type of elements to be processed.

[0105] In some embodiments, when the processor executes a computer program, it further performs the following steps: If there are multiple elements to be processed, the interactivity of each element to be processed is predicted to obtain the corresponding initial prediction type. Based on the initial predicted type of each element to be processed and its visibility within the current browser viewport, set differentiated processing priorities for each element to be processed.

[0106] In some embodiments, when the processor executes a computer program, it further performs the following steps: The multi-dimensional accessible features are encoded separately to obtain multi-dimensional encoded vectors; Multi-dimensional encoding vectors are fused across modalities to obtain a unified semantic representation vector; Based on a unified semantic representation vector, the type of each candidate element and its corresponding confidence level are determined for the element to be processed in an accessible access scenario. The candidate element type with the highest confidence level is determined as the target element type.

[0107] In some embodiments, when the processor executes a computer program, it further performs the following steps: A comprehensive decision context is generated based on the target element type and multi-dimensional accessibility features. The comprehensive decision context is matched with the preset attribute decision rule library; the rules in the attribute decision rule library define the state attributes or descriptive attributes that should be adapted for different element types and their associated context information. Based on the matched rules, generate accessibility enhancement attributes.

[0108] In some embodiments, when the processor executes a computer program, it further performs the following steps: Retrieve existing accessibility properties on a document object model node; Determine whether there is a semantic conflict between accessibility enhancement attributes and existing accessibility attributes; If semantic conflicts exist, the attribute injection scheme is determined according to the preset conflict resolution strategy; If there is no semantic conflict, the accessibility enhancement attribute will be injected into the document object model node.

[0109] In some embodiments, when the processor executes a computer program, it further performs the following steps: Obtain accessibility information for the document object model nodes after attribute injection; The accessibility information is compared with the semantic information expected based on the target element type and multi-dimensional accessibility features; If the comparison is inconsistent, it is determined that the accessibility enhancement attribute injection has not achieved the expected effect, the accessibility enhancement attribute is removed, and the corresponding pending element is added back to the pending queue.

[0110] In some embodiments, a computer-readable storage medium is provided having a computer program stored thereon, which, when executed by a processor, performs the following steps: Retrieve the elements to be processed from the webpage; Extract multi-dimensional accessible features of the element to be processed; the multi-dimensional accessible features include at least two of the following: document object model structural features, visual features, interaction mode features, and semantic features of the element to be processed; Based on multi-dimensional accessibility features, the target element type of the element to be processed in an accessible access scenario is determined. Based on the target element type and multi-dimensional accessibility features, corresponding accessibility enhancement attributes are generated; the accessibility enhancement attributes include at least one of the following: role attributes, status attributes, and description attributes used to assist access. Inject accessibility enhancement attributes into the document object model node corresponding to the element to be processed, so that assistive technologies can access the element to be processed based on the accessibility enhancement attributes.

[0111] In some embodiments, when a computer program is executed by a processor, it further performs the following steps: By traversing the document object model tree of the webpage, elements that do not meet the preset accessibility standards are identified as the first type of elements to be processed. Detect change events in the document object model tree and, in response to these events, identify the changed elements as the second type of elements to be processed.

[0112] In some embodiments, when a computer program is executed by a processor, it further performs the following steps: If there are multiple elements to be processed, the interactivity of each element to be processed is predicted to obtain the corresponding initial prediction type. Based on the initial predicted type of each element to be processed and its visibility within the current browser viewport, set differentiated processing priorities for each element to be processed.

[0113] In some embodiments, when a computer program is executed by a processor, it further performs the following steps: The multi-dimensional accessible features are encoded separately to obtain multi-dimensional encoded vectors; Multi-dimensional encoding vectors are fused across modalities to obtain a unified semantic representation vector; Based on a unified semantic representation vector, the type of each candidate element and its corresponding confidence level are determined for the element to be processed in an accessible access scenario. The candidate element type with the highest confidence level is determined as the target element type.

[0114] In some embodiments, when a computer program is executed by a processor, it further performs the following steps: A comprehensive decision context is generated based on the target element type and multi-dimensional accessibility features. The comprehensive decision context is matched with the preset attribute decision rule library; the rules in the attribute decision rule library define the state attributes or descriptive attributes that should be adapted for different element types and their associated context information. Based on the matched rules, generate accessibility enhancement attributes.

[0115] In some embodiments, when a computer program is executed by a processor, it further performs the following steps: Retrieve existing accessibility properties on a document object model node; Determine whether there is a semantic conflict between accessibility enhancement attributes and existing accessibility attributes; If semantic conflicts exist, the attribute injection scheme is determined according to the preset conflict resolution strategy; If there is no semantic conflict, the accessibility enhancement attribute will be injected into the document object model node.

[0116] In some embodiments, when a computer program is executed by a processor, it further performs the following steps: Obtain accessibility information for the document object model nodes after attribute injection; The accessibility information is compared with the semantic information expected based on the target element type and multi-dimensional accessibility features; If the comparison is inconsistent, it is determined that the accessibility enhancement attribute injection has not achieved the expected effect, the accessibility enhancement attribute is removed, and the corresponding pending element is added back to the pending queue.

[0117] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium. When executed, the computer program can include the processes of the embodiments of the above methods. Any references to memory, storage, databases, or other media used in the embodiments provided in this application can include non-volatile and / or volatile memory. Non-volatile memory may include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), or flash memory. Volatile memory may include random access memory (RAM) or external cache memory. By way of illustration and not limitation, RAM is available in a variety of forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), dual data rate SDRAM (DDRSDRAM), enhanced SDRAM (ESDRAM), synchronous link DRAM (SLDRAM), RAMbus direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and memory bus dynamic RAM (RDRAM), etc.

[0118] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0119] The embodiments described above are merely illustrative of several implementation methods of this application, and while the descriptions are relatively specific and detailed, they should not be construed as limiting the scope of the invention patent. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these all fall within the protection scope of this application. Therefore, the protection scope of this patent application should be determined by the appended claims. < / button>

Claims

1. A method for web accessibility enhancement, the method comprising: The method includes: Retrieve the elements to be processed from the webpage; Extract the multi-dimensional accessibility features of the element to be processed; the multi-dimensional accessibility features include at least two of the document object model structural features, visual features, interaction mode features and semantic features of the element to be processed; Based on the multi-dimensional accessibility features, the target element type of the element to be processed in the accessibility scenario is determined; Based on the target element type and the multi-dimensional accessibility features, corresponding accessibility enhancement attributes are generated; the accessibility enhancement attributes include at least one of role attributes, status attributes, and descriptive attributes used to assist access. The accessibility enhancement attributes are injected into the document object model node corresponding to the element to be processed, so that assistive technologies can access the element to be processed based on the accessibility enhancement attributes.

2. The method according to claim 1, characterized in that, The process of obtaining the elements to be processed in the webpage includes: By traversing the document object model tree of the webpage, elements that do not meet the preset accessibility standards are identified as the first type of elements to be processed. Detect change events in the document object model tree, and in response to the change events, determine the changed elements as the second type of elements to be processed.

3. The method according to claim 2, characterized in that, If there are multiple elements to be processed, then before extracting the multi-dimensional accessibility features of the elements to be processed, the process further includes: Perform an interactiveness prediction on each of the elements to be processed to obtain the corresponding initial prediction type; Based on the initial predicted type of each element to be processed and the visibility of each element to be processed within the current browser viewport, a differentiated processing priority is set for each element to be processed.

4. The method according to claim 1, characterized in that, The step of determining the target element type of the element to be processed in an accessibility scenario based on the multi-dimensional accessibility features includes: The multi-dimensional accessible features are encoded separately to obtain multi-dimensional encoded vectors; The multi-dimensional encoding vectors are fused across modalities to obtain a unified semantic representation vector; Based on the unified semantic representation vector, the candidate element types and corresponding confidence levels of the element to be processed in the accessible access scenario are determined. The candidate element type with the highest confidence level is determined as the target element type.

5. The method according to claim 1, characterized in that, The step of generating corresponding accessibility enhancement attributes based on the target element type and the multi-dimensional accessibility features includes: Based on the target element type and the multi-dimensional accessibility features, a comprehensive decision context is generated. The comprehensive decision context is matched with a preset attribute decision rule base; the rules in the attribute decision rule base define the state attributes or descriptive attributes that should be adapted for different element types and their associated context information. The accessibility enhancement attributes are generated based on the matched rules.

6. The method according to claim 1, characterized in that, The step of injecting the accessibility enhancement attributes into the document object model node corresponding to the element to be processed includes: Obtain the existing accessibility attributes on the document object model node; Determine whether there is a semantic conflict between the accessibility enhancement attribute and the existing accessibility attribute; If semantic conflicts exist, the attribute injection scheme is determined according to the preset conflict resolution strategy; If there is no semantic conflict, the accessibility enhancement attribute is injected into the document object model node.

7. The method according to claim 1, characterized in that, After injecting the accessibility enhancement attributes into the document object model node corresponding to the element to be processed, the method further includes: Obtain the accessibility information corresponding to the document object model nodes after attribute injection; The accessibility information is compared with the semantic information expected based on the target element type and the multi-dimensional accessibility features; If the comparison is inconsistent, it is determined that the accessibility enhancement attribute injection has not achieved the expected effect, the accessibility enhancement attribute is removed, and the corresponding element to be processed is added back to the processing queue.

8. A webpage accessibility enhancement device, characterized in that, The device includes: The acquisition module is used to retrieve elements to be processed from a webpage. An extraction module is used to extract multi-dimensional accessible features of the element to be processed; the multi-dimensional accessible features include at least two of the document object model structural features, visual features, interaction mode features and semantic features of the element to be processed; The determination module is used to determine the target element type of the element to be processed in an accessibility scenario based on the multi-dimensional accessibility features. The generation module is used to generate corresponding accessibility enhancement attributes based on the target element type and the multi-dimensional accessibility features; the accessibility enhancement attributes include at least one of role attributes, status attributes, and description attributes for assisting access. An accessibility enhancement module is used to inject the accessibility enhancement attributes into the document object model node corresponding to the element to be processed, so that assistive technologies can access the element to be processed based on the accessibility enhancement attributes.

9. A computer device, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements the method of any one of claims 1 to 7.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the method of any one of claims 1 to 7.

Images