A web page accessibility detection method based on a browser plug-in

Abstract

An accessibility detection method based on a browser plug-in comprises the following steps: first, the total number of pages to be detected is set, a crawler thread is started on a server, and a browser plug-in crawler task is constructed; second, the browser plug-in establishes a short-term communication channel with a client, requests a URL to be detected from the server, adds a tab page in a specified window, concurrently accesses the specified link page within the maximum value of the set number of web pages, and obtains the source code; third, the obtained web page source code is subjected to source code level accessibility detection according to a pre-set accessibility item and rule set, and a detection result is obtained. The present application can be applied to automatic detection of website page accessibility, can effectively avoid anti-crawling strategies of some web pages, realizes source code level accessibility detection under a cross-local area network, improves detection efficiency through concurrent control, and helps developers to carry out accessibility improvement.

Description

Technical fields:

[0001] This invention belongs to the field of information accessibility and relates to a webpage accessibility detection method based on browser plugins, which is particularly applicable to source code-level accessibility detection of webpages in cross-local area network scenarios. Background technology:

[0002] With the rapid development of internet technology, there are now numerous types of web pages, and information storage is electronic, information dissemination is networked, information acquisition is technologically advanced, and information presentation is multimedia-based. However, due to the limitations of early technology, some web pages did not adequately consider user experience during design and development, and are insufficient in terms of user needs and the comprehensiveness of the target audience. Support for people with disabilities is inadequate, and people with disabilities and other special groups face various human-made barriers brought about by technological innovation when accessing information.

[0003] At the same time, due to the development of digitalization and the deepening of information difficulties faced by people with disabilities, the needs of people with disabilities and the development of the times have gradually shown some irreconcilable contradictions: on the one hand, there is the rapidly developing Internet technology, and on the other hand, there are people with disabilities who have limited ways of using the Internet and have difficulty operating it.

[0004] In recent years, the government has successively introduced relevant laws and policies to actively promote the development of website accessibility services. Website designers also have relevant accessibility design standards to follow, but the final degree of compliance with these standards still requires a professional website accessibility assessment to provide a reliable evaluation. This assessment helps identify shortcomings in the website and assists developers in making accessibility modifications. Accessibility testing is a crucial part of accessibility development. Effective accessibility testing helps developers promptly identify parts of the design that hinder users from accessing information and urges them to optimize functionality. Currently, existing accessibility testing processes often encounter situations where the system cannot efficiently and accurately obtain the webpage source code due to the website's settings. Summary of the Invention:

[0005] This invention overcomes the aforementioned shortcomings of existing technologies by proposing a browser plugin-based webpage accessibility detection method, enabling cross-LAN, concurrent webpage accessibility detection. Compared to server-side webpage crawling for accessibility detection, this invention effectively circumvents diverse anti-crawling verification techniques and has higher versatility. Using this method, webpage data resources can be acquired more efficiently, and webpages can be further tested to determine whether they conform to accessibility design standards, thereby assessing the usability and user-friendliness of the webpage under test.

[0006] A webpage accessibility detection method based on browser plugins, characterized by comprising the following steps:

[0007] S1: The server obtains the homepage links of the websites to be tested and the total number of websites to be tested (totalCount) from the user input, and adds the homepage links of the websites to be tested to the URL queue (urlQueue), where the URL queue (urlQueue) is defined as: urlQueue = [url1, url2, ..., url...]. i ];

[0008] S2: The server starts the crawler thread, builds the browser plugin crawler task, and waits for the crawler to return the results;

[0009] S211: The server allocates a URL and a unique identifier taskId from the head of the URL queue urlQueue in step S1 according to the list order and packages it into a browser plugin task. The task T is defined as: T = {taskId, url}, and the finishedCount value of the visited links is incremented by 1.

[0010] S212: The server adds task T from step S211 to the task queue taskQueue, where the task queue taskQueue is defined as: taskQueue = [T1, T2, ..., T i ];

