Accessibility Policy

Purpose

The purpose of this policy is to state the accessibility standard Cadence OneFive holds its software to, how conformance with that standard is verified, and how shortfalls are recorded and remediated.

Momentum is used by building owners, operators, contractors, lenders, and program administrators, many of whom reach it through a city- or utility-sponsored program. An interface a participant cannot operate is a barrier to the program itself, not only to the software. Accessibility is therefore treated as a condition of the product working.

Scope

This policy applies to Momentum and to digital content Cadence OneFive produces, including participant applications, owner-facing web resources, and program deliverables.

It applies to all employees and contractors who design, build, review, or accept changes to those surfaces.

Policy

Conformance standard

Cadence OneFive designs, builds, and maintains its software to conform to the Web Content Accessibility Guidelines (WCAG) 2.1, Level AA.

Digital content is delivered in conformance with WCAG 2.1 Level AA unless a written exception is recorded for a specific purpose, feature, or duration.

Assessment and reporting

• Conformance is reported on the VPAT® 2.4 template as an Accessibility Conformance Report (ACR) covering all fifty Level A and Level AA success criteria.
• The ACR is a self-assessment, produced by the engineering organization and reviewed internally by the QA function. It must not be described, in a proposal or elsewhere, as an independent, external, or third-party evaluation. Where an engagement requires third-party validation, it is commissioned separately and identified as such.
• Every criterion carries the evidence that decided it. A criterion with no evidence is reported as not evaluated rather than assumed to pass.
• Each report states the surfaces it covers and the surfaces it excludes. Surfaces outside the stated scope are not claimed as conforming.

Verification

Conformance is not asserted from design review. Each success criterion is mapped to the verification method that decides it:

• Automated rule checking. Audited screens are scanned with axe-core against the WCAG 2.0 and 2.1 A and AA rule sets. Results are retained as per-screen artifacts so any claim can be traced to the scan that produced it.
• Interaction probes. Criteria that no automated rule can decide are covered by browser tests that drive the interface — keyboard traversal and focus order, focus visibility at every tab stop, accessible name against visible label, content on hover and focus, reflow, text resize, text spacing, and status-message announcement.
• Static analysis. Structural properties that must hold across the repository are enforced by static checks, including table header scoping, autocomplete tokens on inputs collecting user information, and the absence of focus-indicator suppression without a replacement.
• Recorded manual assessment. Criteria requiring human judgement are decided by a named reviewer and recorded with the reasoning and the code inspected. These are identified as manual determinations in the report.

Continuous verification

• The full accessibility audit runs on a weekly schedule and on demand against the current main branch.
• Structural checks run on every pull request, so a change that would remove a focus indicator, break table semantics, or drop an autocomplete token fails review rather than reaching production.
• When a defect is remediated, the affected criterion is re-verified against the current build before its rating is changed. A closed ticket is not by itself treated as evidence of conformance.

Design and development practices

Most accessibility defects are inherited from shared code, and so are most fixes. Cadence OneFive invests at the design-system level so that a correction propagates rather than being reapplied screen by screen.

• Shared components provide the form controls, buttons, dialogs, and table primitives used across the product, so an accessible-name or labelling correction reaches every consumer.
• A universal focus indicator is defined in the base stylesheet rather than per component.
• Color is defined as semantic tokens with measured contrast ratios rather than as ad-hoc values.
• Color is never the sole means of conveying information, state, or an error.

Defect handling and remediation

• Every accessibility defect is recorded as a tracked issue naming the criterion it violates, the surfaces affected, and whether automated coverage detected it.
• Defects affecting a reported criterion are cited in that criterion’s remarks by ticket reference, so a reader of the ACR can see what remains outstanding.
• Remediation is prioritized by user impact and conformance level, with Level A defects taking precedence over Level AA.
• Level A defects are remediated within 30 business days of identification, Level AA within 90.

Disclosure of limitations

Cadence OneFive publishes the limits of its testing alongside its results. A report describing only what passed is not a useful document.

• Where automated coverage does not reach a surface or a state, the report says so on the affected criterion and names the compensating verification.
• Automated results flagged as requiring human review are handled separately from confirmed violations and are not counted as passes.
• Where a criterion is only partially supported, the report describes the specific shortfall and names the tracked work rather than reporting a bare rating.

Feedback

Anyone encountering an accessibility barrier in Momentum, or requiring information in an alternative format, may contact accessibility@c15.io.

Reports are acknowledged within 3 business days with a remediation plan or timeline.

Responsibilities

• The Momentum Application Team owns this policy, owns the accessibility program, and is accountable for the accuracy of any conformance claim Cadence OneFive publishes or supplies.
• The QA function reviews the ACR before it is issued and confirms that each criterion’s rating matches its recorded evidence.
• Engineers are responsible for meeting the standard in the changes they author and for raising a tracked issue when they identify a defect they do not fix in the same change.
• Anyone responding to a proposal or client questionnaire is responsible for describing the ACR accurately, including its self-assessed status and its stated scope.

Review

This policy is reviewed at minimum annually, and on any material change to the product’s accessibility posture or to the standard it is assessed against.

---

VPAT® is a registered service mark of the Information Technology Industry Council (ITI).