Accessibility Conformance Report

Accessibility Conformance Report

Voluntary Product Accessibility Template® (VPAT®) Version 2.5

About this report

A VPAT is a procurement and legal document. A buyer's accessibility or legal team may rely on it, and in public-sector procurement an inaccurate VPAT can be treated as a misrepresentation. Everything below is therefore either measured or marked as not measured.

What is measured. Automated testing with axe-core against WCAG 2.0, 2.1 and 2.2 Level A and AA across twelve representative pages spanning all three surfaces, plus scripted measurement of reflow at 320px, text resize to 200%, the WCAG text-spacing overrides, input-purpose coverage, and keyboard focus visibility. See Evaluation Methods.

What is not. Automated tooling catches roughly a third of WCAG issues. Criteria marked Not Evaluated genuinely have not been tested and need a human with a screen reader. We have not commissioned a third-party audit and we do not claim full AA conformance. That matches our public statement at https://crm.chamberculture.com/accessibility, and the two documents are meant to agree.

Name of Product/Version

Chamber Culture CRM, version 1.2.0, a hosted web application.

This report evaluates the release tagged 1.2.0. Because the product is hosted rather than installed, every chamber runs that version: there is no older release still in the field, and an accessibility fix reaches every customer at once rather than waiting for a site to upgrade. Each release carries notes describing what changed, published in the product under Releases and available to prospective customers on request.

This report is reissued on any material accessibility change, and reviewed quarterly regardless.

As of 14 August 2026.

Report Date

13 August 2026.

Three remediation rounds have landed since this report was first drafted on 8 August 2026. Every figure below is post-fix and re-measured rather than projected. See the Remediation Log. Round three (13 August) is a human keyboard and source-code semantics pass, not another axe-core scan — it is the first evaluation in this report done by a person operating the product with a keyboard rather than by automated tooling, and it moves several rows out of Not Evaluated for exactly that reason. It did not re-run axe-core, so the round-two contrast/reflow/ARIA-validity figures below are unchanged and still dated 12 August.

Product Description

Chamber Culture CRM is a multi-tenant, browser-based membership management platform for chambers of commerce. It covers member and contact records, membership dues and invoicing, online payments, events and ticketing, email and SMS communications, appointment booking, member-submitted content moderation, reporting, and a public-facing chamber website and business directory.

The product has three distinct user-facing surfaces, and their accessibility differs. This report covers all three and says which is which:

The public chamber site is the surface most likely to be subject to a public-sector accessibility obligation, because it is what a chamber's own community uses.

Contact Information

• Vendor: Champlin Enterprises, LLC
• Address: 1449 S Michigan Ave, Ste 13946, Chicago, IL 60605, United States
• Accessibility contact: contact@champlinenterprises.com, with accessibility in the subject line

That address is monitored by the people who build the product, not by a ticket queue. Our commitment, published in the product's own help guide and repeated here so a buyer can hold us to it: a reply within one business day, and anything blocking a disabled user from doing their job is treated as a defect rather than a feature request.

If email is not a workable channel for a given user, we will use whichever one is, including telephone on the number published in the product footer.

Notes

This report is a self-assessment. Chamber Culture CRM has not undergone a third-party accessibility audit. This is consistent with the product's public accessibility statement at /accessibility, which states the target is WCAG 2.2 Level AA and Revised Section 508, and that full conformance is not being claimed today. This report is scoped to claim no more than that statement does, so the two documents stay consistent with each other.

This report is published in full and ungated at /accessibility/vpat, rendered from the same source file this PDF is typeset from, so the web and PDF versions cannot drift apart.

Evaluation Methods

This report is based on the following. Round one and round two ran against the live production system; round three below explains its own surface, since it is not.

Round three, 13-14 August 2026. Keyboard operability and semantics, targeted at the six flows a chamber's own staff, members and the public actually use end to end: sign-in and password reset, the member portal (including the magic-link landing and the invoice pay page), online join, the public directory and member profile pages, event registration and door check-in (camera and manual-code), and the admin dashboard shell (navigation, sidebar, primary tables). Two methods, not one:

1. Source-code review of every Blade/Livewire view in those six flows against: form labelling, focus management (modal trap/restore, whether a Livewire re-render can drop focus), keyboard operability (no click-only handlers on a non-interactive element), visible focus, skip links, heading order, aria-expanded/aria-current where state exists, and image alt. This is the same source the production deploy runs, so its findings apply there directly.
2. A live keyboard walk, real Tab/Enter/Space keypresses driven through Playwright against a local instance running this exact code, seeded with representative demo data (not against production, and not yet re-verified against production after deploy — the finding is about the code, and the code is what ships). Each flow was walked start to finish before any fix, and re-walked after.