[0011] S213: The server constructs a hash table (hashMap) to monitor task information. The hash table (hashMap) is defined as: hashMap = [(taskId1, T1), (taskId2, T2), ..., (taskId...]. i ,T i [), where taskId is the unique identifier of the task, and T is the corresponding waiting task;

[0012] S3: Browser plugins create a crawler environment and define crawler-related configurations;

[0013] S31: Browser plugins establish a short-term channel between content scripts and browser extension pages to monitor the status of web pages and send and receive messages;

[0014] S32: Browser plugins set cross-domain access permissions, supporting access to web pages under any declared domain;

[0015] S33: The browser plugin creates a new window W, where the id value of window W is defined as winId, the number of tab pages under window W is defined as tabCount, and the maximum concurrent crawling value of the page is set to WINDOW_MAX_NUM.

[0016] S4: The browser plugin requests a task T to be detected from the server and obtains the webpage source code S of the page to be detected;

[0017] S41: The browser plugin requests a task T to be tested from the server;

[0018] S42: The server moves the task T to be assigned in step S41 from the task queue defined in step S212 to the listening table hashMap defined in step S213 and waits for the crawler to return the result.

[0019] S43: After the browser plugin obtains the URL of task T in step S41, it opens the browser tab and accesses the URL, concurrently obtaining the webpage source code S at the page level.

[0020] S431: The browser plugin obtains the cookie information stored on the current client and the URL to be detected.

[0021] S432: If tabCount ≤ WINDOW_MAX_NUM, the browser plugin adds a new tab page under window W based on winId in step S33 and URL in step S43 to crawl the current URL to be detected, and the current tab count is incremented by 1; if tabCount > WINDOW_MAX_NUM, wait for the crawling of the currently opened tab page to end until tabCount ≤ WINDOW_MAX_NUM.

[0022] S433: Based on the tabId of the page in step S432, the browser plugin injects a script into the page to be detected through content-scripts, and obtains the serialized HTML fragment outerHTML of the document element object (including its descendants) of the page, which is the source code S to be detected.

[0023] S434: The browser plugin closes the currently crawled tab page, and the current tab count is decremented by 1;

[0024] S5: Perform source code-level accessibility testing based on the source code S obtained in step S4;

[0025] S51: Obtain the accessibility items to be detected and the rule set R = [r1, r2, r3, ..., r] from user input. i ];

[0026] S52: Apply the rule set R selected in step S51 to the source code S obtained in step S4 to perform accessibility testing, and determine whether the current webpage conforms to the corresponding item r in the standard "GB / T 37668-2019 Information Technology Internet Content Accessibility Technical Requirements and Test Methods".i Defined technical requirements;

[0027] S6: The browser plugin obtains the detection result set P generated in step S5, where P = [N s N t N f N i ], N s N represents the number of rules. t N represents the number of rules that passed the detection. f N represents the number of rules that failed the detection. i The number of rules for which the detection result is unknown;

[0028] S7: The browser plugin uploads the webpage source code S obtained in step S4 and the detection result set P obtained in step S6, along with the current task's unique identifier taskId, to the server.

[0029] S8: The server uses the unique task identifier taskId obtained in step S7 to find the corresponding waiting result T and returns it to the waiting thread;

[0030] S9: The server obtains a set of sub-links L from the webpage source code S, where the set of sub-links L is defined as: L = [url1, url2, ..., url...]. i And add L to the URL queue urlQueue;

[0031] S10: The server adds the detection result set P obtained in step S7 to the detection result;

[0032] S11: If the Task queue taskQueue is empty or a sufficient number of connections have been obtained (finishCount ≥ totalCount), the process ends; otherwise, repeat step S2.

[0033] In summary, this invention establishes an accessibility detection method based on browser plugins, which has the following beneficial effects:

[0034] (1) It has universality. By utilizing the browser plugin communication mechanism, it can efficiently circumvent anti-crawler strategies on web pages and provide data information for subsequent accessibility testing. (2) It has high efficiency. Through structural design, it can concurrently test a large number of web pages to be tested, improving the overall accessibility testing efficiency of the website. (3) It realizes cross-text file, multi-window, and cross-domain message passing, expanding the available testing scenarios. Attached image description:

[0035] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0036] Figure 1 This is the overall flowchart of the browser plugin-based accessibility detection method provided by the present invention;

[0037] Figure 2 This is a flowchart of the process of a browser plugin crawling the source code of a webpage to be tested, which is part of the overall flowchart of the browser plugin-based accessibility detection method provided by this invention. Specific implementation methods:

[0038] Exemplary embodiments of the present disclosure will now be described in more detail with reference to the accompanying drawings. While exemplary embodiments of the present disclosure are shown in the drawings, it should be understood that the present disclosure may be implemented in various forms and should not be limited to the embodiments set forth herein. Rather, these embodiments are provided so that this disclosure will be thorough and complete, and will fully convey the scope of the disclosure to those skilled in the art.

[0039] This example uses the detection of a webpage as an example. A webpage accessibility detection method based on a browser plugin includes the following specific steps:

[0040] S1: The server obtains the homepage links of the websites to be tested and the total number of websites to be tested (totalCount) from the user input, and adds the homepage links of the websites to be tested to the URL queue (urlQueue), where the URL queue (urlQueue) is defined as: urlQueue = [url1, url2, ..., url...]. i ];

