Accessibility Conformance Report

Product Information

Product details

Product	CivicCA Agenda Management Platform
Version	Current (April 2026)
Report Date	April 17, 2026
Based On	VPAT 2.5 (WCAG 2.1 Edition)
Contact	support@civicca.com

Applicable Standards

Applicable accessibility standards

Standard	Included in Report
WCAG 2.1 Level A	Yes
WCAG 2.1 Level AA	Yes
Revised Section 508 (36 CFR 1194)	Yes

Terminology

Conformance level definitions

Term	Definition
Supports	The functionality has at least one method that meets the criterion without known defects or meets with equivalent facilitation.
Partially Supports	Some functionality does not meet the criterion.
Does Not Support	The majority of functionality does not meet the criterion.
Not Applicable	The criterion is not relevant to the product.

WCAG 2.1 Level A

WCAG 2.1 Level A conformance results

Criteria	Level	Remarks
1.1.1 Non-text Content	Supports	All images include descriptive alt text. Decorative SVG icons use aria-hidden="true". Document scan thumbnails include finding-specific alt descriptions.
1.2.1 Audio-only and Video-only	Partially Supports	AI-generated meeting transcripts provide text alternatives. Video content relies on external platform captions (YouTube, Zoom).
1.2.2 Captions (Prerecorded)	Partially Supports	Video embeds from YouTube/Zoom provide their own captioning. AI-generated captions available for transcribed meetings.
1.2.3 Audio Description or Media Alternative	Partially Supports	Meeting transcripts serve as media alternatives for audio content.
1.3.1 Info and Relationships	Supports	HTML5 landmarks used throughout (nav, main, header, footer with ARIA roles). Form labels associated with inputs. Data tables include scope attributes on all <th> elements and <caption> elements. Dropdown menus use role="menu" and role="menuitem".
1.3.2 Meaningful Sequence	Supports	Content presented in logical reading order. DOM order matches visual order across all layouts.
1.3.3 Sensory Characteristics	Supports	Instructions do not rely solely on shape, color, size, or visual location. Status badges combine color with text labels.
1.4.1 Use of Color	Supports	Color is not used as the only means of conveying information. Status indicators use text labels alongside color.
1.4.2 Audio Control	Supports	No audio plays automatically. Video embeds require user interaction to start.
2.1.1 Keyboard	Supports	All navigation is keyboard accessible. Modals include focus trapping. Skip navigation links on all layouts. Dropdown menus support arrow key navigation (ArrowUp/Down, Home, End). Drag-and-drop agenda builder provides keyboard alternatives.
2.1.2 No Keyboard Trap	Supports	Focus is not trapped in any component without Escape key exit. Modal dialogs, help panel, and feedback form all close with Escape and return focus to trigger element.
2.1.4 Character Key Shortcuts	Supports	No single character key shortcuts are implemented.
2.2.1 Timing Adjustable	Supports	Session timeout is configurable. Speaker timer is user-controlled. No content-based time limits.
2.2.2 Pause, Stop, Hide	Supports	No auto-updating, blinking, or scrolling content. Live meeting status updates use aria-live="polite". All animations respect prefers-reduced-motion.
2.3.1 Three Flashes or Below Threshold	Supports	No content flashes more than three times per second.
2.4.1 Bypass Blocks	Supports	Skip navigation links on all three layouts (admin, portal, marketing). All visible on keyboard focus.
2.4.2 Page Titled	Supports	All pages have descriptive <title> elements with page name and application name.
2.4.3 Focus Order	Supports	Focus order follows logical reading order. Modal focus is properly managed with focus trapping.
2.4.4 Link Purpose (In Context)	Supports	Links have descriptive text or aria-label. Icon-only buttons include aria-label (e.g., "Toggle sidebar", "Toggle theme", "Send Feedback", "Help", "User menu").
2.5.1 Pointer Gestures	Supports	All drag-and-drop functionality has keyboard alternatives.
2.5.2 Pointer Cancellation	Supports	Actions activate on the up event. Drag-and-drop operations can be cancelled.
2.5.3 Label in Name	Supports	Visible labels match accessible names. Buttons with icons include matching aria-label text.
2.5.4 Motion Actuation	Not Applicable	No functionality is triggered by device motion.
3.1.1 Language of Page	Supports	lang attribute set on the <html> element. Portal supports language selection.
3.2.1 On Focus	Supports	No context changes occur when components receive focus.
3.2.2 On Input	Supports	No context changes occur on input change. Form submissions require explicit action.
3.3.1 Error Identification	Supports	Form errors displayed with role="alert". Validation utility provides aria-invalid="true" and error messages linked via aria-describedby. Toast notifications use role="alert" for errors.
3.3.2 Labels or Instructions	Supports	Form inputs have associated <label> elements. Required fields use aria-required="true" and HTML5 required. Autocomplete attributes used for email and password fields.
4.1.1 Parsing	Supports	HTML output uses well-formed markup with proper nesting.
4.1.2 Name, Role, Value	Supports	Interactive elements have proper names and roles. Modal dialogs use role="dialog" with aria-modal="true". Dropdown menus use role="menu"/role="menuitem". User menu button uses aria-haspopup and aria-expanded.

