Accessibility Conformance Report (VPAT 2.5)

Product Information

Product NameSentraCheck

Product VersionCurrent (SaaS — continuously updated)

Product DescriptionAI-powered compliance and document accessibility platform for government agencies and organizations

Vendor / DeveloperComputer Systems Plus, Inc. (SentraCheck)

Report DateAugust 8, 2026

Contactsupport@sentracheck.com

Covered Components

This report covers two primary components of the SentraCheck product:

SentraCheck Platform — The web application used by agency staff to upload documents, run accessibility scans, manage VPAT reports, and view compliance dashboards (sentracheck.com/app/).
SentraCheck Accessible Document Viewer — A publicly accessible, token-authenticated viewer that renders AI-converted, WCAG-compliant HTML versions of agency documents for the public (sentracheck.com/viewer.html).

Evaluation Method: This report is based on a self-assessment conducted by SentraCheck developers using manual testing, keyboard navigation testing, screen reader testing (NVDA + Chrome, VoiceOver + Safari), and automated tooling (axe-core). The August 2026 update below additionally involved a source-level accessibility audit of the platform and viewer codebases: full-codebase scans for missing accessible names, icon labeling, and heading structure; WCAG contrast-ratio calculation (relative luminance formula, 4.5:1 / 3:1 thresholds) against the actual CSS color values in use; and manual tracing of keyboard interaction code (focus handling, Escape behavior, ARIA state changes). A live assistive-technology re-verification pass and an independent third-party audit are both planned for Q3 2026.

Upgrade to VPAT 2.5 / WCAG 2.2 (August 2026): This edition moves the report from VPAT 2.4 to VPAT 2.5 and from WCAG 2.1 to WCAG 2.2. WCAG 2.2 retains every WCAG 2.1 success criterion, so all prior determinations carry forward unchanged. The six success criteria new to WCAG 2.2 at Level A and AA — 3.2.6 Consistent Help, 3.3.7 Redundant Entry, 2.4.11 Focus Not Obscured (Minimum), 2.5.7 Dragging Movements, 2.5.8 Target Size (Minimum), and 3.3.8 Accessible Authentication (Minimum) — were each evaluated for this edition rather than carried over, by source-level review of the layout, interaction, and authentication code paths they govern. That review found one new gap — undersized range slider thumbs, at 2.5.8 — which was corrected before this report was published rather than disclosed as an open exception. Success criterion 4.1.1 Parsing, which WCAG 2.2 removes, is retained in the table below marked obsolete and is excluded from the conformance totals. The three Level AAA criteria added by WCAG 2.2 (2.4.12, 2.4.13, 3.3.9) are outside the Level A and AA scope of this report.

August 2026 Remediation Update: A source-level accessibility audit identified and corrected the following gaps since the prior report:

Contrast (1.4.3): A body-text color used at ~4.1:1 in the platform's dark theme (below the 4.5:1 minimum) was corrected across every occurrence — over 1,000 instances fixed via a single CSS-level change, in both dark and light themes.
Labels or Instructions (3.3.2): 261 form controls across 41 platform pages that lacked an accessible name were fixed — 183 by connecting existing visible <label> text via for/id (the correct fix, since the visible label already existed), and 78 via aria-label where no visible label existed.
Identify Input Purpose (1.3.5): autocomplete attributes were added to all identified personal-information fields (name, email, password, organization) across 12 platform pages.
Non-text Content (1.1.1): All decorative icons across the platform (850 instances, 78 files) and the Document Viewer were confirmed or corrected to use aria-hidden, and a redundant error-state icon in the viewer was hidden from assistive technology.
Label in Name (2.5.3): 117 icon-only buttons across the platform, and three text-size buttons in the Document Viewer, were given accessible names that contain their visible label text.
Non-text Contrast (1.4.11): The Document Viewer's search box border (~1.2:1) and toolbar button borders (~1.9:1) were raised to 3.5:1+; a keyboard range slider used in the platform's breach risk-assessment tool had no focus indicator at all (outline:none with no replacement) and now has one.
Bypass Blocks (2.4.1) & Status Messages (4.1.3): A "Skip to main content" link was added to the Document Viewer; toast notifications platform-wide were converted to an aria-live region.
Keyboard operability: The Document Viewer's Translate control previously closed only via mouse click outside it; it now closes on Escape with focus returned to the trigger, and its ARIA role was corrected from an incompletely-implemented menu pattern to a plain group of buttons.
Name, Role, Value (4.1.2): None of the platform's 43 modal dialogs exposed role="dialog", an accessible name, a keyboard focus trap, or focus restoration on close — each page hand-rolled its own show/hide logic with no shared accessibility behavior. Rather than editing each page individually, a single central utility was added that detects any modal being opened or closed (by its existing markup shape) and automatically applies all of the above, verified with an automated test suite against both the standard modal markup and a legacy variant used on one page.
Language of Parts (3.1.2): Inline foreign-language passages in converted documents relied entirely on the AI conversion engine's own judgment to tag with a lang attribute, with no verification step. A deterministic backstop was added to the conversion pipeline for the six of eleven supported languages that use a distinct Unicode script (Chinese, Korean, Russian, Khmer, Lao, Punjabi) — these are detected by script range rather than inferred, closing the highest-severity cases (where an unmarked language switch causes a screen reader to mispronounce every character, not just accent words oddly). The five Latin-alphabet languages still depend on the AI's own judgment; see Table 7.

