Accessibility
Accessibility Conformance Report
Voluntary Product Accessibility Template (VPAT®) 2.4 — WCAG 2.1 Edition
Self-assessed report. This VPAT reflects our internal testing against WCAG 2.1 Level AA criteria and is not an independent third-party accessibility audit. An external WCAG 2.1 AA conformance audit is planned for Q4 2026. Procurement teams who require a third-party attestation should email accessibility@thinkkits.com.
About This Report
This Accessibility Conformance Report (ACR) describes the accessibility of ThinkKits, an education data intelligence platform designed for K–12 procurement professionals, district administrators, and education vendors. The report follows the VPAT® 2.4 framework and evaluates conformance against the Web Content Accessibility Guidelines (WCAG) 2.1, Levels A and AA.
ThinkKits consists of two primary interfaces: a data-dense market intelligence dashboard designed with a dark Bloomberg-style UI, and a public help center. This report evaluates the authenticated platform experience available to subscribed users. Some criteria are noted as Partially Supports due to known contrast trade-offs inherent in the dark-theme design; these are documented candidly below along with planned remediation timelines.
This report was prepared by the ThinkKits engineering team based on internal review. It has not been validated by a third-party auditor. An independent audit is planned for Q3 2026.
Evaluation Scope
This report covers the following components:- ThinkKits authenticated SPA —
app.thinkkits.com(React 19, Vite 7) - Public help center —
thinkkits.com/help-center/ - Authentication flows powered by Clerk
- Public marketing pages at
thinkkits.com
Legend
Supports
Partially Supports
Does Not Support
Not Applicable
Principle 1: Perceivable
Information and user interface components must be presentable to users in ways they can perceive.
| Criterion | Level | Conformance | Remarks |
|---|---|---|---|
| 1.1.1 | Non-text Content A |
Partially Supports |
Most functional icons and buttons include aria-label attributes or adjacent visible text. Data visualization charts (school score charts, funding gap charts) include title elements and basic ARIA roles. However, some decorative SVG icons in the dashboard sidebar lack aria-hidden="true" markup, and complex chart tooltips do not provide full text equivalents. A data table fallback for all charts is planned for Q3 2026.
Planned remediation: Q3 2026 — add
aria-hidden to decorative icons; add accessible data table fallbacks for all charts. |
| 1.2.1 | Audio-only and Video-only (Prerecorded) A |
Not Applicable | ThinkKits does not include prerecorded audio-only or video-only content. |
| 1.2.2 | Captions (Prerecorded) A |
Not Applicable | No prerecorded video content is present in the current platform version. |
| 1.2.3 | Audio Description or Media Alternative (Prerecorded) A |
Not Applicable | No prerecorded video content is present. |
| 1.2.4 | Captions (Live) AA |
Not Applicable | No live audio or video content is delivered through the platform. |
| 1.2.5 | Audio Description (Prerecorded) AA |
Not Applicable | No prerecorded video content is present. |
| 1.3.1 | Info and Relationships A |
Partially Supports |
Page structure uses semantic HTML5 landmarks (<main>, <nav>, <header>, <footer>). Data tables in school and district views use <th> with scope attributes. Form inputs in search and filter panels are associated with visible labels. However, some dynamic dashboard cards use <div> containers with visual-only hierarchy cues (font size, weight) without corresponding ARIA landmark or heading structure. Score card relationships conveyed only through spatial proximity are not programmatically determinable.
Planned remediation: Q3 2026 — convert score card containers to use
role="region" with aria-labelledby. |
| 1.3.2 | Meaningful Sequence A |
Supports | Content is structured in logical DOM order matching visual presentation. CSS positioning is used for layout without reordering content from its semantic sequence. TanStack Router page transitions maintain document order. |
| 1.3.3 | Sensory Characteristics A |
Partially Supports |
Most instructions do not rely solely on sensory characteristics. However, certain UI states in the funding engine tool (e.g., tier eligibility indicators and score breakdowns) rely on color alone (green/amber/red) to convey status, without accompanying text labels or icons.
Planned remediation: Q3 2026 — add text labels to all color-coded status indicators.
|
| 1.3.4 | Orientation AA |
Supports | The platform does not restrict content to a single display orientation. All views are functional in both portrait and landscape orientations. |
| 1.3.5 | Identify Input Purpose AA |
Partially Supports |
Account profile fields (name, email, organization) use appropriate autocomplete attribute values. Search inputs and data filter fields do not use autocomplete attributes, which is acceptable as they are not personal data fields. However, the contact/inquiry form does not consistently apply autocomplete to all name and email fields.
|
| 1.4.1 | Use of Color A |
Partially Supports |
Color is not the sole means of conveying most information. Navigation active states, link underlines, and button states use multiple visual cues. However, in the dark-theme market intelligence tool, score tier categories (e.g., "High Priority" vs. "Medium Priority" districts) are differentiated by color (gold, amber, gray) without always including an accompanying icon or text label. This affects the school scoring map and vendor opportunity list.
Planned remediation: Q3 2026 — add icon indicators alongside color-coded tiers.
|
| 1.4.2 | Audio Control A |
Not Applicable | The platform does not play audio automatically. |
| 1.4.3 | Contrast (Minimum) AA |
Partially Supports |
This is a known, significant limitation of the dark Bloomberg-style UI. The primary dark interface uses a deep navy background (#0a1628, #0d1b2e) with the following contrast profile:
Planned remediation: Q3 2026 — audit and uplift all muted text tokens to minimum 4.5:1 on dark backgrounds. Interim workaround: users may use browser-level forced colors mode.
|
| 1.4.4 | Resize Text AA |
Supports | Text can be resized up to 200% using browser zoom without loss of content or functionality. The layout is responsive and reflows appropriately. No fixed-pixel font sizes are used in interactive areas. |
| 1.4.5 | Images of Text AA |
Supports | All text is rendered as actual text, not images of text. Charts and data visualizations use SVG with accessible title elements rather than rasterized images of text values. |
| 1.4.10 | Reflow AA |
Partially Supports |
Most pages reflow appropriately at 320px CSS width. The primary data dashboard with multi-column school/district comparison tables requires horizontal scrolling at narrow viewports, which may impact users relying on reflow. A simplified single-column layout for these views is planned.
Planned remediation: Q4 2026 — responsive table refactor for data-dense dashboard views.
|
| 1.4.11 | Non-text Contrast AA |
Partially Supports |
Interactive control boundaries (form inputs, buttons) against the dark #0d1b2e background generally meet 3:1 contrast for UI components. However, some secondary action buttons with rgba borders on dark panels have been measured at approximately 2.4:1, falling below the 3:1 minimum. Focus indicators for keyboard navigation meet the 3:1 threshold.
Planned remediation: Q3 2026 — uplift secondary button border tokens to meet 3:1 minimum.
|
| 1.4.12 | Text Spacing AA |
Supports | Overriding text spacing properties (line height 1.5x, letter spacing 0.12em, word spacing 0.16em, paragraph spacing 2x) via user stylesheet or extension does not cause loss of content or functionality. Tested with the Text Spacing bookmarklet. |
| 1.4.13 | Content on Hover or Focus AA |
Partially Supports |
Tooltip components triggered on hover include a 500ms delay and persist while the pointer remains within the component boundary. However, some chart data tooltips dismiss immediately when pointer exits the trigger element, preventing users from moving to and reading the tooltip content. Tooltip content is not keyboard-accessible in all cases.
Planned remediation: Q3 2026 — refactor chart tooltips to be keyboard-accessible and to persist appropriately.
|
Principle 2: Operable
User interface components and navigation must be operable.
| Criterion | Level | Conformance | Remarks |
|---|---|---|---|
| 2.1.1 | Keyboard A |
Partially Supports |
Core navigation, authentication, search, and primary data browsing actions are keyboard-accessible. The main navigation, data tables, pagination controls, and account settings are fully operable without a mouse. However, the interactive school map visualization (district geography view) and certain custom multi-select filter dropdowns in the vendor intelligence tool are not fully keyboard operable. Drag-and-drop functionality used in the report builder does not have a keyboard alternative.
Planned remediation: Q3 2026 — keyboard-accessible map controls and filter dropdowns; keyboard alternative for drag-and-drop report builder.
|
| 2.1.2 | No Keyboard Trap A |
Supports | No keyboard traps have been identified. Modal dialogs trap focus within the modal while open and return focus to the triggering element on close. All interactive components allow users to move away using standard keyboard controls. |
| 2.1.4 | Character Key Shortcuts A |
Supports | ThinkKits does not implement single-character keyboard shortcuts that could conflict with assistive technology key bindings. No character-key-only shortcuts are used. |
| 2.2.1 | Timing Adjustable A |
Supports | User session timeout is set to 24 hours via Clerk authentication. No short-duration time limits are imposed on task completion within the platform. The session warning is displayed with sufficient advance notice and can be extended by user action. |
| 2.2.2 | Pause, Stop, Hide A |
Supports | The platform does not include auto-playing animations, scrolling content, or blinking elements that move for more than five seconds. Loading skeleton animations are brief (<3 seconds) and do not persist. |
| 2.3.1 | Three Flashes or Below Threshold A |
Supports | The platform does not contain content that flashes more than three times per second. Loading indicators use smooth fade animations. No strobe effects or rapid transitions are used. |
| 2.4.1 | Bypass Blocks A |
Partially Supports |
A skip navigation link is present on the public help center pages. The authenticated SPA does not currently include a "skip to main content" link, which means keyboard and screen reader users must tab through the full sidebar navigation on every page load within the application.
Planned remediation: Q3 2026 — add skip-to-main-content link to SPA layout.
|
| 2.4.2 | Page Titled A |
Supports | All pages have descriptive <title> elements that describe the page topic. SPA route transitions update the document title via TanStack Router. Titles follow the format "Page Name — ThinkKits". |
| 2.4.3 | Focus Order A |
Partially Supports |
Focus order is logical and follows DOM order for most interfaces. However, when modal dialogs and slide-over panels are opened, focus is not always immediately moved to the dialog. Additionally, after closing a modal, focus does not consistently return to the element that triggered the dialog in all code paths.
Planned remediation: Q3 2026 — audit and fix focus management for all modal and panel components.
|
| 2.4.4 | Link Purpose (In Context) A |
Partially Supports |
Most links have descriptive text that communicates purpose in context. Pagination controls include aria-label attributes (e.g., "Next page of results"). However, some data table rows include "View" action links without sufficient context in the link text itself; assistive technology users may encounter multiple identical "View" links out of context.
Planned remediation: Q3 2026 — update action links to include entity name in aria-label (e.g., "View Aldine ISD profile").
|
| 2.4.5 | Multiple Ways AA |
Supports | Content is accessible via multiple navigation paths: main sidebar navigation, global search, and direct URL access. The help center includes a site search and topic-based index. |
| 2.4.6 | Headings and Labels AA |
Partially Supports |
Most pages use a clear heading hierarchy (H1 → H2 → H3). Form inputs have associated visible labels. However, certain dashboard panels and data cards use visual hierarchy (font weight, size) without corresponding heading markup, and some filter panels use visual group labels without <fieldset> and <legend> elements.
Planned remediation: Q3 2026 — semantic heading audit for all dashboard views; wrap filter groups in fieldset/legend.
|
| 2.4.7 | Focus Visible AA |
Partially Supports |
A visible focus indicator is present for interactive elements in most contexts. The global stylesheet defines a consistent focus ring using outline: 2px solid #f0c860 (gold) with outline-offset: 2px. However, some custom component overrides suppress the default focus ring without providing a sufficient replacement, particularly in the dark-theme sidebar navigation items and certain form inputs.
Planned remediation: Q3 2026 — global audit to ensure no component suppresses focus visibility without a WCAG 2.2-compliant replacement.
|
| 2.5.1 | Pointer Gestures A |
Partially Supports | Most functionality requires single-pointer activation. The report builder includes drag-and-drop functionality that currently requires multi-pointer gestures for some operations. A single-pointer alternative is not available for all drag-and-drop actions.
Planned remediation: Q3 2026 — add reorder buttons as single-pointer alternative to drag-and-drop.
|
| 2.5.2 | Pointer Cancellation A |
Supports | Activation of all interactive elements occurs on the up-event (mouseup/touchend), not the down-event. Users can cancel accidental activations by moving the pointer off the element before releasing. |
| 2.5.3 | Label in Name A |
Partially Supports | Most buttons and links have accessible names that include the visible label text. However, some icon-only buttons use aria-label values that do not match any visible label, and a small number of UI controls have accessible names that do not include the visible text string, potentially causing issues with voice control software.
Planned remediation: Q3 2026 — audit icon-button accessible names for voice control compatibility.
|
| 2.5.4 | Motion Actuation A |
Not Applicable | No platform functionality is triggered by device motion or orientation. Motion actuation is not used. |
Principle 3: Understandable
Information and the operation of the user interface must be understandable.
| Criterion | Level | Conformance | Remarks |
|---|---|---|---|
| 3.1.1 | Language of Page A |
Supports | All HTML pages include lang="en" on the <html> element. The platform is currently available in English only. |
| 3.1.2 | Language of Parts AA |
Not Applicable | ThinkKits is a single-language (English) platform. No content in other languages requiring lang attribute variation is present. |
| 3.2.1 | On Focus A |
Supports | No context changes occur as a result of a component receiving focus. Focus events do not trigger navigation, form submission, or other unexpected behavior. |
| 3.2.2 | On Input A |
Partially Supports |
Most form interactions require explicit submit actions. However, some filter controls in the school search tool automatically submit and reload results when a dropdown selection changes (without a separate submit button), causing context change on input. Users are not warned in advance of this behavior.
Planned remediation: Q3 2026 — add apply/submit button to auto-submit filter panels, or provide user advisory text.
|
| 3.2.3 | Consistent Navigation AA |
Supports | Navigation components appear in the same relative order across all pages of the platform. The primary sidebar navigation, top header, and account controls are consistently positioned throughout the SPA. |
| 3.2.4 | Consistent Identification AA |
Supports | Components with the same functionality are identified consistently throughout the platform. Search inputs, save buttons, export controls, and tier-gating "Upgrade" prompts use consistent labels and accessible names across all tools. |
| 3.3.1 | Error Identification A |
Supports | Form validation errors are identified both visually (red border, error icon) and with descriptive text messages adjacent to the affected field. Error messages describe the nature of the problem (e.g., "Email address is required" rather than generic "Error"). Fields with errors are associated with error messages via aria-describedby. |
| 3.3.2 | Labels or Instructions A |
Supports | All form fields have visible labels. Required fields are marked with an asterisk and adjacent explanatory text ("* Required field"). Complex search filter panels include brief instructional text explaining filter behavior. |
| 3.3.3 | Error Suggestion AA |
Partially Supports |
Validation errors for most form fields include specific correction guidance (e.g., "Enter a valid email address in the format name@domain.com"). However, some complex search query errors return a generic "Invalid search format" message without specific guidance on correct syntax.
Planned remediation: Q4 2026 — improve search error messages with syntax examples and correction guidance.
|
| 3.3.4 | Error Prevention (Legal, Financial, Data) AA |
Supports | All subscription plan changes and purchase order submissions require explicit confirmation via a two-step confirmation dialog. Users can review and correct their selections before finalizing. Stripe handles all payment processing with its own built-in confirmation flow. |
Principle 4: Robust
Content must be robust enough to be reliably interpreted by a wide variety of user agents, including assistive technologies.
| Criterion | Level | Conformance | Remarks |
|---|---|---|---|
| 4.1.1 | Parsing A |
Supports | HTML output passes W3C validation with no critical parsing errors. React 19's server-rendered and client-hydrated markup produces valid HTML5. Element IDs are unique within each rendered page. Deprecated per WCAG 2.2 errata: this criterion is generally satisfied by modern browsers and is included for completeness. |
| 4.1.2 | Name, Role, Value A |
Partially Supports |
Standard HTML elements (buttons, links, inputs, checkboxes, selects) expose correct name, role, and value to accessibility APIs. Custom interactive components built with <div> elements (e.g., custom toggle switches, star rating selectors, and the tier comparison slider) are missing required ARIA roles and properties in some cases. Live region updates (e.g., search result count changes, data loading notifications) are not consistently announced via aria-live regions.
Planned remediation: Q3 2026 — custom component ARIA audit; add aria-live regions to all dynamic content update areas.
|
| 4.1.3 | Status Messages AA |
Partially Supports |
Toast notifications (success, error, warning) are rendered in a container with role="alert" and aria-live="polite" for most use cases. However, loading state messages (e.g., "Fetching district data...") and inline form success confirmations do not consistently use ARIA live regions, meaning screen reader users may not receive status updates without moving focus.
Planned remediation: Q3 2026 — audit all status message patterns; add aria-live="polite" or role="status" to all non-focus-receiving status areas.
|
Conformance Summary
Overall conformance level by WCAG 2.1 principle.
| Principle | Supports | Partially Supports | Does Not Support | Not Applicable |
|---|---|---|---|---|
| 1. Perceivable | 5 | 8 | 0 | 5 |
| 2. Operable | 5 | 7 | 0 | 2 |
| 3. Understandable | 5 | 2 | 0 | 1 |
| 4. Robust | 1 | 2 | 0 | 0 |
| Total (38 criteria) | 16 | 19 | 0 | 8 |
Remediation Roadmap
ThinkKits is committed to improving accessibility. The following timeline covers known issues identified in this report:
Q3 2026 (July–September): Dark-theme contrast uplift (muted text tokens); skip-to-main-content link in SPA; focus management audit for modals and panels; chart tooltip keyboard accessibility; aria-live regions for status messages; custom component ARIA audit (name, role, value); action link context improvement; icon-only button accessible name audit.
Q4 2026 (October–December): Responsive table refactor for data-dense dashboard views; improved search error suggestion messages; full independent third-party WCAG 2.1 AA audit.
We will publish an updated VPAT following the completion of the Q3 2026 remediation sprint and the independent audit.
Feedback and Accessibility Support
We welcome feedback from users with disabilities. If you encounter an accessibility barrier not documented in this report, or need content in an alternative format, please contact us:
Email: support@thinkkits.com
Subject line: Accessibility — [brief description of issue]
Response time: We aim to respond to accessibility inquiries within 2 business days.
If the platform does not meet your accessibility needs, we will work to provide an equally effective alternative means of access.