This round found and fixed a critical defect: below the 1024px breakpoint, the entire sidebar navigation in both the staff CRM and the member portal was completely unreachable by keyboard — the visible hamburger trigger was a <label>, and a <label> cannot be focused or activated by Enter/Space no matter what ARIA role it carries. The underlying checkbox is what daisyUI's own CSS expects to hold focus (it already ships a :focus-visible rule for exactly this), so the fix un-hides the checkbox from the keyboard/AT layer instead of trying to make the label do a checkbox's job. See the Remediation Log for the complete list; only the criteria below marked with a 13-14 August date were touched by this round — everything else in this report is unchanged from 12 August.

Round two, 12 August 2026. Repeat axe-core scan over twelve pages spanning all three surfaces, including four that did not exist on 8 August (/terms, /privacy, /qbo/disconnected, and the rebuilt help guide). Result: zero violations on every page, against 173 contrast failures at baseline. Additionally, scripted rather than eyeballed:

• Reflow at 320px CSS width on ten pages, with each overflowing element identified by name
• Resize text to 200% on the same ten
• Text spacing using the WCAG-specified overrides
• Input purpose, every field audited against the specification's defined list
• Focus visibility across the first twelve tab stops per page, driven by real Tab keypresses. An earlier pass using programmatic focus reported three failures. Those were false positives, because .focus() does not trigger :focus-visible. Re-tested properly, all twelve tab stops show a visible ring on every page. Recorded because an invented failure in a procurement document is as damaging as a concealed one.

Round one, 8 August 2026:

1. Automated WCAG scan using axe-core (industry standard, the engine behind most commercial accessibility tooling), run against 17 representative pages across all three surfaces, filtered to WCAG 2.0/2.1/2.2 Level A and AA rules. Run three times: a baseline, then twice more after remediation, so every claim of improvement below is a measured before-and-after rather than an assertion.
   • Pages covered: sign-in, accessibility statement, public booking, public directory, public events, a live chamber website, dashboard, member roster, member create form, event create form, billing, communications, settings, booking setup, help guide, a help topic, and reports.
2. Source code review for accessibility affordances: landmarks, skip links, ARIA usage, form labelling, focus styles, reduced-motion support, and keyboard alternatives to pointer-only interactions.
3. Layout measurement in a real browser at 1440px, 1280px and 390px viewports.

A methodology note that materially affects what these scans are worth. Early runs measured too soon after page load and therefore under-reported. The booking calendar is populated after an async availability fetch, so a scan taken before that returns finds an empty container and reports nothing wrong. That hid a critical role="grid" failure on every /book page for three days. Every figure in this report comes from runs that wait for the page to settle first. If you commission a third-party audit, ask how they handle asynchronously rendered content.

What has not been done yet

These are the gaps between this report and a fully evidenced one. All are scheduled, and the report is reissued as each lands. We would rather publish the list than let a buyer find it.

Applicable Standards / Guidelines

EN 301 549 is out of scope: no chamber we serve or are currently pursuing operates in the EU or sells to EU public bodies. If that changes this report gets a European annex rather than a footnote, because the criteria differ in places and a buyer deserves the real mapping instead of an assurance that they are equivalent.

WCAG 2.2 is used rather than 2.1 because 2.2 is the current recommendation and supersedes 2.1. Everything in 2.1 is included. The nine criteria new in 2.2 are marked (new in 2.2).

Terms

The terms used in the Conformance Level column are defined by ITI:

• Supports — the functionality of the product has at least one method that meets the criterion without known defects, or meets it with equivalent facilitation.
• Partially Supports — some functionality of the product does not meet the criterion.
• Does Not Support — the majority of product functionality does not meet the criterion.
• Not Applicable — the criterion is not relevant to the product.
• Not Evaluated — the product has not been evaluated against the criterion. (Permitted for Level AAA only under the standard VPAT template. We use it more widely here, and say so plainly, because claiming "Supports" for something untested would be the dishonest option. Every use is explained in the Remarks column.)

WCAG 2.2 Report

Table 1: Success Criteria, Level A

Table 2: Success Criteria, Level AA

Authoring Tool Note

This matters more for Chamber Culture than for most products, and buyers who know accessibility will ask about it.

Chamber Culture CRM is an authoring tool: chambers use it to publish a public website, a business directory, events and news. The accessibility of that published output depends on both our templates and what the chamber types and uploads.

Our templates are our responsibility. Chamber-authored content is theirs, and today the product does little to help them:

• Image upload forms do not prompt for alt text, so member logos, gallery photos and cover images can be published with none. This is the single biggest lever we have over the accessibility of the public web pages our chambers put into the world.
• There is no contrast check on the brand-kit colour picker, so a chamber can select a brand colour pair that fails 1.4.3 on its own public site.
• There is no reading-level or heading-structure guidance in the page builder.

Delivered 12 August 2026, in part. Every content-image upload, deals, news, marketplace listings, adverts, sponsorship creative and member-submitted event flyers, now offers a Describe this image field. The helper text teaches the skill rather than naming the field, "say what the image shows, not that it is an image", and on event flyers it asks for the date and price too, because on a flyer those are pixels and reach nobody using a screen reader. The in-product help guide explains why it matters.

Closed 13 August 2026: the brand kit and branding settings now warn, at pick time and persistently while a failing pair stays saved, when a chosen colour fails WCAG contrast against the way that colour actually renders on the chamber's public site. It warns rather than blocks: the chamber keeps the final say, but no longer picks a failing pair unknowingly.

Still outstanding, and honestly so: the describe-this-image field is optional rather than required, and there is no reading-level or heading-structure guidance in the page builder.

This matters beyond compliance. A chamber that describes its images is making its own community's web better, and a platform that teaches that is doing something a competitor's feature list does not cover.

Revised Section 508 Report

Chapter 3: Functional Performance Criteria

Chapter 4: Hardware

Not Applicable. Chamber Culture CRM is a web application and includes no hardware.

Chapter 5: Software

Chapter 6: Support Documentation and Services

Summary of Known Defects

Everything below was measured on the live product with axe-core, before and after remediation. Nothing here is inferred.

Scan results

Two surfaces, measured separately, because they are separate codebases.

Chamber Culture CRM (the application this report covers):

The published chamber websites (generated by a separate codebase, included because it is the surface a chamber's community actually uses):

Every page of Chamber Culture CRM, and every chamber-site page except the four carrying a map, now scans clean at WCAG 2.2 A and AA under automated testing. That is a real result and also a limited one: see the caveat below.

Why the map pins are not a defect

WCAG 2.5.8 exempts a target whose particular presentation is Essential. A map pin's position is the information being conveyed: spacing pins 24 CSS pixels apart would place businesses somewhere they are not. The pins are keyboard focusable and carry accessible names, and the same members are reachable at full size from the directory.

Delivered 13 August 2026: the map pages now cluster their pins (clusters are keyboard-operable, with an accessible name announcing the count and the zoom action), and the full member list renders on the map page itself as plain server-rendered HTML, so every business on the map is reachable at full target size on the same page without JavaScript. That satisfies the Equivalent exception on its own terms: the Essential claim above remains true of the pins, but nothing relies on it any longer.

Remaining automated finding

One, and it is claimed under an exception rather than outstanding:

Defects fixed in this round

Still open in this application

What "zero automated violations" does and does not mean

It does not mean "conforms to WCAG 2.2 AA", and we will not present it that way. Automated tooling reaches roughly a third of the standard. It cannot judge whether alt text is meaningful, whether focus order is logical, whether an error message is helpful, or whether the product is genuinely usable with a screen reader.

What it does mean is that the third a machine can reach is now clean, on every page of all three surfaces, and that we have said precisely which criteria fall outside it. Every row marked Not Evaluated is one we have not tested, rather than one we have quietly assumed in our own favour.

That distinction is the reason to trust the rows marked Supports. A report claiming conformance across the board on the strength of an automated scan is easier to write and worth less to the buyer, and it is exactly what an accessibility reviewer is trained to look for. We would rather hand you a shorter list of claims that hold.

The outstanding evaluations, principally a screen-reader and keyboard pass by a human, are scheduled. When they are done this report is reissued with those rows answered, whichever way they land.

Remediation Log

Three regression tests pin the critical fixes against rendered markup, so they cannot quietly come back.

Resolution log for this issue

Every question that blocked the 8 August draft is now closed. Recorded so a reader can see what changed between drafts rather than taking the word "issued" on trust.

Legal Disclaimer

This Accessibility Conformance Report is provided by Champlin Enterprises, LLC for informational purposes. It reflects a good-faith self-assessment of Chamber Culture CRM as of the report date, using the evaluation methods described above. It is not a third-party audit and does not constitute a warranty, guarantee, or legal certification of conformance. Accessibility is assessed against the standards named above; a product may conform to those standards and still present barriers to an individual user.

The product is under continuous development, and this report describes it as of the report date only.

❓ Standard VPAT disclaimers vary. If a client's legal team supplies preferred wording, use theirs. If any chamber you sell to is a public body, have this reviewed by counsel before issuing.

"VPAT" and "Voluntary Product Accessibility Template" are registered service marks of the Information Technology Industry Council (ITI).