[0041] S2: The server starts the crawler thread, builds the browser plugin crawler task, and waits for the crawler to return the results;

[0042] S211: The server allocates a URL and a unique identifier taskId from the head of the URL queue urlQueue in step S1 according to the list order and packages it into a browser plugin task. The task T is defined as: T = {taskId, url}, and the finishedCount value of the visited links is incremented by 1.

[0043] S212: The server adds task T from step S211 to the task queue taskQueue, where the task queue taskQueue is defined as: taskQueue = [T1, T2, ..., Ti ];

[0044] S213: The server constructs a hash table (hashMap) to monitor task information. The hash table (hashMap) is defined as: hashMap = [(taskId1, T1), (taskId2, T2), ..., (taskId...]. i ,T i [), where taskId is the unique identifier of the task, and T is the corresponding waiting task;

[0045] S3: Browser plugins create a crawler environment and define crawler-related configurations;

[0046] S31: Browser plugins establish a short-term channel between content scripts and browser extension pages to monitor the status of web pages and send and receive messages;

[0047] S32: Browser plugins set cross-domain access permissions, supporting access to web pages under any declared domain;

[0048] S33: The browser plugin creates a new window W, where the id value of window W is defined as winId, the number of tab pages under window W is defined as tabCount, and the maximum concurrent crawling value of the page is set to WINDOW_MAX_NUM.

[0049] S4: The browser plugin requests a task T to be detected from the server and obtains the webpage source code S of the page to be detected;

[0050] S41: The browser plugin requests a task T to be tested from the server;

[0051] S42: The server moves the task T to be assigned in step S41 from the task queue defined in step S212 to the listening table hashMap defined in step S213 and waits for the crawler to return the result.

[0052] S43: After the browser plugin obtains the URL of task T in step S41, it opens the browser tab and accesses the URL, concurrently obtaining the webpage source code S at the page level.

[0053] S431: The browser plugin obtains the cookie information stored in the current client and the URL to be detected;

[0054] S432: If tabCount ≤ WINDOW_MAX_NUM, the browser plugin adds a new tab page under window W based on winId in step S33 and URL in step S43 to crawl the current URL to be detected, and the current tab count is incremented by 1; if tabCount > WINDOW_MAX_NUM, wait for the crawling of the currently opened tab page to end until tabCount ≤ WINDOW_MAX_NUM.

[0055] S433: Based on the tabId of the page in step S432, the browser plugin injects a script into the page to be detected through content-scripts, and obtains the serialized HTML fragment outerHTML of the document element object (including its descendants) of the page, which is the source code S to be detected.

[0056] S434: The browser plugin closes the currently crawled tab page, and the current tab count is decremented by 1;

[0057] Figure 1 This is the overall flowchart of the browser plugin-based accessibility detection method provided by the present invention.

[0058] Figure 2 This is a flowchart of the floating window position detection process in the overall flowchart of the computer vision-based floating window closing detection algorithm for web pages provided by this invention.

[0059] S5: Perform source code-level accessibility testing based on the source code S obtained in step S4;

[0060] S51: Obtain the accessibility items to be detected and the rule set R = [r1, r2, r3, ..., r] from user input. i ];

[0061] S52: Apply the rule set R selected in step S51 to the source code S obtained in step S4 to perform accessibility testing, and determine whether the current webpage conforms to the corresponding item r in the standard "GB / T 37668-2019 Information Technology Internet Content Accessibility Technical Requirements and Test Methods". i Defined technical requirements;

[0062] S6: The browser plugin obtains the detection result set P generated in step S5, where P = [N s N t N f N i ], N s N represents the number of rules. t N represents the number of rules that passed the detection. f N represents the number of rules that failed the detection.i The number of rules for which the detection result is unknown;

[0063] S7: The browser plugin uploads the webpage source code S obtained in step S4 and the detection result set P obtained in step S6, along with the current task's unique identifier taskId, to the server.

[0064] S8: The server uses the unique task identifier taskId obtained in step S7 to find the corresponding waiting result T and returns it to the waiting thread;

[0065] S9: The server obtains a set of sub-links L from the webpage source code S, where the set of sub-links L is defined as: L = [url1, url2, ..., url...]. i And add L to the URL queue urlQueue;

[0066] S10: The server adds the detection result set P obtained in step S7 to the detection result;

[0067] S11: If the Task queue taskQueue is empty or a sufficient number of connections have been acquired (dinishCount ≥ totalCount), the process ends; otherwise, repeat step S2.

