Barrier-free node element parsing method and device, equipment and storage medium

Abstract

This invention discloses a method, apparatus, device, and storage medium for parsing accessible node elements, belonging to the field of computer technology. The invention generates an accessible DOM tree by traversing the node elements in the source DOM tree in response to state change events. In response to user click events, it obtains the node attributes of the target accessible node element in the accessible DOM tree corresponding to the user click event. Based on these node attributes, it parses the target accessible node element. This allows for automatic parsing of the corresponding node elements and subsequent output of the accessibility implementation status after developers modify the document object model node elements on the target page for accessibility. This eliminates the need for developers to self-test via mobile devices or learn related gesture operations, thus improving the efficiency of accessibility feature development.

Description

Technical Field

[0001] This invention relates to the field of computer technology, and in particular to a method, apparatus, device, and storage medium for parsing barrier-free node elements. Background Technology

[0002] Currently, most common website accessibility features focus on the user experience, providing screen reading and gesture controls to help visually impaired people perceive website content. However, there is still a lack of solutions on how to help developers technically implement accessibility features and related solutions and apply them to the accessibility development process of websites.

[0003] Developers face numerous challenges that impact development efficiency when developing and self-testing accessibility features. For instance, self-testing requires familiarity with various gestures in accessibility mode and manual testing of each element to identify areas for improvement and issues, which can easily lead to omissions. Furthermore, development self-testing relies heavily on manual operation, placing a high demand on human resources. In addition to the PC used for development, mobile devices are also required for self-testing, further increasing reliance on mobile devices. Moreover, recognizing large blocks of text requires waiting for voice screen reading to complete before assessing the accuracy of text recognition. These issues significantly reduce the efficiency of accessibility feature development.

[0004] The above content is only used to help understand the technical solution of the present invention and does not represent an admission that the above content is prior art. Summary of the Invention

[0005] The main objective of this invention is to provide a method, apparatus, device, and storage medium for parsing accessible node elements, aiming to automatically parse the accessible content of accessible nodes, assist developers in quickly testing the implementation of accessible functions, and improve the efficiency of accessible function development.

[0006] To achieve the above objectives, the present invention provides a method, apparatus, device, and storage medium for parsing barrier-free node elements, comprising:

[0007] In response to state change events of the source Document Object Model (DOM) tree, an accessible DOM tree is generated after traversing the node elements in the source DOM tree.

[0008] In response to a user click event, obtain the node attributes of the target accessible node element in the accessible DOM tree that corresponds to the user click event;

[0009] The target accessibility node element is parsed based on the node attributes.

[0010] Optionally, the step of generating an accessible DOM tree after traversing the node elements in the source DOM tree in response to a state change event of the source Document Object Model (DOM) tree further includes:

[0011] The target page is nested into the front-end service interface using a floating frame, and the target page includes node elements of the source document object model (DOM) tree;

[0012] Establish a listener for state change events of the DOM tree using a change observer.

[0013] Optionally, the step of generating an accessible DOM tree after traversing the node elements in the source DOM tree in response to a state change event of the source Document Object Model (DOM) tree includes:

[0014] In response to state change events in the source Document Object Model (DOM) tree, traverse the node elements in the source DOM tree;

[0015] Convert node elements that meet the preset conditions into accessible node elements;

[0016] An accessible DOM tree is generated based on the accessible node elements, and the accessible node elements of the accessible DOM tree are displayed on the target page.

[0017] Optionally, the step of converting node elements that meet preset conditions into accessible node elements includes:

[0018] Traverse the node elements in the DOM tree. If the node element is accessible and recognizable, determine whether the node element is a text node element.

[0019] If the node element is a text node element, then replace the label of the node element with a custom node element and add custom attributes to generate an accessibility node element;

[0020] If the node element is not a text node element, then add custom attributes to the node element to generate an accessibility node element.

[0021] Optionally, before traversing the node elements in the DOM tree, the method further includes: disconnecting the state change listener for the source DOM tree; after the step of generating an accessible DOM tree after traversing the node elements in the source DOM tree in response to the state change event of the source Document Object Model (DOM) tree, the method further includes the following steps:

[0022] Re-establish the listener for state change events of the DOM tree by using a change observer;

[0023] A visual accessible DOM tree is generated based on the accessible DOM tree and displayed on the front-end service interface;

[0024] An accessibility report is generated based on the accessibility DOM tree.

[0025] Optionally, the node attributes of the target accessible node element include accessibility attributes, custom attributes, and location attributes, and the step of parsing the target accessible node element based on the node attributes includes:

[0026] Based on the positional attributes of the target accessibility node element, the target accessibility node element in the target page is selected using a floating box;

[0027] The accessibility content of the accessibility node element is parsed based on the accessibility attributes and custom attributes.

[0028] Optionally, the step of parsing the accessibility content of the accessibility node element based on the accessibility attributes and custom attributes includes:

[0029] The text content of the accessibility node element is obtained by parsing the attribute values ​​of the accessibility attributes.

[0030] The custom content of the accessibility node element is obtained by parsing the attribute values ​​of the custom attributes.

[0031] The accessibility attributes and custom attributes are matched with preset accessibility reading rules;

[0032] Based on the matching results, the accessibility attributes, custom attributes, text content, and custom content are prioritized and concatenated to obtain the accessibility content of the accessibility node element.

[0033] Furthermore, to achieve the above objectives, the present invention also provides an accessibility node element parsing device, the accessibility node element parsing device comprising:

[0034] The generation module is used to generate an accessible DOM tree by traversing the node elements in the DOM tree in response to state change events of the Document Object Model (DOM) tree.

