What is the AudioEye Scanner?

Intended audience: Developers, Engineers, IT Professionals

The AudioEye® Scanner is an automated web browsing tool designed to perform various types of scans by interacting with web pages. 

The AudioEye Scanner evaluates websites for accessibility compliance by testing HTML elements against web accessibility standards such as the Web Content Accessibility Guidelines (WCAG). It also detects whether AudioEye's JavaScript is properly installed on the website. This detection process verifies that AudioEye is correctly set up and operational. When AudioEye functions as intended, it provides users with various accessibility features, ensuring that the website is more usable for people with different needs.

Additionally, if a customer has also purchased our Springtime Consent Management product, it carries out cookie compliance checks, analyzing and categorizing cookies to verify adherence to privacy regulations such as the California Consumer Privacy Act (CCPA) or the European Union’s General Data Protection Regulation (GDPR).

Finally, the AudioEye Scanner has site crawling capabilities that gather data about the website necessary for the above assessments and provide site metadata—like page titles—to enhance the customer experience within our products and services.

To differentiate between the purpose of the scans being performed, the AudioEye Scanner utilizes these specific User Agents, which correspond to the type of scan being performed:

• AudioEyeMonitoringBot agent — when the scanner is being utilized for our customers for the purpose of delivering our product (e.g., cookie compliance checks, accessibility compliance, JavaScript installation detection, new user experience, etc.)
  
  
• AudioEyeResearchBot agent (respects robots.txt files) — when the scanner is explicitly utilized for research.

How does the AudioEye Scanner work?

The AudioEye Scanner performs a range of website assessments, each tailored to gather specific data or ensure compliance with various standards. These scans are executed through a combination of automated interactions with web pages and specialized analysis techniques. Below is a breakdown of how each type of scan is conducted.

Common processes across all scans

• Pre-scan URL validation: Before executing a scan, the URL is validated for accessibility and properly formatted. This includes:
  
  • URL check: Verify that the incoming URL is, in fact, a URL
    
    
  • DNS resolution: Verify that the target server is reachable and the domain is valid
    
    
  • Live check: Verify that a GET request to the target URL does not return an error
    
• Request management: User-agent strings are employed to delineate different types of scans, with each user-agent associated with one or more scan types. This allows scan targets to recognize the nature of the request.
  
  
• Scan interaction: The scanner interacts directly with webpages, capturing essential data for each type of scan (see below for specifics). For each scan, the following pieces of data are captured: the original URL requested, the resolved URL after pre-scan validation occurs, whether the URL supports query strings, the state of the scan, a failure reason if appropriate, and the type of scan requested. No personally identifiable information (PII) is collected, and all captured data is securely stored and retained in our database until explicitly deleted.

Detailed scan procedures

Each scan type below is generated via an API request that specifies the type of scan to be performed and the target URL on which to perform the scan. This occurs after pre-scan URL validation has taken place.

1. Accessibility compliance scan
   
   • Objective: Test HTML elements for compliance with web accessibility standards (e.g., WCAG).
     
     
   • Process: Our accessibility testing framework script is injected into the page and begins running a series of tests against HTML elements present on the page. Once completed, a report is generated that includes information about the tests performed and which elements passed or failed said tests.
     
     
   • Data captured: For each accessibility test run, we store how many elements passed, how many failed, how many we could fix via automation, and how many did not apply to that specific test.
     
2. JavaScript installation detection
   
   • Objective: Verify the correct installation of the AudioEye JavaScript snippet.
     
     
   • Process: After the page loads, network requests that indicate the presence of AudioEye’s JavaScript are checked. Using this information, we return a report of whether or not AudioEye is correctly installed on the site.
     
     
   • Data captured: For script detection scans, we store a boolean that indicates whether or not AudioEye’s script was detected on the webpage during the scan.
     
3. Site metadata scan
   
   • Objective: Gather site metadata, such as page title, to display within our customer portal to enhance the customer experience.
     
     
   • Process: Once the page is loaded, the page title is gathered and returned.
     
     
   • Data captured: The website’s page title.
     
4. Cookie compliance scan (when our Springtime product is activated)
   
   • Objective: Analyze and categorize cookies for compliance with privacy regulations (e.g., CCPA, GDPR).
     
     
   • Process: Once the page is loaded, we scan and record cookies that are present on the page. This includes checking cookies in browser storage, cookies as part of network requests (e.g., in response headers), and cookies from public cookie setting elements. Once gathered, a report is returned that includes which cookies were found and from what source.
     
     
   • Data captured: Cookie compliance scans store a list of all cookies found on the website, including the size of the cookie, its value, the domain that set the cookie, whether or not it is secure, when it expires, if it is tied to the session, whether or not it is an HTTP only cookie, it’s priority, the SameSite designation of the cookie, its source port,  and the source scheme. Additionally, an identifier tied to any cookie setting element is stored, along with the names of the cookies set by said element.