WCAG 2.1 Level AA

WCAG 2.1 Level AA conformance results

Criteria	Level	Remarks
1.2.4 Captions (Live)	Not Applicable	CivicCA does not host live media streams. Live meeting features are data-driven.
1.2.5 Audio Description (Prerecorded)	Not Applicable	CivicCA embeds third-party video and does not produce original video content.
1.3.4 Orientation	Supports	Content is not restricted to a single display orientation. All layouts are responsive.
1.3.5 Identify Input Purpose	Supports	Input fields use appropriate autocomplete attributes (email, password, name).
1.4.3 Contrast (Minimum)	Supports	Primary text meets 4.5:1 ratio. Dark theme: #e8ecf4 on #06090f (~17:1). Light theme: #1a1f2e on #f0f2f5 (~14:1). Secondary and dim text colors have been verified to meet WCAG AA requirements. Focus indicators use 2px solid outline. Portal color picker includes contrast ratio validation against white backgrounds.
1.4.4 Resize Text	Supports	Text can be resized up to 200% without loss of content. Layouts use responsive CSS with relative units.
1.4.5 Images of Text	Supports	Text is rendered as actual text. PDF generation uses real text. No images of text for UI elements.
1.4.10 Reflow	Supports	Content reflows at 320px width without horizontal scrolling. Sidebar collapses on small screens.
1.4.11 Non-text Contrast	Supports	UI components and graphical objects meet 3:1 contrast ratio. Focus indicators are clearly visible.
1.4.12 Text Spacing	Supports	Content adapts when users override text spacing via user stylesheets.
1.4.13 Content on Hover or Focus	Supports	Tooltips and dropdown menus appear on hover/focus and are dismissible via Escape key.
2.4.5 Multiple Ways	Supports	Multiple ways to locate content: navigation menu, search, breadcrumbs, direct URLs.
2.4.6 Headings and Labels	Supports	Headings describe topic/purpose. Form labels clearly describe inputs. Proper heading hierarchy maintained.
2.4.7 Focus Visible	Supports	Visible focus indicator on all interactive elements: :focus-visible { outline: 2px solid var(--blue); outline-offset: 2px; } across all themes.
2.4.11 Focus Not Obscured	Supports	Focused elements are not hidden by other content. Fixed headers/sidebars do not cover focused elements.
3.1.2 Language of Parts	Supports	Portal supports multiple languages with appropriate language attributes.
3.2.3 Consistent Navigation	Supports	Navigation is consistent across pages within each layout.
3.2.4 Consistent Identification	Supports	Components with the same functionality have consistent labels and behavior.
3.3.3 Error Suggestion	Supports	Forms provide specific error messages with suggestions. Validation utility links errors to fields via aria-describedby.
3.3.4 Error Prevention	Supports	Destructive actions require confirmation dialogs. Agenda publishing includes review steps.
4.1.3 Status Messages	Supports	Toast container uses aria-live="polite". Individual toasts use role="status" (success) and role="alert" (error). Upload progress, drag-and-drop reorder, and speaker timer all use appropriate aria-live regions.

Revised Section 508 — Functional Performance Criteria

Section 508 functional performance criteria

Criteria	Level	Remarks
302.1 Without Vision	Supports	Screen reader users can navigate using landmarks, headings, ARIA attributes, and descriptive image alt text. All data tables have proper structure with scope and caption elements.
302.2 With Limited Vision	Supports	Content supports zoom up to 200%. High contrast between text and backgrounds. Clear focus indicators. Dark and light themes available.
302.3 Without Perception of Color	Supports	Color is not the sole means of conveying information. Status indicators use text labels.
302.4 Without Hearing	Partially Supports	AI-generated meeting transcripts provide text alternatives. Video captions depend on external platform support.
302.5 With Limited Hearing	Partially Supports	Same as 302.4.
302.6 Without Speech	Supports	No functionality requires speech input.
302.7 With Limited Manipulation	Supports	Full keyboard navigation supported. Dropdown menus have arrow key navigation. Drag-and-drop has keyboard alternatives.
302.8 With Limited Reach and Strength	Supports	All functionality accessible via standard keyboard and mouse/touch.
302.9 With Limited Language, Cognitive, and Learning Abilities	Supports	Clear, consistent navigation. Descriptive labels and headings. Error messages provide guidance. Multi-language portal support.

Accessibility Features Summary

Keyboard Navigation

• Skip-to-content links on all page layouts (admin, portal, marketing)
• Full Tab/Shift+Tab navigation with visible focus indicators
• Arrow key navigation in dropdown menus (Up/Down, Home, End)
• Escape key closes all modals, dropdowns, and overlays
• Focus trapping in modal dialogs, help panel, and feedback form
• Focus returns to trigger element when dialogs close

Screen Reader Support