Conformance Scorecard

Counts below exclude criteria marked Not Applicable, per standard VPAT practice — the denominator is criteria actually applicable to SentraCheck.

WCAG 2.2 — Level A

22 / 22 applicable

Full support — includes 3.3.7 Redundant Entry, new in WCAG 2.2

WCAG 2.2 — Level AA

21 / 22 applicable

1 criterion Partially Supports — see 3.1.2 Language of Parts

Section 508

6 / 6 applicable

Chapters 5 & 6, full support

The SentraCheck Accessible Document Viewer specifically — the component members of the public interact with directly — has no known open conformance gaps as of this report. The one open exception sits in the staff-facing platform: 3.1.2 Language of Parts. The target-size gap found at 2.5.8 during this evaluation was corrected before publication rather than carried as an exception. The platform's one previously-open Level A item (4.1.2, modal dialog semantics) was closed in an earlier cycle; see the remediation update below.

Terms Used in This Report

Supports

The functionality of the product meets the criterion without any known deficiencies.

Partially Supports

Some functionality does not meet the criterion. Known exceptions are described in the remarks.

Does Not Support

The majority of product functionality does not meet the criterion.

Not Applicable

The criterion is not relevant to this product.

Not Evaluated

The product has not been evaluated against this criterion.

WCAG 2.2 Success Criteria — Level A

Table 1: Perceivable

Criteria	Conformance	Remarks
1.1.1 Non-text Content	Supports	Images within accessible document output include AI-generated alternative text. Decorative icons across the platform (850 instances, 78 pages) and the Document Viewer (8 icons) are confirmed to use `aria-hidden`; a redundant error-state icon in the viewer was corrected in August 2026. Viewer toolbar buttons all have programmatic labels.
1.2.1 Audio-only and Video-only	Not Applicable	SentraCheck does not produce or embed audio-only or video-only content.
1.2.2 Captions (Prerecorded)	Not Applicable	No prerecorded audio content is present.
1.2.3 Audio Description or Media Alternative	Not Applicable	No synchronized media is present.
1.3.1 Info and Relationships	Supports	The Document Viewer outputs semantic HTML5: headings (h1–h6), lists, data tables with thead/tbody, paragraphs, and definition lists. The platform uses ARIA landmarks (main, nav, banner, contentinfo) throughout.
1.3.2 Meaningful Sequence	Supports	DOM order in converted documents reflects the logical reading sequence of the source. AI conversion preserves document structure and reading order.
1.3.3 Sensory Characteristics	Supports	Instructions do not rely on shape, color, size, visual location, orientation, or sound as the sole means of identification.
1.4.1 Use of Color	Supports	Color is never the sole means of conveying information. Status indicators and compliance badges include text labels alongside color coding.
1.4.2 Audio Control	Not Applicable	No audio plays automatically.

Table 2: Operable