[0035] The acquisition module is used to acquire the node attributes of the target accessible node element in the accessible DOM tree corresponding to the user click event in response to the user click event;

[0036] The parsing module is used to parse the target accessibility node element based on the node attributes.

[0037] In addition, to achieve the above objectives, the present invention also provides an accessibility node element parsing device, the device comprising: a memory, a processor, and an accessibility node element parsing program stored in the memory and executable on the processor, the accessibility node element parsing program being configured to implement the steps of the accessibility node element parsing method as described above.

[0038] In addition, to achieve the above objectives, the present invention also provides a storage medium storing an accessibility node element parsing program, wherein the accessibility node element parsing program, when executed by a processor, implements the steps of the accessibility node element parsing method as described above.

[0039] The present invention proposes an accessibility node element parsing method, apparatus, device, and storage medium. By responding to state change events in the source Document Object Model (DOM) tree, it traverses the node elements in the source DOM tree to generate an accessibility DOM tree. Responding to user click events, it obtains the node attributes of the target accessibility node element in the accessibility DOM tree corresponding to the user click event. Based on these node attributes, it parses the target accessibility node element. This allows for automatic parsing of the corresponding node elements and subsequent output of accessibility implementation status after developers modify the document object model node elements on the target page for accessibility purposes. Developers are not required to self-test via mobile devices or learn related gesture operations, thus improving the efficiency of accessibility feature development. Attached Figure Description

[0040] Figure 1 This is a schematic diagram of the structure of the barrier-free node element parsing device in the hardware operating environment involved in the embodiments of the present invention;

[0041] Figure 2 This is a flowchart illustrating the first embodiment of the barrier-free node element parsing method of the present invention;

[0042] Figure 3 This is a schematic diagram illustrating the overall architecture and interaction flow of various embodiments of the barrier-free node element parsing method of the present invention;

[0043] Figure 4 This is a schematic diagram illustrating the process of classifying the accessibility and recognizability levels of node elements in the accessibility node element parsing method of the present invention.

[0044] Figure 5 This is a flowchart illustrating the third embodiment of the barrier-free node element parsing method of the present invention;

[0045] Figure 6 A flowchart illustrating the process of finding adjacent accessible node elements in the method for parsing accessible node elements;

[0046] Figure 7This is a flowchart illustrating the third embodiment of the barrier-free node element parsing method of the present invention;

[0047] Figure 8 This is a schematic diagram of the functional modules of the barrier-free node element parsing device of the present invention.

[0048] The realization of the objective, functional features and advantages of the present invention will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

[0049] It should be understood that the specific embodiments described herein are merely illustrative of this application and are not intended to limit this application.

[0050] The main solution of this application embodiment is: to monitor the state of the document object model tree in the target webpage developed by the developer; when the developer performs accessibility development, the nodes in the document object model tree are modified for accessibility, which triggers a state change event of the document object model tree; after detecting the occurrence of this event, the system traverses each node of the document object model tree to convert the nodes that have been modified for accessibility into accessible nodes and generates an accessibility tree based on these accessible nodes; after the developer clicks on a node in the visual accessibility tree corresponding to the accessibility tree on the front-end service interface, the system will automatically select the corresponding accessibility node in the target page according to the selected node and parse the accessibility function implementation of the node.

[0051] This application's embodiments take into account that currently common mobile accessibility features focus on the user experience, namely providing screen reading and gesture controls to help visually impaired individuals perceive web page content. There are currently no known examples of applying accessibility features and solutions to the accessible development process of web pages. If developers use the built-in accessibility features of mobile devices to assist in accessibility development and self-testing, the following problems may arise:

[0052] The current mobile accessibility gesture operation is relatively complex. After enabling accessibility mode, the original gesture interaction will be completely changed. When developers use it for self-testing, they need to learn before they can become familiar with the various gesture operations in accessibility mode, which is time-consuming and prone to misoperation.

[0053] Existing mobile accessibility features cannot provide an inspection of the accessibility implementation of the target page. Developers cannot directly and quickly discover areas for improvement and problems in the accessibility implementation of the target page. They must manually test each element on the page, which is prone to omissions and leads to low efficiency in accessibility development self-testing.

[0054] Existing mobile accessibility features cannot provide prompts for problems during the accessibility recognition process; instead, they simply read out the incorrect content. Developers need to rely on their experience to repeatedly adjust and test the system to find and correct errors, which places high demands on their experience and proficiency.

[0055] Developing and testing using existing mobile accessibility features requires manual operation by developers, which is highly dependent on manpower. In addition to the PC used for development, mobile devices are also required for self-testing, which also makes them highly dependent on mobile devices. When recognizing large blocks of text on mobile devices in accessibility mode, developers need to wait for the voice screen reading to be completed before they can judge the accuracy of the recognition, which is time-consuming. These problems all reduce the development efficiency of developers when developing accessibility features to varying degrees.

[0056] Based on this, this application proposes a solution that generates an accessible DOM tree by traversing the node elements in the source DOM tree in response to state change events. In response to user click events, it obtains the node attributes of the target accessible node element in the accessible DOM tree corresponding to the user click event, and parses the target accessible node element based on the node attributes. This automatically parses the corresponding node elements and outputs the accessibility implementation status after the developer performs accessibility modifications on the document object model node elements in the target page, avoiding the need for developers to self-test on mobile devices and learn related gesture operations, thus improving the efficiency of accessibility function development.

[0057] Specifically, refer to Figure 1 , Figure 1 This is a schematic diagram of the functional modules of the terminal device to which the accessible node element parsing device of this application belongs. The accessible node element parsing device can be a data processing device independent of the terminal device, and it can be carried on the terminal device in the form of hardware or software.