• Semantic HTML5 landmarks: <nav>, <main>, <header>, <footer>
• ARIA roles on all interactive components (dialog, menu, menuitem, alert, status)
• aria-live regions for dynamic content (toasts, upload progress, drag-and-drop, speaker timer)
• aria-expanded, aria-haspopup, aria-current on navigation elements
• Descriptive alt text on all images; decorative icons hidden with aria-hidden
• Data tables with scope attributes and <caption> elements
• Portal breadcrumbs use proper <ol>/<li> structure

Visual Accessibility

• Dark and light theme support with CSS custom properties
• All text meets WCAG AA contrast ratios (4.5:1 for normal text, 3:1 for large text)
• Portal color customization includes contrast ratio validation
• Respects prefers-reduced-motion across all stylesheets
• Responsive design works at 320px width and 200% zoom

Form Accessibility

• All form inputs have associated <label> elements
• Required fields indicated with aria-required and HTML5 required
• Validation errors use aria-invalid and aria-describedby to link error messages to fields
• Error notifications use role="alert" for immediate screen reader announcement
• Autocomplete attributes on identity and credential fields

DOJ Title II ADA Compliance

On April 24, 2024, the U.S. Department of Justice published a final rule under Title II of the Americans with Disabilities Act (28 CFR Part 35) requiring state and local governments to ensure their web content and mobile applications conform to WCAG 2.1 Level AA.

DOJ Title II compliance deadlines

Entity Type	Population	Compliance Deadline
State & local governments, large	50,000 or more	April 24, 2026
State & local governments, small	Under 50,000	April 26, 2027
Special district governments	Any	April 26, 2027

CivicCA is designed to help municipalities meet this requirement. The platform’s admin interface, public portal, and all generated documents (agendas, minutes, reports) are built to conform to WCAG 2.1 Level AA. By using CivicCA for agenda management, your municipality’s meeting content is published on an accessible, compliant platform from day one.

What This Means for Your Municipality

• Public portals — All meeting agendas, minutes, legislation, and documents served through CivicCA’s public portal meet WCAG 2.1 AA, helping satisfy your Title II obligations for meeting-related web content.
• Staff interfaces — The admin and staff dashboards are also WCAG 2.1 AA compliant, ensuring equitable access for all government employees regardless of ability.
• PDF documents — Agendas and minutes generated by CivicCA use real text (not images of text) and are structured for assistive technology.
• Ongoing compliance — Accessibility is built into our development process, not bolted on. Every feature release is evaluated against WCAG 2.1 AA criteria.

Shared Responsibility Model

Accessibility compliance under Title II is a shared responsibility between CivicCA (the platform provider) and the agency (the content owner). The table below clarifies what each party is responsible for.

Shared responsibility for accessibility compliance

CivicCA Is Responsible For	The Agency Is Responsible For
Accessibility of the platform, including all admin interfaces, public portal pages, navigation, forms, and interactive features	Accessibility of documents authored outside of CivicCA and uploaded to the platform (Word, PDF, Excel, etc.)
PDFs generated by CivicCA (agendas, minutes, action summaries, reports) — these use real text, proper heading structure, and are built for assistive technology	Ensuring uploaded attachments (staff reports, exhibits, correspondence) meet accessibility standards before publishing
Accessible HTML rendering of all meeting content on the public portal, including agenda items, voting records, and legislation	Providing descriptive text for agenda item titles and descriptions that are clear and meaningful
Video player accessibility (keyboard controls, ARIA attributes, iframe labeling)	Ensuring meeting videos hosted on YouTube or Zoom have captions enabled
Maintaining WCAG 2.1 AA conformance across all platform updates and new features	Reporting any accessibility issues encountered so they can be addressed promptly

How CivicCA Differs from Legacy Platforms

Unlike legacy agenda management systems, CivicCA was built from the ground up with accessibility as a core requirement — not a retrofit. Key differences include:

• PDFs generated by CivicCA are accessible by default. Agendas, minutes, and reports use real text with proper structure. You do not need to run them through Adobe Acrobat or third-party remediation tools before publishing.
• Public portal content is served as accessible HTML first. Meeting agendas, items, votes, and legislation are rendered as semantic HTML on the portal — not as downloadable PDFs that require separate remediation.
• No remediation roadmap needed for the platform. CivicCA conforms to WCAG 2.1 AA today. There are no critical or high-severity issues pending resolution.
• Accessibility is continuously validated. Every feature is evaluated against WCAG 2.1 AA criteria during development, not in semi-annual audits after the fact.

Testing Methodology

This assessment was conducted through:

• Code audit: Review of HTML templates, CSS stylesheets, and JavaScript source code
• Automated analysis: Evaluation of ARIA attributes, landmark structure, and semantic HTML patterns
• Standards reference: WCAG 2.1 Level A and AA success criteria
• Regulatory reference: DOJ Title II ADA final rule (28 CFR Part 35, published April 24, 2024)

Contact

For accessibility questions, feedback, or to request accommodations, contact: support@civicca.com

For procurement teams needing this report in an alternative format, please reach out and we will provide it within two business days.