Criteria	Conformance	Remarks
2.1.1 Keyboard	Supports	All viewer controls (font size, print, translate, download) are keyboard accessible via Tab and Enter/Space. Converted document content — headings, links, and tables — is fully keyboard navigable.
2.1.2 No Keyboard Trap	Supports	No keyboard traps exist. Modal dialogs and dropdowns release focus via the Escape key.
2.1.4 Character Key Shortcuts	Not Applicable	No single-character keyboard shortcuts are implemented.
2.2.1 Timing Adjustable	Not Applicable	No time limits are set on viewer content or document interaction.
2.2.2 Pause, Stop, Hide	Not Applicable	No auto-updating, blinking, scrolling, or moving content is present.
2.3.1 Three Flashes or Below Threshold	Supports	No flashing or strobing content exists anywhere in the product.
2.4.1 Bypass Blocks	Supports	The Document Viewer includes a visually hidden "Skip to main content" link as the first focusable element, targeting a focusable main landmark, allowing keyboard users to bypass the toolbar and go directly to document content. Verified present and correctly wired in the live viewer.
2.4.2 Page Titled	Supports	The viewer page title is set dynamically to the document filename (e.g., "Budget-Report-2026.pdf — SentraCheck"). All platform pages have descriptive, unique titles.
2.4.3 Focus Order	Supports	Focus order follows a logical, meaningful sequence matching the visual presentation throughout the viewer and platform.
2.4.4 Link Purpose (In Context)	Supports	All links have descriptive text or accessible names via `aria-label`. Ambiguous link text includes surrounding context or an explicit aria-label.
2.5.1 Pointer Gestures	Supports	No multi-point or path-based gestures are required. All functionality is operable with a single pointer.
2.5.2 Pointer Cancellation	Supports	Actions are triggered on the up-event, allowing users to cancel accidental activations by moving the pointer away.
2.5.3 Label in Name	Supports	Accessible names for interactive components contain or begin with the visible text label. 117 icon-only buttons across the platform were audited and labeled without disturbing 38 buttons that already had correct visible text (avoiding a conflicting duplicate label); the Document Viewer's text-size buttons ("A−"/"A"/"A+") were corrected in August 2026 so their `aria-label` now begins with the visible glyph shown on screen.
2.5.4 Motion Actuation	Not Applicable	No functionality is triggered by device motion or user movement.

Table 3: Understandable

Criteria	Conformance	Remarks
3.1.1 Language of Page	Supports	The viewer sets `lang="en"` by default. When the conversion process detects a non-English document, the `lang` attribute is updated accordingly (e.g., `lang="es"` for Spanish). Verified all 78 platform pages declare a page language.
3.2.1 On Focus	Supports	No context changes are initiated solely by a component receiving focus.
3.2.2 On Input	Supports	No unexpected context changes occur on input. Form submissions require explicit user action.
3.3.1 Error Identification	Supports	Input errors are identified in text and described specifically. Error messages are marked `role="alert"` and associated with their fields via `aria-describedby` on the sign-in and registration forms.
3.3.2 Labels or Instructions	Supports	All form inputs have accessible labels. A full-codebase audit in August 2026 found and fixed 261 form controls across 41 pages that lacked one — the large majority by connecting an already-present visible `<label>` via `for`/`id`, the remainder via `aria-label`. Required fields are marked. Format requirements are stated before submission.
3.2.6 Consistent Help New in 2.2	Not Applicable	The application does not currently repeat a help mechanism (contact details, live chat, or a help link) across multiple pages, so there is no repeated mechanism whose relative order could vary. Support contact information is published on the public website rather than persistently within the application. A persistent in-application support link is planned; when added it will be placed in the same relative position on every page.
3.3.7 Redundant Entry New in 2.2	Supports	Multi-step processes (the breach reporting wizard, BAA signing, and document upload flows) are implemented as single pages that show and hide steps rather than reloading, so information entered in an earlier step remains populated and is never requested twice within the same process. Where a value is already known to the system — organization details, signer name and email on the BAA — it is pre-filled from the account record rather than re-entered.

Table 4: Robust

Criteria	Conformance	Remarks
4.1.1 Parsing Obsolete in 2.2	Not Applicable	This success criterion was removed from WCAG 2.2 and is deprecated in WCAG 2.1; it is therefore excluded from the conformance totals. For reference, the underlying property still holds: HTML output from the Document Viewer is valid HTML5, with complete start and end tags, correct nesting, and IDs unique within each page.
4.1.2 Name, Role, Value	Supports	All interactive components expose accessible names, roles, and states to assistive technologies via native HTML semantics or ARIA. 261 previously-unlabeled form controls were fixed platform-wide in August 2026. Platform modal dialogs (43 across the application) are auto-enhanced with `role="dialog"`, `aria-modal`, an accessible name derived from the dialog's own heading, a keyboard focus trap, and focus restoration to the triggering control on close — implemented centrally so every modal gets the same behavior regardless of which page opens it, verified with an automated test suite covering both the standard modal markup and a legacy variant. The Document Viewer's Translate control was similarly corrected from an incompletely-implemented `menu` pattern to a plain `group` of buttons, closing on Escape with focus returned to the trigger.

WCAG 2.2 Success Criteria — Level AA

Table 5: Perceivable