[0058] In this embodiment, the terminal device to which the barrier-free node element parsing device belongs includes at least an output module 110, a processor 120, a memory 130, and a communication module 140.

[0059] The memory 130 stores the operating system and the accessibility node element parsing program. The accessibility node element parsing device can store information such as the detected finger gestures on a preset area at the edge of the touchscreen screen, and the acquired gesture state parameters on the preset area at the edge of the touchscreen screen, in the memory 130. The output module 110 can be a display screen, speaker, etc. The communication module 140 can include a WIFI module, a mobile communication module, and a Bluetooth module, etc., and communicates with external devices or servers through the communication module 140.

[0060] When the barrier-free node element parsing program in memory 130 is executed by the processor, it performs the following steps:

[0061] In response to state change events in the source Document Object Model (DOM) tree, an accessible DOM tree is generated after traversing the node elements in the DOM tree.

[0062] In response to a user click event, obtain the node attributes of the target accessible node element in the accessible DOM tree that corresponds to the user click event;

[0063] The target accessibility node element is parsed based on the node attributes.

[0064] Furthermore, when the barrier-free node element parsing program in memory 130 is executed by the processor, it also performs the following steps:

[0065] The target page is nested into the front-end service interface using a floating frame, and the target page includes node elements of the Document Object Model (DOM) tree;

[0066] Establish a listener for state change events of the DOM tree using a change observer.

[0067] Furthermore, when the barrier-free node element parsing program in memory 130 is executed by the processor, it also performs the following steps:

[0068] In response to state change events in the source Document Object Model (DOM) tree, traverse the node elements in the source DOM tree;

[0069] Convert node elements that meet the preset conditions into accessible node elements;

[0070] An accessible DOM tree is generated based on the accessible node elements, and the accessible node elements of the accessible DOM tree are displayed on the target page.

[0071] Furthermore, when the barrier-free node element parsing program in memory 130 is executed by the processor, it also performs the following steps:

[0072] Traverse the node elements in the DOM tree. If the node element is accessible and recognizable, determine whether the node element is a text node element.

[0073] If the node element is a text node element, then replace the label of the node element with a custom node element and add custom attributes to generate an accessibility node element;

[0074] If the node element is not a text node element, then add custom attributes to the node element to generate an accessibility node element.

[0075] Furthermore, when the barrier-free node element parsing program in memory 130 is executed by the processor, it also performs the following steps:

[0076] Re-establish event listeners for the DOM tree using a change observer;

[0077] A visual accessible DOM tree is generated based on the accessible DOM tree and displayed on the front-end service interface;

[0078] An accessibility report is generated based on the accessibility DOM tree.

[0079] Furthermore, when the barrier-free node element parsing program in memory 130 is executed by the processor, it also performs the following steps:

[0080] Based on the positional attributes of the target accessibility node element, the target accessibility node element in the target page is selected using a floating box;

[0081] The accessibility content of the accessibility node element is parsed based on the accessibility attributes and custom attributes.

[0082] Furthermore, when the barrier-free node element parsing program in memory 130 is executed by the processor, it also performs the following steps:

[0083] The text content of the accessibility node element is obtained by parsing the attribute values ​​of the accessibility attributes.

[0084] The custom content of the accessibility node element is obtained by parsing the attribute values ​​of the custom attributes.

[0085] The accessibility attributes and custom attributes are matched with preset accessibility reading rules;

[0086] Based on the matching results, the accessibility attributes, custom attributes, text content, and custom content are prioritized and concatenated to obtain the accessibility content of the accessibility node element.

[0087] This embodiment, through the above-described scheme, specifically generates an accessible DOM tree by traversing the node elements in the DOM tree in response to state change events of the Document Object Model (DOM). In response to user click events, it obtains the node attributes of the target accessible node element in the accessible DOM tree corresponding to the user click event, and parses the target accessible node element based on the node attributes. Thus, after the developer performs accessibility modifications on the DOM node elements in the target page, the corresponding node elements are automatically parsed and the accessibility implementation status is subsequently output. This avoids developers having to self-test on mobile devices and learn related gesture operations, improving the efficiency of accessibility function development.

[0088] Based on, but not limited to, the terminal device architecture described above, this application proposes method embodiments.

[0089] First, the background upon which the embodiments of the present application are based is presented. With the advancement of accessibility and age-friendly transformation and the implementation of related requirements, the importance of web accessibility functions is becoming increasingly prominent. However, a serious problem currently faced by web accessibility developers is the high development cost of adapting to accessibility modes. Developers urgently need to improve the development efficiency of accessibility development while ensuring the correct implementation and accurate identification of accessibility functions. At the same time, they need to find ways to reduce the difficulty and requirements of self-testing accessibility function development, thereby reducing the development cost of accessibility functions. However, there is currently no mature product to serve developers, help them develop, self-test, and improve the efficiency of web accessibility functions.

[0090] Currently, most accessibility features on the market are designed for the user experience, aiming to provide accessibility for visually impaired individuals. However, this solution focuses on the development process, serving developers of web accessibility features. It efficiently assists developers in identifying risks and improving code for accessibility features on web pages. Its unique starting point and perspective make it unique, and no similar products have been found on the market yet.

[0091] The embodiments of this solution support dynamic analysis and risk identification of web page accessibility functions, perform efficient dynamic analysis and real-time processing of pages, and output analysis results in real time through various forms such as accessibility DOM trees and summary reports. This helps developers analyze the effectiveness of web page accessibility functions and more easily and promptly identify problems in the accessibility experience of pages.

