FastComments Accessibility

We work to make FastComments usable by everyone, including people who rely on assistive technology. This page summarizes our current conformance with WCAG 2.1 Level AA, the standard most commonly referenced by educational institutions and government buyers.

Overview

FastComments is an embedded commenting and chat widget delivered as a JavaScript bundle that renders inside a host page. Our accessibility work targets WCAG 2.1 Level AA and the U.S. Section 508 ICT Refresh (which incorporates WCAG 2.0 AA by reference). This statement applies to the FastComments comment widget, live chat widget, and the public fastcomments.com marketing site.

The administrative dashboard (used by site owners and moderators, not end commenters) is covered by best-effort accessibility but is not the primary focus of this statement. Tenant-side customization (custom CSS, custom themes, translation overrides) can affect end-user accessibility in ways outside of our control; please review any customization you apply.

Conformance Status

FastComments is partially conformant with WCAG 2.1 Level AA. "Partially conformant" means that some parts of the content do not fully meet the standard. The table below reflects our honest current state, not an aspirational claim. Items marked "Partially Supports" or "Does Not Support" are tracked on our internal roadmap.

Standards Used

WCAG 2.1 Level A & AA Conformance Table

The "Conformance Level" column uses the standard VPAT terminology: Supports, Partially Supports, Does Not Support, and Not Applicable. Where an item is "Not Applicable," the criterion does not apply to an embedded widget that renders only text content, or the responsibility falls to the host page.

Criterion Level Conformance Remarks
1.1.1 Non-text ContentAPartially SupportsAvatars, status icons, and toolbar icons have alt text. Some icon-only buttons rely on adjacent text or title attributes rather than explicit aria-label.
1.2.1 Audio-only and Video-only (Prerecorded)ANot ApplicableThe widget does not present audio or video content directly. Embedded media in comment bodies is the responsibility of the linking commenter.
1.2.2 Captions (Prerecorded)ANot ApplicableNo prerecorded synchronized media is delivered by the widget.
1.2.3 Audio Description or Media AlternativeANot ApplicableNo prerecorded synchronized media is delivered by the widget.
1.2.4 Captions (Live)AANot ApplicableNo live synchronized media is delivered by the widget.
1.2.5 Audio Description (Prerecorded)AANot ApplicableNo prerecorded video is delivered by the widget.
1.3.1 Info and RelationshipsAPartially SupportsForms use semantic input and label elements. Comment threads use nested lists structurally. Editor toolbar buttons currently use div elements with data-action handlers rather than native button elements; replacing these is on our roadmap.
1.3.2 Meaningful SequenceASupportsDOM order matches reading order.
1.3.3 Sensory CharacteristicsASupportsNo instructions depend on shape, color, or spatial location alone.
1.3.4 OrientationAASupportsThe widget reflows to both portrait and landscape.
1.3.5 Identify Input PurposeAAPartially SupportsEmail and name inputs accept autocomplete; some optional fields do not yet declare autocomplete tokens.
1.4.1 Use of ColorASupportsColor is not the sole means of conveying state (votes, validation errors, status badges all include text or icons).
1.4.2 Audio ControlANot ApplicableThe widget does not auto-play audio.
1.4.3 Contrast (Minimum)AAPartially SupportsDefault light and dark themes meet 4.5:1 for body text against background. Tenants may apply custom CSS that overrides these values; we recommend tenants verify contrast on customized deployments.
1.4.4 Resize TextAASupportsLayout reflows up to 200% zoom without loss of content or functionality.
1.4.5 Images of TextAASupportsNo images of text are used for UI labels.
1.4.10 ReflowAASupportsContent reflows at 320 CSS pixels width without horizontal scrolling.
1.4.11 Non-text ContrastAAPartially SupportsDefault theme meets the 3:1 ratio for active UI controls and graphical objects in most cases. Vote arrows and some hover states are being reviewed.
1.4.12 Text SpacingAASupportsUser-applied text-spacing overrides do not break the layout.
1.4.13 Content on Hover or FocusAAPartially SupportsTooltips and dropdowns are dismissible and hoverable. A small number of hover-triggered popovers do not yet support keyboard-equivalent dismissal.
2.1.1 KeyboardAPartially SupportsSubmission, voting, reply, sign-in, and search are keyboard-operable. The rich-text formatting toolbar (bold, italic, link, image, etc.) is currently activated via mouse and arrow-key navigation rather than full tab order; this is on our roadmap.
2.1.2 No Keyboard TrapASupportsModals and inline editors can be exited with Escape or by tabbing out.
2.1.4 Character Key ShortcutsASupportsThe widget does not bind single-character shortcuts at the document level.
2.2.1 Timing AdjustableANot ApplicableNo time limits are imposed on reading or composing comments. Sign-in sessions follow the host site's policy.
2.2.2 Pause, Stop, HideAPartially SupportsLive-update streams can be disabled at the tenant level. We do not yet expose a per-user toggle to pause incoming live comments.
2.3.1 Three Flashes or Below ThresholdASupportsNo content flashes more than three times per second.
2.4.1 Bypass BlocksANot ApplicableThe widget is one block of content within a host page; bypass links are the host page's responsibility.
2.4.2 Page TitledANot ApplicableThe widget does not set the host page title.
2.4.3 Focus OrderASupportsFocus order follows DOM order and matches reading order.
2.4.4 Link Purpose (In Context)ASupportsLink text describes destination; permalink and reply links are paired with comment context.
2.4.5 Multiple WaysAANot ApplicableApplies to a set of pages, not to an embedded widget.
2.4.6 Headings and LabelsAAPartially SupportsForm labels are descriptive. The widget does not currently emit heading elements for comment-thread sections; individual comment authors and timestamps are exposed as labelled regions instead.
2.4.7 Focus VisibleAADoes Not SupportThe widget relies on browser-default focus rings. Tenants whose host CSS removes outlines globally will inherit that loss of focus indication. Adding explicit, opinionated focus-visible styles to the widget shell is a tracked roadmap item.
2.5.1 Pointer GesturesASupportsAll actions can be performed with a single-point activation; no path-based or multi-point gestures.
2.5.2 Pointer CancellationASupportsActions trigger on pointer-up, allowing cancellation by dragging off the target.
2.5.3 Label in NameAPartially SupportsMost accessible names include the visible label text. A small number of icon-only buttons use a synonymous aria-label that does not match the visible tooltip word-for-word.
2.5.4 Motion ActuationANot ApplicableNo motion-triggered functionality.
3.1.1 Language of PageANot ApplicableThe widget honors the host page's lang attribute and serves localized strings accordingly; the host page is responsible for declaring lang on its document.
3.1.2 Language of PartsAASupportsThe widget does not mix languages within a single rendered string; commenter content is delivered as authored.
3.2.1 On FocusASupportsFocusing an element does not initiate a context change.
3.2.2 On InputASupportsChanging an input value does not initiate an unexpected context change.
3.2.3 Consistent NavigationAASupportsThe widget renders the same controls in the same order on every page where it is embedded.
3.2.4 Consistent IdentificationAASupportsComponents with the same functionality (vote, reply, report) are identified consistently.
3.3.1 Error IdentificationAPartially SupportsServer-side errors are surfaced inline near the relevant form field. Some client-side validation errors are not yet associated with their input via aria-describedby.
3.3.2 Labels or InstructionsASupportsAll form inputs have visible labels or placeholders paired with descriptions.
3.3.3 Error SuggestionAAPartially SupportsErrors describe what went wrong and, where possible, how to fix it. Some validation messages are generic.
3.3.4 Error Prevention (Legal, Financial, Data)AASupportsComment deletion and account deletion are confirmable and reversible within a grace window.
4.1.1 Parsing (obsolete in WCAG 2.2)ASupportsGenerated markup is well-formed.
4.1.2 Name, Role, ValueAPartially SupportsNative form controls expose correct names and roles. Custom div-based toolbar buttons do not yet declare role=button or aria-pressed where applicable; this is a tracked roadmap item.
4.1.3 Status MessagesAADoes Not SupportNew incoming comments, successful submissions, and toast notifications are not currently announced via aria-live regions. We are scoping a polite-priority live region for these events.

