1. Conformance Level

Ads By Virtue aims to conform to WCAG 2.2 Level AA, the legal standard for ADA compliance in the United States and the recommended conformance level for public-sector sites under the European Accessibility Act. We test every page release against the full WCAG 2.2 AA criteria using a combination of automated scanning (axe-core v4.12, integrated into our Playwright test suite) and manual keyboard, screen-reader, and cognitive-load reviews.

Our most recent full audit (July 2026) found 0 axe-core violations across 40 scans covering all primary pages, all interactive states (cookie banner open, mobile drawer open, accordion expanded, validation errors visible), and all auth flows. The raw audit results are persisted in our test artifact archive and are summarized in the ACCESSIBILITY-AUDIT-REPORT.md document.

2. What We Do

Skip-to-content link: A visually-hidden keyboard-accessible skip link is the first focusable element on every page, letting keyboard users bypass the navigation chrome and jump straight to the main content region.
Semantic landmarks: Every page uses proper <header>, <main>, <nav>, and <footer> landmarks with descriptive aria-label attributes so screen-reader users can navigate by region.
Keyboard operability: All interactive elements (forms, dropdowns, accordions, the cookie consent dialog, the mobile drawer) are operable with a keyboard alone, with a visible focus indicator that meets WCAG 2.4.7 (Focus Visible) and 2.4.11 (Focus Not Obscured).
Color contrast: All text meets the 4.5:1 contrast minimum (WCAG 1.4.3) for normal text and 3:1 for large text. The dark theme is the default because it provides the best contrast for the majority of our color palette.
Forms: Every input has a programmatically associated <label> (or aria-label), required fields are marked with both a visible asterisk and aria-required, validation errors are announced via aria-live="assertive", and the first invalid field receives focus on a failed submit.
Respect for user preferences: The site honors prefers-color-scheme, prefers-reduced-motion, and prefers-contrast media queries. Reduced-motion users see no animations; forced-colors users see outlines preserved.
Internationalization: The site is fully translated into English, Spanish, and Arabic, with proper RTL layout for Arabic (the dir attribute is set on <html> per locale) and a font stack that includes Noto Sans Arabic for correct glyph rendering.

3. Known Limitations

Despite our best efforts, some parts of the platform may have accessibility limitations:

Third-party embeds: Social media embeds (LinkedIn, Instagram, Facebook icons in the footer) link to third-party sites whose accessibility we do not control. We mark these external links with rel="noopener noreferrer" and visually indicate them with an arrow icon.
Payoneer checkout: The Payoneer payment flow loads in an iframe that we cannot modify. Payoneer maintains its own accessibility statement. If you encounter accessibility issues during checkout, please contact Payoneer support and our team will assist with an alternative payment method.
User-generated content: Campaign briefs, ad creatives, and messages submitted by brands, influencers, and publishers are not pre-screened for accessibility (e.g. alt text on images). We provide guidance in our content guidelines and offer a reporting mechanism for inaccessible user content.
Older blog content: A small number of legacy blog posts may contain images without alt text. We are working through the backlog; please report any specific posts that are inaccessible and we will prioritize them.

4. How to Report an Accessibility Issue

If you encounter an accessibility barrier on Ads By Virtue, please report it so we can fix it. We take accessibility reports seriously and aim to respond within 2 business days. Critical barriers (e.g. a screen-reader user cannot complete a signup flow) are treated as production incidents and patched within 24 hours.

You can report issues by:

Email: accessibility@adsbyvirtue.com
Our contact form (select "Bug Report" as the subject)

When reporting, please include:

The URL of the page where you encountered the barrier.
A brief description of the barrier and what you were trying to do.
The browser and assistive technology you are using (e.g. "Safari 17 with VoiceOver" or "Chrome 124 with NVDA 2024.1").

5. Technical Approach

Accessibility is enforced at three layers:

Automated testing: Every pull request runs axe-core against the affected pages. New code that introduces a violation is blocked from merging. The test artifact is published as tests/qa/axe-results/_all.json.
Component library: Our internal UI primitives (form inputs, buttons, dialogs, accordions) bake ARIA semantics in at the component level, so developers cannot accidentally produce an inaccessible variant.
Manual review: Every new page is manually tested with keyboard navigation and at least one screen reader (NVDA on Windows or VoiceOver on macOS) before release.

6. Changes to This Statement

We may update this Accessibility Statement as we improve our platform or in response to changes in WCAG or applicable law. The "Last updated" date at the top of this page reflects the most recent review. We will not materially reduce our conformance level without notice.

7. Contact

For accessibility inquiries, contact our accessibility lead at accessibility@adsbyvirtue.com or use our contact form.

1. Conformance Level

2. What We Do

Skip-to-content link: A visually-hidden keyboard-accessible skip link is the first focusable element on every page, letting keyboard users bypass the navigation chrome and jump straight to the main content region.

Semantic landmarks: Every page uses proper <header>, <main>, <nav>, and <footer> landmarks with descriptive aria-label attributes so screen-reader users can navigate by region.

Keyboard operability: All interactive elements (forms, dropdowns, accordions, the cookie consent dialog, the mobile drawer) are operable with a keyboard alone, with a visible focus indicator that meets WCAG 2.4.7 (Focus Visible) and 2.4.11 (Focus Not Obscured).

Color contrast: All text meets the 4.5:1 contrast minimum (WCAG 1.4.3) for normal text and 3:1 for large text. The dark theme is the default because it provides the best contrast for the majority of our color palette.

Forms: Every input has a programmatically associated <label> (or aria-label), required fields are marked with both a visible asterisk and aria-required, validation errors are announced via aria-live="assertive", and the first invalid field receives focus on a failed submit.

Respect for user preferences: The site honors prefers-color-scheme, prefers-reduced-motion, and prefers-contrast media queries. Reduced-motion users see no animations; forced-colors users see outlines preserved.

Internationalization: The site is fully translated into English, Spanish, and Arabic, with proper RTL layout for Arabic (the dir attribute is set on <html> per locale) and a font stack that includes Noto Sans Arabic for correct glyph rendering.

3. Known Limitations

Despite our best efforts, some parts of the platform may have accessibility limitations:

Third-party embeds: Social media embeds (LinkedIn, Instagram, Facebook icons in the footer) link to third-party sites whose accessibility we do not control. We mark these external links with rel="noopener noreferrer" and visually indicate them with an arrow icon.

Payoneer checkout: The Payoneer payment flow loads in an iframe that we cannot modify. Payoneer maintains its own accessibility statement. If you encounter accessibility issues during checkout, please contact Payoneer support and our team will assist with an alternative payment method.

User-generated content: Campaign briefs, ad creatives, and messages submitted by brands, influencers, and publishers are not pre-screened for accessibility (e.g. alt text on images). We provide guidance in our content guidelines and offer a reporting mechanism for inaccessible user content.

Older blog content: A small number of legacy blog posts may contain images without alt text. We are working through the backlog; please report any specific posts that are inaccessible and we will prioritize them.

4. How to Report an Accessibility Issue

You can report issues by:

When reporting, please include:

The URL of the page where you encountered the barrier.

A brief description of the barrier and what you were trying to do.

The browser and assistive technology you are using (e.g. "Safari 17 with VoiceOver" or "Chrome 124 with NVDA 2024.1").

5. Technical Approach

Accessibility is enforced at three layers:

Automated testing: Every pull request runs axe-core against the affected pages. New code that introduces a violation is blocked from merging. The test artifact is published as tests/qa/axe-results/_all.json.

Component library: Our internal UI primitives (form inputs, buttons, dialogs, accordions) bake ARIA semantics in at the component level, so developers cannot accidentally produce an inaccessible variant.

Manual review: Every new page is manually tested with keyboard navigation and at least one screen reader (NVDA on Windows or VoiceOver on macOS) before release.