VPAT 2.4 — WCAG 2.1 & Section 508
Accessibility Conformance Report
Voluntary Product Accessibility Template documenting how SentraCheck and its Accessible Document Viewer conform to WCAG 2.1 Level AA and Revised Section 508 standards.
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 6, 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.
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 viafor/id(the correct fix, since the visible label already existed), and 78 viaaria-labelwhere no visible label existed. - Identify Input Purpose (1.3.5):
autocompleteattributes 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:nonewith 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-liveregion. - 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
menupattern to a plaingroupof 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
langattribute, 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.1 — Level A
22 / 22 applicable
Full support — last gap (4.1.2, modal dialogs) closed August 2026
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 platform's one previously-open Level A item (4.1.2, modal dialog semantics) was closed in this report 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.1 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. |
Table 4: Robust
| Criteria | Conformance | Remarks |
|---|---|---|
| 4.1.1 Parsing | Supports | HTML output from the Document Viewer is valid HTML5. Elements have complete start and end tags, are correctly nested, and IDs are 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.1 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. |
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. |
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.1 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.1 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.1 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.