[0092] It can also achieve mobile accessibility simulation without physical devices, and can simulate mobile accessibility recognition in a PC browser. This allows developers to complete the entire process of webpage accessibility development, debugging, and self-testing via PC, eliminating the dependence on physical devices for mobile accessibility development and self-testing, and improving resource utilization efficiency.

[0093] In addition, it includes support for automated quick preview and retrospective of accessibility effects. This solution supports adjustable-rate automatic accessibility simulation and historical content retrospective, which can automatically simulate the page access process in accessibility mode and output the accessible accessibility content in text form, making it convenient for developers to quickly preview the accessibility effect of page nodes, and can retrospectively and reproduce the browsing history.

[0094] This application proposes a method for parsing accessibility node elements. Specifically, it is a solution that can be performed on a PC webpage via a browser to simulate mobile webpage accessibility recognition and check the coverage and accuracy of accessibility function implementation. By simplifying accessibility operations, parsing page content, checking page elements, simulating mobile accessibility recognition, and providing development suggestions, it helps developers in accessibility development, saves developers' development time, reduces developers' learning and operation costs, improves the automation and coverage of accessibility development self-testing, and improves developers' efficiency in developing accessibility functions.

[0095] Reference Figure 2 , Figure 2 This is a flowchart illustrating the first embodiment of the accessibility node element parsing method of the present invention. In this embodiment, the accessibility node element parsing method includes:

[0096] Step S2000: In response to the state change event of the source document object model (DOM) tree, generate an accessible DOM tree by traversing the node elements in the source DOM tree;

[0097] Specifically, this application and solution are mainly applied to the field of accessibility mode development for web page content. Accessibility mode for web pages refers to ensuring that users can access and use web page content regardless of whether they have physical, sensory, or cognitive impairments by adopting specific design and development methods. Currently, most common devices that support accessibility mode for web pages are mobile terminal devices, such as the VoiceOver function of the iOS system and the Talkback screen reading function of the Android system. For web page developers, this is mainly achieved by adjusting the structure and tags of the HTML web page, adding HTML attributes, and using CSS and JavaScript to improve the accessibility and accessibility of the page.

[0098] Specifically, the implementation of this solution mainly includes two parts: JavaScript scripts embedded in the target page and a web front-end service providing the user interface. The target page refers to the webpage for which accessibility functionality needs to be developed. Figure 3 , Figure 3 This demonstrates the main functions of the JS script and the web front-end service, as well as their interaction with the target page. This solution uses an iframe to nest the target page in the web front-end service to achieve real-time preview of the page in accessibility mode.

[0099] like Figure 3As shown, the solution in this implementation mainly involves three objects: a web front-end service, a JavaScript script, and a target page. Specifically, for the web front-end service and the target page, a bidirectional communication channel is established between the user interface (web front-end service) and the target page. A two-way listening method (postMessage + onMessage) is used for asynchronous communication between the user interface and the target page. Request dispatching and response listening methods are set in both the front-end service and the page script for unified communication request management, resolving the cross-domain request issue of floating frames (iframes). Furthermore, to ensure the security of message transmission between the web front-end service and the target page, when the JavaScript script is launched on the target page, the target domain of postMessage can be restricted. This ensures that only the domain deployed through the web front-end service can listen to the message queue content, preventing the leakage of page content and data.

[0100] In addition, an automatic startup interaction layer is designed between the Web front-end service and the JS script to ensure that the initialization process of the imported JS script will only be started when the Web front-end service is accessed. That is, the initialization command will be automatically issued after the Web front-end service has finished loading the target page. Correspondingly, the JS script will only start the initialization process after receiving the command, which further improves the data security during the page interaction process.

[0101] In this embodiment, a JavaScript script is used to listen for changes in the source Document Object Model (DOM) tree of the target HTML webpage. When the state of the source DOM tree of the target webpage changes, for example, when the developer performs accessibility modifications on a node element of the DOM tree, i.e., a component element in the front-end webpage (such as a button, text box, or image container), a state change event of the DOM tree will be triggered. After sensing the event, the JavaScript script in this solution will respond accordingly, traverse all nodes in the DOM tree, find the node elements that meet the accessibility node selection criteria, perform accessibility modifications, and generate an accessibility DOM tree based on the modified node elements.

[0102] Step S3000: In response to a user click event, obtain the node attributes of the target accessible node element in the accessible DOM tree that corresponds to the user click event;

[0103] Specifically, when a user modifies the accessibility of node elements on the target page, the JavaScript MutationObserver detects the change, traverses the DOM tree on the target page, and generates an accessibility DOM tree. After the accessibility DOM tree is generated, the user (developer) can click to select a specific accessibility node element in the accessibility DOM tree of the target page, thereby obtaining accessibility-related information for that node element.

[0104] More specifically, when the user completes the click, a user click event is triggered. At this time, the JS script responds to the user click event and obtains the attribute information of the accessibility node clicked by the user.

[0105] Specifically, the attribute information of accessible node elements includes a series of attributes that indicate the specific details of the accessible node, such as its label (name), type (role), and content. For example, the label of the navigation bar node element on the target page is... <nav>The type is navigation. Because it has been transformed into an accessibility node, its tags can also be recognized as semantic HTML tags. <nav>It is identified as "xxx navigation icon content", and similar tags are also included. <header>Identified as "xxx banner logo content", <footer>Identified as "xxx footer icon content" <button>Recognized as "xxx button" It is identified as "xxx link", etc.