Known Gaps and Roadmap

We track the following items as the highest-priority accessibility work:

  1. Visible focus styles baked into the widget shell so they survive aggressive host-page CSS resets (addresses 2.4.7).
  2. aria-live status region for new-comment arrivals, submission success, and validation toasts (addresses 4.1.3).
  3. Native button elements for the rich-text editor toolbar, with proper role, name, and aria-pressed where applicable (addresses 1.3.1, 2.1.1, 4.1.2).
  4. Per-user toggle to pause the live-update stream from within the widget (addresses 2.2.2).
  5. Continued contrast audit of icon controls and hover states in both default themes (addresses 1.4.11).

Compatibility With Assistive Technology

FastComments is designed to work with current versions of:

Browser Support

FastComments supports the latest two major versions of Chrome, Firefox, Safari, and Edge. Older browsers may degrade accessibility in ways outside our control.

Tenant Responsibilities

Site owners who embed FastComments influence end-user accessibility through their own host page. To preserve accessibility:

Formal Approach

Our accessibility approach combines automated linting in CI (axe-core based checks), targeted manual testing during feature work, and periodic full audits against the WCAG 2.1 AA checklist. We do not currently hold a third-party accessibility certification; this self-assessment is performed by the FastComments engineering team.

VPAT

A formal VPAT 2.5 (revision 508/WCAG/EN edition) is available on request for procurement teams. The contents mirror the conformance table above. Please contact us at the email below and we will provide the current PDF.

Feedback and Contact

We welcome feedback on the accessibility of FastComments. If you encounter an accessibility barrier, please let us know what page or interaction was involved, your assistive technology, and your browser. We aim to respond within five business days.

Email us at: Click to Show Email

This statement was last reviewed on May 19th 2026.