[0068] This invention can be applied to the automated detection of website page accessibility, effectively circumventing some webpage anti-scraping strategies, achieving source code-level accessibility detection across local area networks, and improving detection efficiency through concurrency control, thus helping developers to carry out accessibility modifications.

Claims

1. An accessibility detection method based on a browser plugin, characterized in that... Includes the following steps: S1: The server obtains the homepage links of the websites to be tested and the total number of websites to be tested (totalCount) from the user input, and adds the homepage links of the websites to be tested to the URL queue (urlQueue), where the URL queue (urlQueue) is defined as: urlQueue = [url1, url2, ..., url...]. i ]; S2: The server starts the crawler thread, builds the browser plugin crawler task, and waits for the crawler to return the results; S211: The server allocates a URL and a unique identifier taskId from the head of the URL queue urlQueue in step S1 according to the list order and packages it into a browser plugin task. The task T is defined as: T = {taskId, url}, and the finishedCount value of the visited links is incremented by 1. S212: The server adds task T from step S211 to the Task queue taskQueue, where the Task queue taskQueue is defined as: taskQueue = [T1, T2, ..., T i ]; S213: The server constructs a hash table (hashMap) to monitor task information, where the hash table (hashMap) is defined as: hashMap = [(taskId1, T1), (taskId2, T2), ..., (taskId...]. i T i [), where taskId is the unique identifier of the task, and T is the corresponding waiting task; S3: Browser plugins create a crawler environment and define crawler-related configurations; S31: Browser plugins establish a short-term channel between content scripts and browser extension pages to monitor the status of web pages and send and receive messages; S32: Browser plugins set cross-domain access permissions, supporting access to web pages under any declared domain; S33: The browser plugin creates a new window W, where the id value of window W is defined as winId, the number of tab pages under window W is defined as tabCount, and the maximum concurrent crawling value of the page is set to WINDOW_MAX_NUM. S4: The browser plugin requests a task T to be detected from the server and obtains the webpage source code S of the page to be detected; S4l: The browser plugin requests a task T to be tested from the server; S42: The server moves the task T to be assigned in step S41 from the task queue defined in step S212 to the listening table hashMap defined in step S213 and waits for the crawler to return the result. S43: After the browser plugin obtains the URL of task T in step S41, it opens the browser tab and accesses the URL, concurrently obtaining the webpage source code S at the page level. S431: The browser plugin obtains the cookie information stored in the current client and the URL to be detected; S432: If tabCount ≤ WINDOW_MAX_NUM, the browser plugin adds a new tab page under window W based on winId in step S33 and URL in step S43 to crawl the current URL to be detected, and the current tab count is incremented by 1; if tabCount > WINDOW_MAX_NUM, wait for the crawling of the currently opened tab page to end until tabCount ≤ WINDOW_MAX_NUM. S433: Based on the tabId of the page in step S432, the browser plugin injects a script into the page to be detected through content-scripts, and obtains the serialized HTML fragment outerHTML of the document element object (including its descendants) of the page, which is the source code S to be detected. S434: The browser plugin closes the currently crawled tab page, and the current tab count (tabCount) is decremented by 1. S5: Perform source code-level accessibility testing based on the source code S obtained in step S4; S51: Obtain the accessibility items to be detected and the rule set R = [r1, r2, r3, ..., r] from user input. i ]; S52: Apply the rule set R selected in step S51 to the source code S obtained in step S4 to perform accessibility testing, and determine whether the current webpage conforms to the corresponding item r in the standard "GB / T 37668-2019 Information Technology Internet Content Accessibility Technical Requirements and Test Methods". i Defined technical requirements; S6: The browser plugin obtains the detection result set P generated in step S5, where P = [N s N t N f N i ], N s N represents the number of rules. t N represents the number of rules that passed the detection. f N represents the number of rules that failed the detection. i The number of rules for which the detection result is unknown; S7: The browser plugin uploads the webpage source code S obtained in step S4 and the detection result set P obtained in step S6, along with the current task's unique identifier taskId, to the server. S8: The server uses the unique task identifier taskId obtained in step S7 to find the corresponding waiting result T and returns it to the waiting thread; S9: The server obtains a set of sub-links L from the webpage source code S, where the set of sub-links L is defined as: L = [url1, url2, ..., url...]. i And add L to the URL queue urlQueue; S10: The server adds the detection result set P obtained in step S7 to the detection result; S11: If the Task queue taskQueue is empty or a sufficient number of connections have been obtained (finishCount ≥ totalCount), the process ends; otherwise, repeat step S2.

Images