Criteria	Conformance	Remarks
1.2.4 Captions (Live)	Not Applicable	No live audio content is present.
1.2.5 Audio Description (Prerecorded)	Not Applicable	No prerecorded video with audio is present.
1.3.4 Orientation	Supports	The viewer and platform function in both portrait and landscape orientations. Content is not restricted to a single display orientation.
1.3.5 Identify Input Purpose	Supports	Input fields collecting personal information include appropriate `autocomplete` attribute values to assist users and assistive technologies. An August 2026 audit added the attribute to every identified personal-information field (name, email, password, organization) across 12 platform pages.
1.4.3 Contrast (Minimum)	Supports	Document Viewer body text meets a minimum 4.5:1 contrast ratio, verified by calculation against the actual CSS colors in use. The dark toolbar (navy background) uses white text at >7:1. A platform-wide secondary text color previously rendering at ~4.1:1 in the dark theme (below the 4.5:1 minimum) was corrected in August 2026 across all 1,000+ occurrences in both themes.
1.4.4 Resize Text	Supports	The viewer includes built-in font size controls (Small, Medium, Large, X-Large). Text can also be resized to 200% via browser zoom without loss of content or functionality.
1.4.5 Images of Text	Supports	The Document Viewer converts source PDFs to real HTML text, not images. Scanned image PDFs are OCR-processed to extract actual text before conversion. No document content is presented as an image of text.
1.4.10 Reflow	Supports	Content reflows at 320 CSS pixels width without horizontal scrolling. The viewer uses a fluid single-column layout. Wide tables in converted documents are wrapped in scrollable containers.
1.4.11 Non-text Contrast	Supports	UI components (buttons, form inputs, focus indicators) meet the 3:1 minimum contrast ratio against adjacent colors. An August 2026 audit found and corrected three Document Viewer gaps: the search box border (previously ~1.2:1, now 3.5:1+), toolbar button borders (previously ~1.9:1, now 3.5:1+), and a keyboard range slider in the platform's breach risk-assessment tool that had no focus indicator at all (now has a visible 2px outline).
1.4.12 Text Spacing	Supports	No loss of content or functionality occurs when letter spacing, word spacing, line height, and paragraph spacing are overridden to WCAG 2.1 SC 1.4.12 values.
1.4.13 Content on Hover or Focus	Supports	Tooltips and dropdowns triggered by hover or focus are persistent, hoverable, and dismissable via Escape without moving focus.

Table 6: Operable

Criteria	Conformance	Remarks
2.4.5 Multiple Ways	Supports	The platform provides multiple ways to locate content: navigation sidebar, search, and direct links. The Document Viewer is a single-purpose page and is exempt from this requirement.
2.4.6 Headings and Labels	Supports	All page sections and form controls have descriptive headings and labels (see 3.3.2). Converted document headings reflect the source document's hierarchy (h1–h6). Each platform page uses a single `<h1>`, verified against the live rendered DOM.
2.4.7 Focus Visible	Supports	Keyboard focus is visible at all times. A clearly visible focus ring (blue outline, minimum 2px) is displayed on all interactive elements.
2.4.11 Focus Not Obscured (Minimum) New in 2.2	Supports	Neither component overlays scrolling content with sticky or floating chrome. The Document Viewer’s toolbar is a fixed-height flex sibling of the document pane, not an overlay, so document content scrolls beneath its own region and a focused element can never pass under it. In the platform, the navigation sidebar is fixed to the left edge at 260 px and the main content region carries a matching 260 px left margin, so the two never overlap. On narrow viewports the sidebar becomes an explicitly opened drawer with focus contained inside it.
2.5.7 Dragging Movements New in 2.2	Supports	The only dragging interaction in either component is the optional drawn signature on the Business Associate Agreement page. A typed signature is offered as an equivalent single-pointer alternative that produces the same legally recorded signature, so no function requires a dragging movement. No drag-and-drop reordering, drag-to-select, or drag-to-annotate interaction exists elsewhere in the platform or viewer.
2.5.8 Target Size (Minimum) New in 2.2	Supports	Buttons, links, form controls, and viewer toolbar controls meet or exceed the 24 × 24 CSS pixel minimum, and viewer toolbar controls increase to roughly 36 px tall on touch viewports. Range slider thumbs (the breach risk-assessment scoring controls and the redaction confidence control) were measured at 18 × 18 CSS pixels during this evaluation and were enlarged to 24 × 24 in August 2026; the slider’s own element box was raised to 24 px to match, with the 6 px visual track moved onto the track pseudo-elements so the control looks unchanged and only the hit area grew. These sliders are also operable from the keyboard with arrow keys and carry accessible names and a visible focus indicator.

Table 7: Understandable

