Accessibility & Screen Reader Support

Accessibility & Screen Reader Support

At Sleeknote, accessibility is a core part of how we build campaigns. Our widgets are designed and tested to meet WCAG 2.1 Level AA, so visitors using assistive technologies, including screen readers such as NVDA, JAWS, and VoiceOver, can perceive, navigate, and interact with campaigns confidently and independently.

Campaign Formats Covered

Our accessibility standards apply across all campaign types, including:

• Popups (center overlays, slide-ins, corner widgets)
• Banners (top and bottom bars)
• Embedded forms (inline on-page)
• Coupon codes
• Interactive campaigns (quizzes, spin-to-win, scratch cards)
• Product recommendations
• Calendar and door-style campaigns

Built as a Native Web Component

Campaigns render as a custom web component rather than inside an iframe. This is what makes full accessibility possible: campaign content lives in the page’s own accessibility tree, so screen readers announce it as part of the document instead of as an isolated frame. It also gives us precise control over ARIA semantics, focus order, and how the campaign interacts with the surrounding site.

Screen Reader Behavior

When a campaign appears, it is exposed to assistive technologies as a dialog with the correct ARIA role and properties, clearly communicating that a distinct, interactive region has opened. Campaign content, including headings, text, form fields, and controls, is fully readable by screen readers.

• Modal campaigns (such as popups and slide-ins) set the rest of the page as inert while open, so screen reader users aren’t navigated into hidden background content.
• Non-modal campaigns (such as banners and embedded forms) allow continued access to surrounding page content.
• Only genuinely decorative elements, such as background images, layout spacers, and purely visual flourishes, are hidden from screen readers, so users hear meaningful content without noise.

ARIA & Labeling

Every campaign and its controls carry correct ARIA roles, states, and accessible names:

• Campaigns use the appropriate dialog role, with the campaign’s heading or title programmatically associated as its accessible name.
• Interactive elements expose their role and current state (for example, expanded/collapsed, selected, or pressed) to assistive technologies.
• All labels are derived from visible text wherever possible, so what a sighted user sees matches what a screen reader announces.

Focus Management

We implement structured focus behavior to support keyboard and screen reader users:

• On open: Focus automatically moves into the campaign, to the first interactive element (or the dialog itself).
• Focus trapping: In modal campaigns, the Tab key cycles only through elements within the campaign. Focus wraps from the last element back to the first (and vice versa with Shift + Tab).
• On close: Focus returns to the element that triggered the campaign, so keyboard users keep their place on the page.
• Shadow DOM compatibility: As a web component, campaigns render inside Shadow DOM for style isolation. Our focus management traverses shadow boundaries so all interactive elements remain accessible.

Keyboard Navigation & Tab Order

All campaigns are fully operable by keyboard, and tab order is coordinated with the host website:

• Tab: Move to the next interactive element
• Shift + Tab: Move to the previous interactive element
• Escape: Close the campaign
• Enter / Space: Activate buttons, submit forms, select options
• Arrow keys: Navigate dropdown lists and autocomplete fields

While a modal campaign is open, tabbing is contained within it. Once closed, tab order flows naturally back into the page in the correct sequence, with no orphaned or out-of-order stops introduced by the campaign.

Form Accessibility

We ensure forms are structured and announced correctly:

• Labels: Every form field has an associated label, so screen readers clearly announce its purpose.
• Required fields: Required inputs are announced as required when focused.
• Validation errors: Errors are announced immediately using live regions and are programmatically linked to their corresponding inputs.
• Buttons: Interactive elements use semantic <button> elements with accessible names derived from visible text.

Images & Alt Text

Images that carry meaning can be given alternative text directly in the editor, with no code required. Adding an image element exposes an alt-text field, so you can describe it for screen reader users. Decorative images are automatically hidden from assistive technologies, so you only need to write alt text where it adds value.

Coupon Codes

Coupon codes are accessible to both keyboard and screen reader users. The code itself is presented as selectable text, and a semantic Copy button allows easy copying and is fully operable via keyboard and assistive technologies.

Interactive Campaigns

Interactive elements are built with semantic markup and keyboard operability:

• Selection states use standard form controls (radio buttons, checkboxes) with associated labels.
• Dropdowns and list selections communicate the currently selected option to assistive technologies.

Hidden from Assistive Technology

To reduce noise and improve clarity, only purely decorative elements are hidden from screen readers:

• Background images and decorative overlays
• Visual spacers and layout-only elements
• Decorative SVG icons