Finalsite + AudioEye FAQs

Misty Flowers

April 28, 2026 22:07

Answers to the most common questions about AudioEye on your Finalsite CMS. For a high-level overview of what AudioEye is and where the work overlaps with your editors, check out the article, "Accessibility management with AudioEye".

Compliance and scope

Q: Is my site WCAG 2.1 compliant?
A: Compliance depends on your site's specific content and structure, so a definitive answer requires a review. Email accessibility@finalsite.com to open a specialized ticket, and the Finalsite accessibility team will advise on next steps based on your site.

Q: What standards does AudioEye target?
A: AudioEye monitors and remediates toward WCAG 2.2 Level AA. According to AudioEye, when its automation and expert services combine with your editors' content work, the stack addresses the full set of 55 WCAG A/AA success criteria. No combination of tooling guarantees compliance; confirming your site's status for any specific regulatory framework still requires a specialized review.

Q: Does AudioEye detect or fix inaccessible PDFs?
A: No. PDFs fall outside AudioEye's scope. It doesn't scan for accessibility issues in PDFs and doesn't apply fixes to the PDF files themselves. PDFs need to be made accessible before they're uploaded: reading order, tagged structure, alt text on images inside the PDF, and accessible form fields all live in the source document. AudioEye's Help Center has guidance on making PDFs accessible; for bulk remediation, it's worth a conversation with accessibility@finalsite.com about triage priorities.

Q: Does AudioEye work on embedded third-party content (Google Forms, YouTube, iframes)?
A: Generally no. Content served from another domain (especially anything inside an iframe) sits outside what AudioEye can reach. The overlay simply can't modify content that isn't part of your page. If an embedded tool is important to your site, check its own accessibility documentation or consider a more accessible alternative. For visitors who rely on assistive tech, a well-built native page is almost always more reliable than an embed.

How AudioEye makes corrections

Q: How does AudioEye actually make corrections?
A: AudioEye processes issues through AI-powered JavaScript that runs on your page. Problems the automation can't resolve are flagged for AudioEye's expert team to review and fix manually. Your current Finalsite plan with AudioEye includes ongoing rollout of those expert fixes, so you don't need to request each one. Specifics are governed by your active AudioEye subscription.

Q: Does AudioEye automatically add missing alt text?
A: Partially, and this is one of the clearest examples of shared work. During implementation, AudioEye's AI automatically writes alt text for template-level images (logos, footer images, icons). Interior content images (a photo in a story, a flyer in a newsletter, a headshot on a staff page) need alt text that reflects what the image actually means on the page, which has to come from an editor who knows the context. AudioEye flags issues like "Image accessible name is missing" or "too verbose," and then your team writes the descriptive text. Finalsite's AI-generative alt text feature in Composer drafts alt text for you as you work, which editors can review and refine so the description matches the context of the page. It's a useful starting point when you're working through volume.

Q: Does AudioEye fix heading structure (H1, H2, H3)?
A: AudioEye detects heading-order issues (for example, a page that skips from H1 to H3, or uses heading styling for visual emphasis rather than structure) and surfaces them on your report. Restructuring the headings themselves is editor work, because the right order follows the logical flow of the content, which is a judgment only someone familiar with the page can make. Composer helps you here: the accessibility checker in the Content element flags heading issues as you edit, and our best-practice article on structuring pages with HTML headings walk through how to think about heading order. Never change a heading level just to achieve a specific font size. The heading dropdown is for structural correction, not design. Broadly, AudioEye detects about 2/3 of WCAG issues automatically and fixes about half; with expert services, coverage reaches 90%+. The remaining piece is content work like this.

Q: Does AudioEye include its own screen reader?
A: No, and that's by design. Screen readers are independent software (built into the operating system or installed by the user) that read whatever window the user is in, not just a single website. Visitors should continue using the screen reader they've already configured: JAWS, NVDA, VoiceOver, TalkBack, or others. AudioEye's role is to make sure your site is clean, well-structured content that screen readers can read reliably.

The visitor experience