Criteria	Conformance	Remarks
3.1.2 Language of Parts	Partially Supports	Page language is always set correctly. Inline language changes within converted documents are marked with `lang` attributes primarily by the AI conversion engine's own judgment. In August 2026, a deterministic backstop was added for six of the eleven supported languages — Chinese, Korean, Russian, Khmer, Lao, and Punjabi — which use dedicated Unicode script blocks that don't otherwise appear in an English document, so detection for these is exact rather than AI-inferred, verified with an automated test suite (10 tests). The remaining five supported languages (Spanish, French, Vietnamese, Tagalog, Hmong) share the Latin alphabet with English and still depend on the AI conversion engine correctly recognizing them during conversion; detection for these is not guaranteed complete.
3.2.3 Consistent Navigation	Supports	Navigation mechanisms appear in the same location and order across all platform pages. The sidebar navigation is consistent throughout the application.
3.2.4 Consistent Identification	Supports	Components with the same function across pages are consistently identified with the same name, label, or accessible name.
3.3.3 Error Suggestion	Supports	When input errors are detected, specific correction suggestions are provided where feasible and security permits (e.g., "Password must be at least 8 characters and include a number").
3.3.4 Error Prevention (Legal, Financial, Data)	Supports	Destructive actions require confirmation. Submissions can be reviewed before final confirmation. Users can cancel before committing.
3.3.8 Accessible Authentication (Minimum) New in 2.2	Supports	Sign-in requires no cognitive function test. Authentication is handled by an embedded third-party identity component (Clerk) offering three paths, any one of which is sufficient: email and password, a one-time code sent by email, and Microsoft single sign-on. Password fields use standard `autocomplete` values and do not block pasting, so password managers and browser autofill work normally. No puzzle, image-recognition, or transcription challenge is presented in the standard sign-in flow. Because the sign-in interface is rendered by a third party, its behavior is reviewed at each report cycle rather than assumed.

Table 8: Robust

Criteria	Conformance	Remarks
4.1.3 Status Messages	Supports	Status messages (conversion progress, upload success/failure, scan completion) are implemented as `aria-live` regions, announced by screen readers without requiring focus to move. Platform-wide toast notifications were converted to a `role="status" aria-live="polite"` region in August 2026. Loading states use `aria-busy` where appropriate, including the Document Viewer's loading overlay and search result count.

Revised Section 508 — Chapter 5: Software

The Revised Section 508 Technical Standards incorporate WCAG 2.0 Level A and AA by reference for web-based software. SentraCheck’s conformance to WCAG 2.2 Level A and AA (detailed above) addresses the Section 508 web accessibility requirements.

Criteria	Conformance	Remarks
501.1 Scope	Supports	SentraCheck is web-based software covered under Chapter 5. Requirements are addressed via WCAG 2.2 Level AA conformance documented above.
502 Interoperability with Assistive Technology	Supports	Tested with NVDA + Chrome (Windows) and VoiceOver + Safari (macOS/iOS). The viewer and platform are operable with standard screen readers without special configuration.
503 Applications	Supports	SentraCheck does not override user preferences for platform display settings. User-set font sizes, high-contrast modes, and color inversion settings are respected.
504 Authoring Tools	Supports	SentraCheck functions as an authoring tool for accessible documents. The Document Viewer output is WCAG 2.2 Level AA conformant HTML, enabling agencies to publish accessible content to the public.

Chapter 6: Support Documentation and Services

Criteria	Conformance	Remarks
602 Support Documentation	Supports	Product documentation describes accessibility features, keyboard shortcuts, and how to use the product with assistive technologies. Available at sentracheck.com/support.html.
603 Support Services	Supports	Technical support is available via email (support@sentracheck.com) and by phone (559-251-7767). Support staff can assist users with assistive technology needs.

Contact & Legal Disclaimer

Accessibility Contactsupport@sentracheck.com

Phone559-251-7767

Address2134 North Fine Ave, Fresno, CA 93727

Next ReviewFebruary 2027 (semi-annual)

This report was completed by SentraCheck development staff. The information provided reflects the state of the product as of the report date. We welcome feedback from users and procurement teams.

If you experience any accessibility barriers while using SentraCheck, please contact us at support@sentracheck.com with a description of the issue and the assistive technology you are using. We will respond within 2 business days.

Legal Disclaimer: This accessibility conformance report is provided for informational purposes only. It represents a good-faith self-assessment and does not constitute a legal warranty or guarantee of accessibility. SentraCheck continually works to improve accessibility and will update this report as the product evolves. Government agencies requiring formal third-party audits should contact us to discuss assessment options.