Report Date: 2026-05-01
Version: 1.0
CivAll Platform
2026-05-01
CivAll is a multi-tenant SaaS civic engagement platform for local government. It unifies website management, social media publishing, compliance archiving, and resident engagement on a shared data model, authentication system, and administrative interface, allowing content authored once to be distributed across web, social, email, and SMS channels.
This report covers the authenticated administrative web application used by government staff. In-scope surfaces include CivSites (website builder and Page Editor), content collections, the media library, social publishing (CivSocial), and account, department, and user administration. The citizen-facing public sites generated by CivSites are deployed separately and will be evaluated under their own VPAT.
Scope of evaluation. This report covers the authenticated administrative web application served at app.civall.com, consumed in modern desktop browsers. Surfaces exercised in the audit include the Login, Dashboard, CivSites Sites list, Site detail, Pages list, Page Editor, Page Settings sheet, Version History sheet, and Media Library. Form-error behavior and 320-pixel reflow were specifically probed.
Out of scope of this report:
civall.com.This evaluation combined static, runtime, and assistive-technology testing across three phases.
This report covers:
| Term | Meaning |
|---|---|
| Supports | The functionality of the product has at least one method that meets the criterion without known defects, or fully conforms to the criterion. |
| 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. (Permissible only for WCAG 2.x AAA criteria.) |
| Criterion | Conformance Level | Remarks and Explanations |
|---|---|---|
| 1.1.1 Non-text Content | Partially Supports | Row-action menu triggers, filter controls, breadcrumb home, the brand logo, and asset thumbnails carry contextual accessible names or alternative text. Decorative icons paired with visible text are marked aria-hidden. A small subset of social-publishing preview images may render with empty alt text when source metadata is missing. |
| 1.2.1 Audio-only and Video-only (Prerecorded) | Not Applicable | The administrative application does not author or render prerecorded audio-only or video-only content. Customer-provided media is rendered on citizen-facing public sites covered by a separate VPAT. |
| 1.2.2 Captions (Prerecorded) | Not Applicable | No prerecorded video with audio is rendered in the administrative application. |
| 1.2.3 Audio Description or Media Alternative (Prerecorded) | Not Applicable | No prerecorded synchronized media is rendered in the administrative application. |
| 1.3.1 Info and Relationships | Supports | Semantic landmarks (main, navigation, complementary) structure every page. Data tables use native table markup with column-header scope and ARIA sort attributes on sortable columns. Lists use semantic list markup. The Page Editor exposes an ARIA carousel with named slide groups and tab triggers. Form errors are programmatically associated with their inputs via aria-invalid, aria-describedby, and role="alert". Modal dialogs expose role="dialog" with aria-modal and an accessible name. |
| 1.3.2 Meaningful Sequence | Supports | DOM order matches visual presentation order; meaningful content is not visually re-ordered via CSS. |
| 1.3.3 Sensory Characteristics | Supports | Instructions and content do not rely on sensory characteristics such as shape, color, size, visual location, orientation, or sound alone. |
| 1.4.1 Use of Color | Supports | Validation errors are conveyed via both red color and visible text. Required-field markers use an asterisk symbol. Tab active state combines background change, font weight, border style, and offset. Asset upload statuses pair color with an icon and a text label. |
| 1.4.2 Audio Control | Not Applicable | No auto-playing audio is present in the administrative application. |
| 2.1.1 Keyboard | Supports | All interactive controls are keyboard operable. Modal dialogs provide a focus trap, Escape to close, and focus restoration to the triggering element. Drag-and-drop reordering provides a keyboard alternative (Tab to handle, Space to lift, Arrow keys to move, Space to drop). |
| 2.1.2 No Keyboard Trap | Supports | No keyboard traps were identified during traversal. Escape closes all sheets and dialogs cleanly with focus restored to the triggering element. |
| 2.1.4 Character Key Shortcuts | Supports | No global single-character keyboard shortcuts are bound at the application level. Editor-internal shortcuts are scoped to the editor's focused state. |
| 2.2.1 Timing Adjustable | Partially Supports | The product does not currently implement a client-side idle-timeout warning or session-extender mechanism. If a server-side session limit is reached, users may be logged out without a timed warning. Toast notifications are dismissible but auto-dismiss at default durations. |
| 2.2.2 Pause, Stop, Hide | Supports | Animations are short-duration fade, scale, or slide effects. No auto-advancing carousel or auto-scrolling content is present in the administrative application. |
| 2.3.1 Three Flashes or Below Threshold | Supports | No flashing or strobing content is present. All animations are short-duration fade, scale, or slide effects. |
| 2.4.1 Bypass Blocks | Supports | A "Skip to main content" link is rendered as the first focusable element in the application shell and moves focus to the main content region when activated. Authentication pages expose a main landmark across all conditional render branches. |
| 2.4.2 Page Titled | Supports | Each route updates the document title to a unique, descriptive value of the form "{Page} — CivAll Platform". |
| 2.4.3 Focus Order | Supports | Focus order matches the visual reading order. Sheets and dialogs auto-focus their close (or first focusable) element on open and restore focus to the trigger on close. Route navigation moves focus to the main content region with a polite announcement of the new page title. |
| 2.4.4 Link Purpose (In Context) | Partially Supports | Most link text is unique and descriptive. Some content templates (for example, news cards) use repeated "Read more" link text; the surrounding heading provides context but the link text alone is not unique. |
| 2.5.1 Pointer Gestures | Supports | Drag-and-drop interactions provide keyboard alternatives. Carousel slides are reachable via individual slide-tab buttons in addition to swipe gestures, satisfying the single-pointer alternative requirement. |
| 2.5.2 Pointer Cancellation | Supports | Activation occurs on pointer-up rather than pointer-down. No destructive actions trigger on pointer-down. |
| 2.5.3 Label in Name | Supports | Visible text on interactive controls is included in the accessible name. Controls with text labels expose names that match or contain the visible text. |
| 2.5.4 Motion Actuation | Not Applicable | No motion-driven (accelerometer, shake, or orientation) interactions exist in the administrative application. |
| 3.1.1 Language of Page | Supports | The HTML lang attribute is set to "en" on every page. |
| 3.2.1 On Focus | Supports | Focusing a control does not trigger an unexpected change of context. |
| 3.2.2 On Input | Supports | Changing the value of a form control does not automatically submit the form or trigger an unexpected change of context. Form submission requires explicit user action. |
| 3.3.1 Error Identification | Supports | Form errors are rendered in a role="alert" region linked to the offending input via aria-describedby; the input also carries aria-invalid="true". Errors are identified in text, not solely by color. |
| 3.3.2 Labels or Instructions | Supports | All form inputs are paired with an associated label. Required fields are marked with both a visible asterisk and aria-required="true". A small number of legacy forms use placeholder-led labels but do not undermine the criterion. |
| 4.1.1 Parsing | Supports | Markup parses without errors that would affect assistive technology. (Note: 4.1.1 is obsoleted in WCAG 2.2.) |
| 4.1.2 Name, Role, Value | Supports | Native HTML controls and ARIA-pattern composites expose appropriate roles, names, and states (pressed, expanded, selected, sort direction, invalid, required, described-by). |
| Criterion | Conformance Level | Remarks and Explanations |
|---|---|---|
| 1.2.4 Captions (Live) | Not Applicable | No live media is present in the administrative application. |
| 1.2.5 Audio Description (Prerecorded) | Not Applicable | No prerecorded synchronized media is present in the administrative application. |
| 1.3.4 Orientation | Supports | The application does not restrict its view to a single display orientation. |
| 1.3.5 Identify Input Purpose | Supports | Input fields collecting user information use the appropriate HTML autocomplete attributes (for example, email and current-password) so user-agent autofill and password managers can recognize them. |
| 1.4.3 Contrast (Minimum) | Supports | Text and UI components meet or exceed the WCAG AA contrast minimums (4.5:1 for normal text, 3:1 for large text and UI components). Primary, success, and accent foregrounds achieve approximately 9:1 to 10:1 against their fills. The brand color is preserved as a design accent and contrast is provided by the foreground partner. |
| 1.4.4 Resize Text | Supports | Text uses relative units and reflows at 200% browser zoom without loss of content or functionality in the primary flows inspected. |
| 1.4.5 Images of Text | Supports | UI text is rendered as HTML text rather than images. The brand logo is paired with redundant text. |
| 1.4.10 Reflow | Supports | The application reflows to a 320 CSS-pixel viewport without horizontal scrolling. Wide data tables scroll within their container, which is permitted under the criterion's exception for content requiring two-dimensional layout. |
| 1.4.11 Non-text Contrast | Supports | UI component boundaries, focus indicators, and state changes meet or exceed the 3:1 non-text contrast minimum, with multi-cue redundancy (color plus shape or position) where state is conveyed. |
| 1.4.12 Text Spacing | Supports | Component styles do not override line-height, letter-spacing, word-spacing, or paragraph-spacing in ways that would block user customization. |
| 1.4.13 Content on Hover or Focus | Partially Supports | Tooltips are dismissible and hoverable. Some custom hover-revealed action buttons appear only on pointer hover and are not reachable by keyboard hover alone. |
| 2.4.5 Multiple Ways | Supports | The application provides persistent sidebar navigation, per-section landing pages, and search where applicable. |
| 2.4.6 Headings and Labels | Supports | All authenticated pages provide a single descriptive top-level heading. Subsequent headings follow a logical h1 → h2 sequence. Authentication pages provide explicit top-level headings. |
| 2.4.7 Focus Visible | Supports | A focus indicator is rendered on every focusable element. The application's focus ring meets the 3:1 contrast minimum against adjacent content. |
| 3.1.2 Language of Parts | Not Applicable | The application is currently English-only. No inline foreign-language passages requiring lang attributes were observed. |
| 3.2.3 Consistent Navigation | Supports | The application shell, sidebar, and breadcrumb pattern are consistent across all routes inspected. |
| 3.2.4 Consistent Identification | Supports | Repeated controls (Save, Cancel, Delete, Open menu) share consistent labels and iconography across screens. |
| 3.3.3 Error Suggestion | Supports | Where input errors are detected and a suggestion is known, plain-language guidance is provided alongside the field. |
| 3.3.4 Error Prevention (Legal, Financial, Data) | Supports | Destructive actions are confirmed via an explicit confirmation dialog. The Page Editor warns the user before navigating away from a page with unsaved changes. |
| 4.1.3 Status Messages | Supports | Toast notifications, editor status updates, and form-validation errors are exposed via ARIA live regions (polite or assertive, as appropriate) and role="alert" so they are announced without moving focus. |
These six criteria were introduced in WCAG 2.2 and are evaluated separately. (4.1.1 Parsing, the only criterion deprecated in 2.2, retains its Supports status from Table 1.)
| Criterion | Conformance Level | Remarks and Explanations |
|---|---|---|
| 2.4.11 Focus Not Obscured (Minimum) (Level AA) | Supports | The application uses a left-aligned sidebar that does not overlap focused content, and editor toolbars are positioned above (not over) editable content. No floating overlays obscure focused elements in primary flows. |
| 2.5.7 Dragging Movements (Level AA) | Partially Supports | The Page Editor and Data Library use drag-and-drop reordering with a keyboard alternative (Tab to handle, Space to lift, Arrow keys to move, Space to drop). The criterion also requires a non-dragging single-pointer alternative for users who cannot perform a sustained drag; this is not yet provided in these two surfaces. Other reordering interactions on the platform use single-click controls and meet the criterion. |
| 2.5.8 Target Size (Minimum) (Level AA) | Supports | All interactive controls meet or exceed the 24×24 CSS-pixel minimum, with primary controls at 36×36 and secondary controls at 32×32 or larger. |
| 3.2.6 Consistent Help (Level A) | Not Applicable | No persistent help mechanism (help link, "?" icon, or contact-support widget) is implemented in the audited surfaces. The criterion applies only to pages that contain help mechanisms. |
| 3.3.7 Redundant Entry (Level A) | Supports | Multi-step processes do not require users to re-enter the same information. Login and MFA verification reuse the email already entered; create-site and create-page workflows do not duplicate field entry across steps; invitation acceptance pre-fills data from the invitation token. |
| 3.3.8 Accessible Authentication (Minimum) (Level AA) | Supports | The login flow offers passkeys (WebAuthn) and email magic-codes alongside password sign-in. Both passkeys and magic-codes satisfy the requirement to provide an alternative to a cognitive-function test. Browser autocomplete attributes support password managers, which the criterion recognizes as a permitted aid. |
These outcome-based criteria summarize the WCAG findings.
| Criterion | Conformance Level | Remarks and Explanations |
|---|---|---|
| 302.1 Without Vision | Supports | Programmatic semantics, focus management, and live-region announcements are in place across forms, modals, navigation, and status messages. |
| 302.2 With Limited Vision | Supports | Color-token contrast across primary, success, accent, focus ring, and component borders meets WCAG AA thresholds. |
| 302.3 Without Perception of Color | Supports | Information is not conveyed by color alone (see 1.4.1). |
| 302.4 Without Hearing | Not Applicable | No audio content. |
| 302.5 With Limited Hearing | Not Applicable | No audio content. |
| 302.6 Without Speech | Supports | No speech-input requirement is identified. |
| 302.7 With Limited Manipulation | Supports | Drag-and-drop interactions provide keyboard alternatives, and standard touch-target sizes are met. |
| 302.8 With Limited Reach and Strength | Supports | Standard touch-target sizes (≥36×36 for primary controls) meet WCAG 2.2 AA's 24×24 minimum. |
| 302.9 With Limited Language, Cognitive, and Learning Abilities | Partially Supports | Generic UI patterns and plain-language labels are used throughout. No specific cognitive accommodations such as reading-level toggles or summarization are provided. |
Not Applicable. CivAll is a web-based SaaS application accessed via standard browsers on commodity hardware. Chapters 401–411 do not apply.
| Section | Conformance Level | Remarks and Explanations |
|---|---|---|
| 502.2.1 User Control of Accessibility Features | Not Applicable | The application is browser-based and does not implement platform accessibility services directly. |
| 502.2.2 No Disruption of Accessibility Features | Supports | The application does not override or interfere with browser-level accessibility services such as text zoom, OS contrast settings, or screen-reader heuristics. |
| 502.3.1 Object Information | Supports | Native and ARIA-pattern controls expose appropriate roles. Icon-only buttons carry contextual accessible names; modal dialogs use role="dialog" with aria-modal. |
| 502.3.2 Modification of Object Information | Supports | State changes (pressed, expanded, selected, invalid, sort direction) are exposed correctly via ARIA attributes. |
| 502.3.3 Row, Column, and Headers | Supports | Data tables use native HTML table markup with column-header scope and ARIA sort attributes on sortable columns. |
| 502.3.4 Values | Supports | Form inputs expose their values; errored inputs additionally expose aria-invalid and link to descriptive error text via aria-describedby. |
| 502.3.5 Modification of Values | Supports | Standard form-control behavior. |
| 502.3.6 Label Relationships | Supports | Form labels are associated with their inputs via standard HTML and ARIA mechanisms. |
| 502.3.7 Hierarchical Relationships | Supports | Heading and landmark structure follows a consistent hierarchy across the application. |
| 502.3.8 Text | Supports | UI text is HTML text, not images of text. |
| 502.3.9 Modification of Text | Supports | Standard editable controls. |
| 502.3.10 List of Actions | Supports | Row action menus are exposed as accessible dropdown menus with contextual trigger names. |
| 502.3.11 Actions on Objects | Supports | Standard click and keyboard activation patterns. |
| 502.3.12 Focus Cursor | Supports | Focus is visible on every focused element. Focus is moved programmatically when modals open and restored to the triggering element on close. Route changes move focus to the main content region with a polite announcement. |
| 502.3.13 Modification of Focus Cursor | Supports | Standard browser focus mechanics. |
| 502.3.14 Event Notification | Supports | Toast notifications, editor status updates, and form-error live regions are exposed via ARIA live regions. |
| 502.4 Platform Accessibility Features | Supports | The application uses standard web platform features; browsers and screen readers operate normally. |
| Section | Conformance Level | Remarks and Explanations |
|---|---|---|
| 601 General | Supports | CivAll's customer support and online documentation are designed to be accessible. |
| 602.2 Accessibility and Compatibility Features | Not Evaluated | A dedicated reference describing the product's accessibility features for end users has not yet been published. |
| 602.3 Electronic Support Documentation | Supports | Help-center and online documentation are delivered through an accessible content platform that meets WCAG 2.1 AA expectations for headings, alternative text, color contrast, and keyboard navigation. |
| 602.4 Alternate Formats for Non-Electronic Support Documentation | Not Applicable | No non-electronic support documentation is provided. |
| 603.2 Information on Accessibility and Compatibility Features | Supports | Customer support staff can answer questions about the product's accessibility features and escalate as needed. |
| 603.3 Accommodations for Communication | Supports | Customer support is available via email; alternative communication channels can be arranged on request. |
This product makes no separate claims for closed functionality (Chapter 7); product accessibility claims are derived from the WCAG 2.1 A and AA tables above. For cross-reference, 702.10 references WCAG 2.0 AA and is met by WCAG 2.1 AA conformance. Closed functionality requirements (704–707) are not applicable to a browser-based SaaS application.
Across the 56 in-scope WCAG 2.1 + 2.2 A/AA criteria (50 from WCAG 2.1, plus 6 added in WCAG 2.2; AAA criteria excluded):
| Status | Level A | Level AA | Total |
|---|---|---|---|
| Supports | 23 | 19 | 42 |
| Partially Supports | 3 | 2 | 5 |
| Does Not Support | 0 | 0 | 0 |
| Not Applicable | 6 | 3 | 9 |
This report describes the current accessibility conformance of the CivAll Platform administrative web application as of the report date. Conformance claims reflect the product's behavior as observed during the evaluation; the product evolves continuously and conformance is reassessed after substantive changes.
For accessibility-specific questions, alternate document formats, or to report accessibility issues encountered in the product, contact us at support@civall.com.
"VPAT" is a registered service mark of the Information Technology Industry Council (ITI).
This document is provided for informational purposes only and reflects the conformance of the CivAll Platform as of the report date and to the best of CivAll's knowledge based on the testing methods described. It is not a warranty, a guarantee of conformance, or a contractual commitment, and customers are responsible for evaluating the product's fit for their specific accessibility requirements.
CivAll may update this document at any time without notice as the product evolves. The current version is available at https://trust.civall.com.