Q: How quickly does the AudioEye icon appear on a page?
A: Because AudioEye is JavaScript that runs after the page renders, the icon usually appears within a few seconds of page load. If you're seeing a longer delay, reload the page; if it persists, reach out to accessibility@finalsite.com.

Q: What happens when a visitor uses the "Report Issue" tab?
A: AudioEye reviews the issue, applies a fix on the overlay where possible, and will follow up with your team on what was reported. A reporting channel is aligned with current accessibility guidance, and, more importantly, it gives visitors who hit a barrier a direct way to be heard.

Q: Can we turn off the "Report Issue" feature?
A: We don't recommend it. A reporting channel is part of what accessibility guidelines now expect, and removing it takes away a direct line for the visitors who most need to tell you when something is broken. If you have specific concerns about how reports are routed or responded to, email accessibility@finalsite.com and we'll help work through them with AudioEye.

Q: Does AudioEye offer personalization presets for visitors (e.g., slowing down video)?
A: The AudioEye toolbar offers a suite of personalization controls: contrast, text size, spacing, animation controls, font adjustments, and more. For fine-grained media controls like slowing a video down, visitors generally rely on the media player's own controls (YouTube, Vimeo, etc.) or their own assistive software.

Q: Does AudioEye's overlay apply to pop-ups and modals on my site?
A: We're confirming this directly with AudioEye and will update this FAQ once we have a definitive answer. In the meantime, if you're testing a specific pop-up and want a second set of eyes, email accessibility@finalsite.com.

Q: If a visitor sets a contrast preference in the AudioEye toolbar, does that affect YouTube video captions?
A: Likely not in a significant way. YouTube captions are rendered inside YouTube's own player, which sits outside the layer AudioEye can style. Visitors who want caption contrast adjusted can use YouTube's native caption settings (font, color, background), which are the most reliable path.

Reporting

Q: Can I see reporting for my AudioEye instance?
A: Yes. The AudioEye reporting links shared with you auto-refresh with the most current data. If you don't have your reporting link, email accessibility@finalsite.com and we'll share it.

Q: Can I see exactly where on the page an issue is happening?
A: Yes, and this is one of the most useful features of AudioEye on your site. Add /?oss=1 to the end of any page URL on your AudioEye-enabled Finalsite site and the AudioEye Accessibility Page Scanner launches directly on that page. There's a brief lag after you press Enter; then the scanner panel appears. For a page like https://www.yourdistrict.org/about, you'd visit https://www.yourdistrict.org/about/?oss=1 (or use /?oss=1 if the URL already has other parameters).

What the scanner shows you on that page:

The specific element that's affected, highlighted directly on the page
The WCAG 2.1 Level AA reference (the success criterion involved)
The impact level of the issue
A plain-language description of the error
Help text on how to fix it

The scanner analyzes the live DOM (the actual HTML rendered in the browser at that moment) against WCAG 2.1 Level AA, so it catches things that a static report snapshot may not, including dynamic content that appears as visitors interact with the page.

This closes the gap many editors feel when reading a report: the report tells you the page URL and the issue type, and the scanner tells you where on that page the issue lives and what to do about it.

Q: When does my AudioEye report update?
A: AudioEye reporting runs on a rolling 7-day window. The exact day-of-week and time the report refreshes can vary; we're confirming the precise schedule with AudioEye and will post it here.

Q: I just fixed a "fix at source" issue. When will it come off the report?
A: Because the report is a rolling 7-day window, plan on a full 7 days after your fix is published for that issue to age out of the data. If the issue is still showing after a week, double-check that the fix is live on the page the scanner is hitting, and reach out if you'd like a second set of eyes.

Subscription and scope

Q: I have a parent account with AudioEye on some of my Finalsite sites. Can the same AudioEye code be added to our non-Finalsite sites?
A: Subscription scope depends on your specific AudioEye contract. Email accessibility@finalsite.com and we'll loop in AudioEye to confirm what your agreement covers.

Q: I want to add AudioEye to my site. Where do I start?
A: Email accessibility@finalsite.com. The Finalsite accessibility team handles onboarding with AudioEye and will share your auto-refreshing reporting links once you're live.

Still have questions?

If something isn't covered here, email accessibility@finalsite.com. We’re happy to help!