[0106] In addition, during the process of converting regular node elements into accessibility node elements, the `tabindex` attribute is added to certain node elements to enable them to receive focus. For example, normally only `a` tags, `button` tags, and `input` tags can receive focus, while other elements, such as... 、 Tags like `` cannot gain focus using the tab key, but by adding the `tabindex` attribute to the tag attributes, they can gain focus. A node element gains focus, for example:

[0107] <div tabindex＝"0"> This is the div that can get focus.

[0108] By adding the `tabindex` attribute, you can control the tab navigation order based on the value, from smallest to largest. This allows you to control the overall page browsing order. However, considering that the default tab navigation order is consistent with the tab order, disrupting this order can cause incompatibility issues with some auxiliary tools and browsers that are not compatible with `tabindex`. Generally, it's recommended to use 0 to specify the `tabindex` attribute. More specifically, the `tabindex` value typically has three states:

[0109] When tabindex=0, the element that can gain focus will be traversed in the normal order, without any difference in order.

[0110] When tabindex > 0, after iterating through the elements with tabindex = "0", it iterates through the elements with tabindex equal to 1, equal to 2, and so on.

[0111] When tabindex is -1, using the tab key will not give focus to this element, but focus can be gained through JavaScript.

[0112] The type of a node element can be represented by its role property. For example, common types and their role properties include: button, link, checkbox, radio button, etc. The role property is set mainly to allow users to perceive the type of UI component of the current node element.

[0113] It also includes aria-* series attributes and rules for enhancing the accessibility of node elements on the target page.

[0114] Among them, node visibility is determined based on the degree to which each node supports accessibility recognition, combined with an analysis of its impact on relevant attributes. Node identifiability is divided into several levels, as referenced... Figure 4 The recognition levels and corresponding determination methods are as follows: Level 1: The current node fully supports accessibility recognition; Level 2: The current node supports accessibility recognition, but there are risks associated with it; Level 3: The current node does not support accessibility recognition at all; Level 4: Because it is not visible on the page, the current node will not be focused in accessibility mode; Level 5: Because the tabindex attribute is -1, the current node will not be focused in accessibility mode; Level 6: Because it is affected by the aria-hidden attribute, the current node will not be focused in accessibility mode; Level 7: Because the role attribute of the parent node is valid, the current node will not be accessed individually in accessibility mode. The conditions for determining whether a node element is visible are: if the display attribute of the node element obtained by the getComputedStyle() method is not none, the visibility attribute of the node element obtained by the getComputedStyle() method is not hidden, and the width and height attributes of the node obtained by node.getBoundingClientRect() are both not 0, then the node element is considered visible.

[0115] By obtaining these attribute information of the clicked accessibility node element, detailed information such as the accessibility support of the accessibility node element, the specific implementation of the accessibility function, and the accessibility content of the node can be obtained. This provides a foundation for generating and outputting accessibility reports based on this information for developers' reference.

[0116] Step S4000: Parse the target barrier-free node element based on the node attributes.

[0117] Specifically, after a user clicks, the JavaScript script obtains the attribute information of the accessibility node element corresponding to the click event, including the node element's type, content, name, recognizability, and other information. Based on this information, the details of the accessibility node corresponding to the click event can be further analyzed.

[0118] For example, if a node element is an image, then the node element's... Tags may include an alt attribute. By parsing the content of the alt attribute of a node, the content description information of the image can be obtained. For example, the image may describe a landscape painting. By parsing the alt attribute, the description of the image may be "an image of wheat fields in the wind". If the image node element does not have an alt attribute, its content will only be recognized as "image". However, in this case, visually impaired users will not be able to understand its actual meaning at all.

[0119] In this embodiment, an accessible DOM tree is generated by traversing the node elements in the source DOM tree in response to state change events. In response to user click events, the node attributes of the target accessible node element in the accessible DOM tree corresponding to the user click event are obtained. The target accessible node element is parsed based on the node attributes. Thus, after the developer modifies the document object model node elements in the target page for accessibility, the corresponding node elements are automatically parsed and the accessibility implementation is output. This avoids the need for developers to self-test on mobile devices and learn related gesture operations, improving the efficiency of accessibility function development.

[0120] Furthermore, referring to Figure 5 , Figure 5 This is a flowchart illustrating the second embodiment of the barrier-free node element parsing method of the present invention, based on the above. Figure 2 In the illustrated embodiment, step S2000: before generating the accessible DOM tree after traversing the node elements in the source DOM tree in response to a state change event of the source document object model (DOM) tree, may include:

[0121] Step S1010: The target page is nested into the front-end service interface through a floating frame, wherein the target page includes node elements of the Document Object Model (DOM) tree;

[0122] Step S1020: Establish a listener for state change events of the DOM tree through a change observer.

[0123] Specifically, a floating frame refers to an iframe, short for "Inline Frame," which is used to nest another independent webpage or document within a webpage. In other words, it creates a frame containing a child webpage within a webpage. In this embodiment, the target page is nested into the web front-end service interface through an iframe, allowing for real-time preview of the target page on the front-end service interface.

[0124] MutationObserver is an API introduced through JavaScript to monitor changes in the source DOM tree. MutationObserver can be used to detect and respond to events such as the addition, deletion, and attribute changes of DOM elements in a webpage in real time, thereby achieving more efficient and accurate DOM manipulation.

[0125] Furthermore, step S2000 in this embodiment: generating an accessible DOM tree after traversing the node elements in the source DOM tree in response to the state change event of the source document object model (DOM) tree may include:

[0126] Step S2010: In response to the state change event of the source document object model (DOM) tree, traverse the node elements in the DOM tree;

[0127] When users (developers) perform accessibility development on node elements in the target page, such as adding, deleting, or modifying the content of accessibility node elements, the state change event of the source DOM tree will be triggered. At this time, the change observer will disconnect from listening to the state change event of the source DOM tree and switch to the accessibility conversion process of the DOM tree.

[0128] Step S2020: Convert node elements that meet the preset conditions into accessible node elements;

[0129] Specifically, the accessibility conversion process of the DOM tree mainly involves converting node elements that meet preset conditions into accessible node elements. This is achieved by traversing all node elements in the source DOM tree and then replacing the node element tags and adding custom attributes to the node elements that meet the accessibility conversion conditions, thereby converting them into accessible node elements.

[0130] This allows you to simultaneously perform tag replacement and custom attribute addition on a node, or you can choose to perform tag replacement or custom attribute addition on a single node element. The specific choice should be made based on the relevant information of different nodes, such as node type.

[0131] Step S2030: Generate an accessibility DOM tree based on the accessibility node elements and display the accessibility node elements of the accessibility DOM tree on the target page.

[0132] Specifically, after the accessibility DOM tree is generated, all accessibility node elements of the accessibility DOM tree are displayed on the target page so that users (developers) can preview the development status of the accessibility nodes in real time, including whether the accessibility nodes have been successfully generated and whether the generated accessibility nodes meet expectations.

[0133] Furthermore, step S2020 in this embodiment: converting node elements that meet preset conditions into accessible node elements may include:

[0134] Step S2021: Traverse the node elements in the source DOM tree. If the node element has accessibility and recognizability, determine whether the node element is a text node element.

[0135] Step S2022: If the node element is a text node element, then replace the label of the node element with a custom node element and add custom attributes;

[0136] Step S2023: If the node element is not a text node element, then add a custom attribute to the node element.

[0137] Specifically, in this embodiment, after the developer modifies, adds, or deletes the source DOM tree or accessibility DOM tree in the target page, thereby triggering the state change event of the source DOM tree, the DOM tree transformation process begins. The nodes in the source DOM tree are traversed, and the node elements that meet the conditions are converted into accessibility node elements. Taking depth-first traversal as an example, the body node is used as the initial node for traversal. During the traversal, node elements that will not be rendered, such as those with tags such as style, script, and noscript, as well as meaningless node elements with tags such as #comment, are skipped.

[0138] Then, the identifiability of the current node in accessibility mode is determined. The determination of the identifiability of the node in accessibility mode can refer to the first embodiment described above. Figure 4 The method for determining the identifiability level shown determines that the current node is identifiable in accessibility mode, and then performs label replacement and / or custom attribute addition to transform the current node into an accessibility node.

[0139] Specifically, if a node is determined to be identifiable as a text node, the #text node is processed by replacing its tag with a custom tag. <a11y>< / a11y> Create a node and set the content of that custom tag node to the value of the #text node's nodeValue property.

[0140] Then add the data-a11y-index attribute to the current node (or the text node after the custom label replacement in the above steps), and use the custom dataSet method to number and record the current node.

[0141] After the current node is processed, check whether the current node contains child nodes. If it does, continue to check and transform each child node of the current node. If the current node has no child nodes, return the Element object of the current node to generate the corresponding accessibility node element.

[0142] After the traversal is complete, an unobstructed tree is generated, and the observe method of the MutationObserver object is called again to add listeners.

[0143] More specifically, refer to Figure 6 , Figure 6 The method for finding adjacent accessible nodes in this solution can be used when it is necessary to check whether a certain node has adjacent accessible nodes during the traversal process. First, check whether the parent node of the current node is the body node. If not, check whether the current node can find an adjacent node. If an adjacent node is found, this adjacent node is taken as the current node. Check whether the current node supports accessibility recognition. If it does, return the node. If it does not, continue to check the child nodes of the node.

[0144] In this embodiment, the target page is nested into the front-end service interface using a floating frame, and an event listener for the DOM tree is established through a change observer. After the developer triggers the relevant events, an accessible DOM tree is generated and displayed, and listeners are re-added to the DOM tree. When generating the accessible DOM tree, custom tags and / or custom attributes are added to the node elements to convert them into accessible nodes. In this way, developers can obtain the results of accessibility development in real time after development, which facilitates subsequent troubleshooting of function implementation or further implementation of accessibility functions, thus improving the development efficiency of accessibility development.

[0145] Furthermore, referring to Figure 7 , Figure 7 This is a flowchart illustrating the third embodiment of the barrier-free node element parsing method of the present invention, based on the above. Figure 5 In the illustrated embodiment, before traversing the node elements in the DOM tree in step S2000, the method further includes: disconnecting the state change listener for the source DOM tree. Step S2000: after generating an accessible DOM tree in response to the state change event of the Document Object Model (DOM) tree, after traversing the node elements in the DOM tree, the method may include:

[0146] Step S2040: Re-establish the listener for state change events of the DOM tree through the change observer;

[0147] Step S2050: Generate a visual accessible DOM tree based on the accessible DOM tree and display it on the front-end service interface;

[0148] Step S2060: Generate an accessibility report based on the accessibility DOM tree.

[0149] Specifically, after detecting a change in the state of the source DOM tree, the monitoring of the source DOM tree is disconnected and the process of converting the accessibility tree is switched to the process of generating the accessibility DOM tree. The DOM tree is then traversed to generate the accessibility DOM tree. After the accessibility tree is generated, the state change event listener of the DOM tree is re-established through the change observer, so that when the user triggers the state change of the DOM tree again, a new accessibility DOM tree can be generated in response.

[0150] To enable developers to more intuitively observe the results of accessibility development and various accessibility node elements, the generated accessibility tree is visualized and displayed in the web front-end service interface. The visualized accessibility node elements are then bound to the accessibility node elements on the target page. When a developer clicks on a visualized accessibility element node in the web front-end service interface, the corresponding accessibility element node on the target page will also be selected.

[0151] After the accessibility DOM tree is generated, it is automatically traversed to collect relevant indicator data of accessibility nodes, such as the number of accessibility node types, the total number of accessibility nodes of a certain type, and the number of accessibility nodes, and an accessibility report is generated and returned to the web front-end service.

[0152] Furthermore, step S4000 in this embodiment: parsing the target accessibility node element based on the node attributes may include:

[0153] Step S4010: Based on the position attribute of the target accessibility node element, select the target accessibility node element in the target page using a floating box;

[0154] Step S4020: Parse the accessibility content of the accessibility node element based on the accessibility attributes and custom attributes.

[0155] Specifically, in this embodiment, the node element in the target page can be located using the node.getBoundingClientRect() method. This method can obtain the position attributes (top, left, width, height) of the node. When the developer clicks on an accessible node element in the target page, the JS script will obtain the position attribute of the currently selected node on the target page and send it to the front-end service. After receiving the position attribute, the front-end service will render a selection box on the upper layer of the floating frame iframe according to the position attribute, thereby realizing the selection of the currently selected target accessible node element.

[0156] Because the selection box is separate from the target page in the iframe, the selection box has no requirements on the layout or style of the target page, has good compatibility, and will not affect the DOM structure of the target page. If the selected node element is outside the current visible screen, the JS script will automatically slide the target page to the position where the target node element is visible, thereby ensuring that the currently selected node appears in the most appropriate position.

[0157] After selecting the target accessibility element node on the target page using the selection box, the backend will automatically parse the accessibility content of the node element based on its relevant attributes (custom attributes and accessibility attributes).

[0158] Furthermore, step S4020 in this embodiment: parsing the accessibility content of the accessibility node element based on the accessibility attributes and custom attributes may include:

[0159] Step S4021: Based on the attribute values ​​of the accessibility attributes, the text content of the accessibility node element is obtained;

[0160] Step S4022: Based on the attribute values ​​of the custom attributes, obtain the custom content of the accessibility node element;

[0161] Step S4023: Match the accessibility attributes and custom attributes with the preset accessibility reading rules;

[0162] Step S4024: Based on the matching result, prioritize and concatenate the accessibility attributes, custom attributes, text content, and custom content to obtain the accessibility content of the accessibility node element.

[0163] Specifically, in this embodiment, the accessibility content parsing of nodes mainly includes the following three parts of processing: first, parsing the accessibility reading rules, obtaining the role attribute, aria-series attributes, and its tag attribute and content attribute from the custom attributes of the current node element, and then prioritizing and concatenating the above attributes according to the actual reading rules in the accessibility mode of the test machine.

[0164] Secondly, node attribute parsing filters the attributes of the current node element to identify those that will provide additional on-screen text in accessibility mode. If both the original attribute (e.g., disabled) and its corresponding accessibility-specific attribute (e.g., aria-disabled) exist, the accessibility-specific attribute takes precedence. The filtered attributes are then parsed based on their values ​​to construct the corresponding accessibility recognition content. Furthermore, separate compatibility handling is implemented for some special attributes, such as the alt attribute of the img tag and the checkeded attribute of the input tag with type checkbox / radio.

[0165] Next is the parsing of node text content. The selection of node text content depends on the node type. The values ​​of the value, placeholder, and innerText properties are selected for parsing in sequence. Characters that may be ambiguous, such as "-" which may be a minus sign or a hyphen, and "--" which has no semantic meaning and is not read, are checked separately. When a potentially ambiguous character is detected, the special character check table is called to find the target character corresponding to the character and to obtain the meaning and reading processing information of the character that is pre-stored in the special character check table.

[0166] Through the above three parts of analysis, the label, meaning, content, and other information of a target accessible element node are parsed into text form, conforming to preset reading rules. For example, a node element with accessible recognizability is a button. < / button> <button>The button means "search confirmation button" and the text label content is "search". By parsing the label attribute and role attribute of the node element, we can see that in accessibility mode it will be interpreted as "This is a search confirmation button". By checking whether this parsed information is fluent and meets expectations, developers can intuitively find out whether the relevant settings of the accessibility node are successful.

[0167] In this embodiment, an event listener for the DOM tree is established through a change observer. A visualized accessibility DOM tree is generated based on the accessibility DOM tree and displayed on the front-end service interface. An accessibility report is generated based on the accessibility DOM tree. The accessibility content of the accessibility node elements is parsed based on the accessibility attributes and custom attributes. Through the above methods, the transformed accessibility tree is visualized and displayed on the web front-end service interface, and a report on detailed accessibility data of the accessibility node elements is generated. In particular, by parsing the accessibility content of the accessibility nodes, developers can quickly and effectively locate problems in accessibility development and accurately pinpoint problem nodes, thereby improving the efficiency of accessibility development.

[0168] In addition, refer to Figure 8 This invention also provides an accessibility node element parsing device 80, the device comprising:

[0169] Generation module 81 is used to generate an accessible DOM tree after traversing the node elements in the DOM tree in response to the state change event of the Document Object Model (DOM) tree.

[0170] The acquisition module 82 is used to acquire the node attributes of the target accessible node element in the accessible DOM tree corresponding to the user click event in response to the user click event;

[0171] The parsing module 83 is used to parse the target accessibility node element based on the node attributes.

[0172] Furthermore, embodiments of the present invention also provide an accessibility node element parsing device, the device comprising: a memory, a processor, and an accessibility node element parsing program stored in the memory and executable on the processor, the accessibility node element parsing program being configured to implement the steps of the various embodiments of the accessibility node element parsing method described above.

[0173] Furthermore, the present invention also provides a computer-readable storage medium storing an accessibility node element parsing program, which, when executed by a processor, implements the steps of the various embodiments of the accessibility node element parsing method described above.

[0174] In the embodiments of the apparatus, terminal device, and computer-readable storage medium of the present invention, all the technical features of the above-described embodiments of the barrier-free node element parsing method are included. The extended and explanatory content of the specification is basically the same as that of the above-described embodiments of the barrier-free node element parsing method, and will not be repeated here.

[0175] It should be noted that, in this document, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or system that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or system. Unless otherwise specified, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or system that includes that element.

[0176] The sequence numbers of the above embodiments of the present invention are for descriptive purposes only and do not represent the superiority or inferiority of the embodiments.

[0177] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods of the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of the present invention, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk) as described above, and includes several instructions to cause a terminal device (which may be a mobile phone, computer, server, or network device, etc.) to execute the methods described in the various embodiments of the present invention.

[0178] The above are merely preferred embodiments of the present invention and do not limit the scope of the patent. Any equivalent structural or procedural transformations made based on the description and drawings of the present invention, or direct or indirect applications in other related technical fields, are similarly included within the scope of patent protection of the present invention.< / button> < / footer> < / header> < / nav> < / nav>

Claims

1. A method for parsing barrier-free node elements, characterized in that, The method includes the following steps: In response to state change events in the source DOM tree, an accessible DOM tree is generated after traversing the node elements in the source DOM tree. In response to a user click event, the node attributes of the target accessible node element in the accessible DOM tree corresponding to the user click event are obtained, wherein the node attributes of the target accessible node element include accessibility attributes, custom attributes, and position attributes; The target accessibility node element is parsed based on the node attributes; The text content of the accessibility node element is obtained by parsing the attribute values ​​of the accessibility attributes. The custom content of the accessibility node element is obtained by parsing the attribute values ​​of the custom attributes. The accessibility attributes and custom attributes are matched with preset accessibility reading rules; Based on the matching results, the accessibility attributes, custom attributes, text content, and custom content are prioritized and concatenated to obtain the accessibility content of the accessibility node element.

2. The barrier-free node element parsing method as described in claim 1, characterized in that, Before the step of generating an accessible DOM tree after traversing the node elements in the source DOM tree in response to a state change event of the source DOM tree, the following is also included: The target page is nested into the front-end service interface using a floating frame, and the target page includes node elements of the source DOM tree; Establish a listener for state change events of the source DOM tree using a change observer.

3. The barrier-free node element parsing method as described in claim 2, characterized in that, The step of generating an accessible DOM tree by traversing the node elements in the source DOM tree in response to a state change event of the source DOM tree includes: In response to state change events in the source DOM tree, traverse the node elements in the source DOM tree; Convert node elements that meet the preset conditions into accessible node elements; An accessible DOM tree is generated based on the accessible node elements, and the accessible node elements of the accessible DOM tree are displayed on the target page.

4. The barrier-free node element parsing method as described in claim 3, characterized in that, The step of converting node elements that meet preset conditions into accessible node elements includes: If the node element has accessibility and recognizability, then determine whether the node element is a text node element; If the node element is a text node element, then replace the label of the node element with a custom node element and add custom attributes to generate an accessibility node element; If the node element is not a text node element, then add custom attributes to the node element to generate an accessibility node element.

5. The barrier-free node element parsing method as described in claim 3, characterized in that, Before traversing the node elements in the source DOM tree, the method further includes: disconnecting the state change listener for the source DOM tree; after generating the barrier-free DOM tree in response to the state change event of the source DOM tree, the method further includes: Re-establish the listener for state change events of the source DOM tree by using a change observer; A visual accessible DOM tree is generated based on the accessible DOM tree and displayed on the front-end service interface; An accessibility report is generated based on the accessibility DOM tree.

6. The barrier-free node element parsing method as described in claim 3, characterized in that, The step of parsing the target accessibility node element based on the node attributes includes: Based on the positional attributes of the target accessibility node element, the target accessibility node element in the target page is selected using a floating box; The accessibility content of the accessibility node element is parsed based on the accessibility attributes and custom attributes.

7. A barrier-free node element parsing device, characterized in that, The device includes: The generation module is used to generate an accessible DOM tree by traversing the node elements in the source DOM tree in response to state change events of the source DOM tree. The acquisition module is used to respond to a user click event and acquire the node attributes of the target accessible node element in the accessible DOM tree corresponding to the user click event, wherein the node attributes of the target accessible node element include accessibility attributes, custom attributes, and position attributes. The parsing module is used to parse the target accessibility node element based on the node attributes; The parsing module is also used to parse the text content of the accessibility node element based on the attribute value of the accessibility attribute; The custom content of the accessibility node element is obtained by parsing the attribute values ​​of the custom attributes. The accessibility attributes and custom attributes are matched with preset accessibility reading rules; Based on the matching results, the accessibility attributes, custom attributes, text content, and custom content are prioritized and concatenated to obtain the accessibility content of the accessibility node element.

8. A barrier-free node element parsing device, characterized in that, The device includes: a memory, a processor, and an accessibility node element parsing program stored in the memory and executable on the processor, the accessibility node element parsing program being configured to implement the steps of the accessibility node element parsing method as described in any one of claims 1 to 6.

9. A storage medium, characterized in that, The storage medium stores an accessibility node element parsing program, which, when executed by a processor, implements the steps of the accessibility node element parsing method as described in any one of claims 1 to 6.

Images