Accessibility Conformance Report
VPAT® 2.5 – Revised Section 508 Edition
A self-assessment of www.storsoftcorp.com against the Revised Section 508 standards (36 CFR Part 1194), including Chapter 3 Functional Performance Criteria and WCAG 2.1 Level A and Level AA success criteria (a superset of the WCAG 2.0 AA baseline Revised 508 incorporates by reference). Prepared by StorSoft Technology Corp for federal, state and local, and commercial buyers evaluating this site as a vendor property.
Applicable Standards/Guidelines
| Standard/Guideline | Included in Report |
|---|---|
| Web Content Accessibility Guidelines 2.1 (Level A, AA) | Yes – assessed as a superset of the WCAG 2.0 Level AA baseline Revised Section 508 incorporates by reference (36 CFR 1194, Chapter 5 / E205.4). |
| Revised Section 508 – Chapter 3: Functional Performance Criteria (302.1–302.9) | Yes – see the Chapter 3 table below. |
| Revised Section 508 – Chapter 4: Hardware | No – this product is a website; no hardware is distributed. See the Chapter 4 note below. |
| Revised Section 508 – Chapter 5: Software | Yes – fulfilled by the WCAG 2.1 success criteria tables below (web content, per E205.4). |
| Revised Section 508 – Chapter 6: Support Documentation and Services | No – no separately distributed end-user documentation or support-services product exists apart from the website itself. See the Chapter 6 note below. |
Summary
Of 50 WCAG 2.1 Level A and AA success criteria, 38 are assessed as fully supported and 9 do not apply to this site (it carries no audio, video, or financial/legal transaction content). 3 criteria are partially supported; each is itemized below with the specific, disclosed gap rather than a blanket claim.
Product description
www.storsoftcorp.com is the corporate website of StorSoft Technology Corp, a HUBZone-certified, Small Disadvantaged Business (self-certified) IT enterprise solutions firm. The site presents capability, contract-vehicle, past-performance, and training catalog information to public-sector and commercial buyers, and accepts inquiries through a Request Center intake form. It is a server-rendered Next.js application; there is no separately distributed software product.
Evaluation methods used
- Automated scanning with axe-core (WCAG 2.0 and 2.1, Level A and AA rule sets) across 42 representative routes – every distinct page template, market page, and contract-vehicle page – in both light and dark color schemes, via Playwright. This does not include a separate scan of each of the approximately 2,900 individual course pages generated from the training catalog database; those pages share the same template already covered, but each course’s specific description and prerequisite text was not individually re-verified. See the coverage note below.
- Manual code review of semantic structure, landmark regions, ARIA usage, and keyboard interaction patterns.
- Live, hands-on keyboard verification against the production deployment: Tab-order sequencing and focus visibility across the VPAT, Request Center, and Capabilities pages; confirmed no positive tabindex values, no duplicate element IDs, and every form control has a programmatically associated label. Confirmed the mobile navigation dialog’s Escape-to-close behavior with a real, trusted keyboard event. Native Enter/Space activation of focused buttons could not be driven end-to-end through this session’s browser-automation tooling (a documented limitation of synthetic key dispatch, not specific to this site – confirmed by testing a freshly-injected, unrelated control on the same page, which showed the identical gap); reliance for that behavior is on standard native
<button>semantics, which real browsers and assistive technology activate via Enter/Space by specification. This is disclosed rather than silently assumed – see “Not performed” below. - Automated accessibility-tree audit (the same role/name/state tree assistive technology consumes) on representative pages: verified accessible names exist for every interactive element, no keyboard-trap- prone positive tabindex usage, and every form field resolves to a label. This is a structural check, not a substitute for testing with actual assistive technology software – see “Not performed” below.
- Manual computed-color-contrast verification of specific UI elements flagged during review.
- Live testing at WCAG’s exact prescribed technical conditions for 1.4.10 Reflow (320 CSS pixel width), 1.4.4 Resize Text (the documented 200%-zoom-equivalent width), and 1.4.12 Text Spacing (the prescribed CSS override injected at runtime), checked for horizontal scrolling and clipped or overlapping content.
Not performed:testing with actual assistive technology software (screen readers such as NVDA/JAWS/VoiceOver, switch devices, or voice control software) operated by a person, including one who relies on it daily. The accessibility-tree audit above checks the same data those tools read, but it is not a substitute for testing with the tools themselves, which can surface issues (announcement phrasing, reading-order surprises, live-region timing) that structural checks miss. Also not performed: an individual axe-core scan of each training course detail page (see the coverage note above – roughly 2,900 pages share a template that was scanned once, not scanned per-page). The downloadable PDF version of this report is tagged and includes a bookmark outline (verified page-by-page to contain every page’s content), but that tagged structure has not been run through a formal PDF accessibility validator (PAC, veraPDF) or opened with a screen reader to confirm reading order and announcement behavior. This report is a vendor self-assessment, not an independent third-party audit.
Chapter 3: Functional Performance Criteria
Provisions and requirement text below are quoted from 36 CFR Appendix C to Part 1194 (the Revised Section 508 standards).
| Criterion | Conformance | Remarks |
|---|---|---|
| 302.1 Without Vision | Partially Supports | Core functions (navigation, forms, catalog browsing) are built on semantic HTML, ARIA, and keyboard operability rather than visual cues, and automated/structural checks found no barriers (see Evaluation methods used). Rated Partially Supports rather than Supports because this provision is fundamentally about the actual experience of a person using screen-reading software, which has not been verified with real assistive technology. |
| 302.2 With Limited Vision | Supports | Text resizes and reflows without loss of content or function (1.4.4, 1.4.10 above); color contrast independently verified. |
| 302.3 Without Perception of Color | Supports | No information is conveyed by color alone (1.4.1 above). |
| 302.4 Without Hearing | Not Applicable | The site has no audio content requiring hearing. |
| 302.5 With Limited Hearing | Not Applicable | No audio content. |
| 302.6 Without Speech | Supports | No feature requires speech input; all interaction is via standard keyboard, pointer, and form controls. |
| 302.7 With Limited Manipulation | Supports | No feature requires fine motor control or simultaneous manual operations; verified no path-based or multi-point gestures are used (2.5.1 above). |
| 302.8 With Limited Reach and Strength | Supports | Standard-sized interactive controls throughout; target sizing reviewed against the 44px guideline. |
| 302.9 With Limited Language, Cognitive, and Learning Abilities | Partially Supports | Consistent navigation and labeling, clear error identification, and plain page structure are in place (3.2.3, 3.2.4, 3.3.1 above), but no formal plain-language/readability audit or testing with users with cognitive disabilities has been performed. |
Chapter 5: Software – WCAG 2.1 Success Criteria
The Revised Section 508 standard incorporates WCAG 2.0 Level AA by reference for web content (36 CFR 1194, Chapter 5 / E205.4); this is how Chapter 5’s software requirements apply to a website. The tables below assess against WCAG 2.1 Level A and AA instead – a strict superset of that formal baseline, and the standard already targeted site-wide (see https://www.storsoftcorp.com/accessibility).
1. Perceivable
| Criterion | Level | Conformance | Remarks |
|---|---|---|---|
| 1.1.1 Non-text Content | A | Supports | Informative images carry descriptive alt text; decorative graphics (topic thumbnails, chart marks) are marked aria-hidden. No missing alt text found across sampled routes. |
| 1.2.1 Audio-only and Video-only (Prerecorded) | A | Not Applicable | The site contains no audio or video content. |
| 1.2.2 Captions (Prerecorded) | A | Not Applicable | No video content. |
| 1.2.3 Audio Description or Media Alternative (Prerecorded) | A | Not Applicable | No video content. |
| 1.2.4 Captions (Live) | AA | Not Applicable | The site has no live audio or video content. |
| 1.2.5 Audio Description (Prerecorded) | AA | Not Applicable | No video content. |
| 1.3.1 Info and Relationships | A | Supports | Semantic landmarks (header/nav/main/footer), heading hierarchy, list and definition-list markup, and label-input association verified via automated scan and manual review. |
| 1.3.2 Meaningful Sequence | A | Supports | DOM order matches visual reading order; no CSS reordering that alters sequence. |
| 1.3.3 Sensory Characteristics | A | Supports | Instructions do not rely solely on shape, size, visual location, or sound. |
| 1.3.4 Orientation | AA | Supports | No CSS restricts display to a single orientation; layouts verified responsive from 390px through desktop widths. |
| 1.3.5 Identify Input Purpose | AA | Supports | Common form fields (name, email, organization) use standard HTML autocomplete attributes. |
| 1.4.1 Use of Color | A | Supports | Links and form-error states are distinguished by text, weight, and position, not color alone. |
| 1.4.2 Audio Control | A | Not Applicable | No audio auto-plays on the site. |
| 1.4.3 Contrast (Minimum) | AA | Supports | Verified by automated color-contrast scanning (axe-core) across the 42 representative routes covering every distinct page template (see /accessibility) in light and dark themes with zero critical/serious findings, plus manual remediation of two findings caught by independent computed-contrast checks (keyboard focus ring, a dark-band label) during the July 2026 rebuild. |
| 1.4.4 Resize Text | AA | Supports | Verified at the WCAG-equivalent 200% zoom condition (640px effective width on a 1280px baseline, per WCAG's own documented equivalence): no horizontal scrolling and no vertically clipped text elements found. |
| 1.4.5 Images of Text | AA | Supports | No information-bearing text is rendered as an image anywhere on the site; headings and body copy are live text throughout. A decorative photograph appears on the homepage hero as a CSS background image (not an inline image element), so it never enters the accessibility tree; it conveys no text or information. |
| 1.4.10 Reflow | AA | Supports | Verified at the exact WCAG-prescribed 320 CSS pixel width (not a looser proxy) with no horizontal scroll and no element exceeding the viewport, on both this report and a representative content-heavy page. |
| 1.4.11 Non-text Contrast | AA | Partially Supports | Focus indicators and primary UI controls were manually verified. Border/icon contrast on every control across all ~45 routes has not been individually audited; automated tooling has limited coverage of this criterion. |
| 1.4.12 Text Spacing | AA | Supports | Verified by injecting the WCAG-prescribed text-spacing override (line-height 1.5, letter-spacing 0.12em, word-spacing 0.16em, paragraph spacing 2x) at both desktop and 320px widths: no clipped or overlapping text found, including within the criteria tables on this page. |
| 1.4.13 Content on Hover or Focus | AA | Partially Supports | Desktop navigation submenus use native HTML <details>/<summary> disclosure elements, which are keyboard-operable and dismissible by convention, but Escape-to-close behavior varies by browser and was not verified browser-by-browser. |
2. Operable
| Criterion | Level | Conformance | Remarks |
|---|---|---|---|
| 2.1.1 Keyboard | A | Supports | All interactive elements are native controls (links, buttons, selects, native disclosure widgets) or carry explicit keyboard handling; no mouse-only interactions identified. |
| 2.1.2 No Keyboard Trap | A | Supports | The mobile navigation dialog traps focus while open (by design, as a modal) but Escape and the Close control reliably exit it; verified in code and live. |
| 2.1.4 Character Key Shortcuts | A | Supports | No single-character keyboard shortcuts are implemented anywhere on the site. |
| 2.2.1 Timing Adjustable | A | Not Applicable | No session time limits or auto-advancing content exist. |
| 2.2.2 Pause, Stop, Hide | A | Supports | All motion (live-status pulse, animated counters, scroll reveals) is gated behind prefers-reduced-motion; content renders in its final state immediately when that preference is set. |
| 2.3.1 Three Flashes or Below Threshold | A | Supports | No flashing content exists; the only animation is a slow opacity pulse, itself reduced-motion-gated. |
| 2.4.1 Bypass Blocks | A | Supports | A "Skip to main content" link is present site-wide via the shared page layout and verified functional. |
| 2.4.2 Page Titled | A | Supports | Page titles are generated per-route through the site's shared metadata builder, including a per-course title on the training catalog's individual course pages; verified present and descriptive on the 42 representative routes scanned (see Evaluation methods used), not individually re-checked on every one of the ~2,900 course pages the same mechanism covers. |
| 2.4.3 Focus Order | A | Supports | No positive tabindex values are used; focus order follows DOM order, which matches visual order. Modal focus management (open/trap/close/return) was verified live. |
| 2.4.4 Link Purpose (In Context) | A | Supports | Link text is descriptive in context (e.g. "Read the original at [Source]") rather than generic "click here" patterns. |
| 2.4.5 Multiple Ways | AA | Supports | Pages are reachable via the global header navigation, the footer link structure, and the XML sitemap. |
| 2.4.6 Headings and Labels | AA | Supports | Headings and form labels are descriptive and specific, not generic placeholders. |
| 2.4.7 Focus Visible | AA | Supports | Verified with a live keyboard (Tab-key) test against the production site: the focus indicator renders as a 3px solid, opaque, high-contrast outline (6.96:1 light theme, 11.17:1 dark theme). |
| 2.5.1 Pointer Gestures | A | Supports | No multi-point or path-based gestures are used; all interactions are simple taps or clicks. |
| 2.5.2 Pointer Cancellation | A | Supports | Standard click-event handling throughout; no down-event-triggered actions. |
| 2.5.3 Label in Name | A | Supports | Accessible names (aria-label) contain or match visible text where both are present; reviewed for conflicts, none found. |
| 2.5.4 Motion Actuation | A | Not Applicable | No device-motion-triggered interactions exist. |
3. Understandable
| Criterion | Level | Conformance | Remarks |
|---|---|---|---|
| 3.1.1 Language of Page | A | Supports | html lang="en" is set on every page. |
| 3.1.2 Language of Parts | AA | Supports | All site content is English; no foreign-language passages requiring a lang override were identified. |
| 3.2.1 On Focus | A | Supports | No context changes (navigation, form submission) are triggered by focus alone. |
| 3.2.2 On Input | A | Supports | Form fields and selects do not auto-submit or auto-navigate on change; all forms use an explicit submit control. |
| 3.2.3 Consistent Navigation | AA | Supports | Header and footer navigation are rendered once from a shared site-wide layout, guaranteeing identical order and labeling on every page by construction. |
| 3.2.4 Consistent Identification | AA | Supports | Repeated components (primary CTA, card patterns, contact links) use a shared design system and consistent labeling across pages. |
| 3.3.1 Error Identification | A | Supports | The Request Center form surfaces a visible, programmatically announced (role="alert") error message on validation failure, in addition to native browser field validation. |
| 3.3.2 Labels or Instructions | A | Supports | Every form field has an associated, descriptive <label>; several also include placeholder text with format guidance. |
| 3.3.3 Error Suggestion | AA | Partially Supports | Native browser validation and the form-level error banner explain that a field was missing or invalid, but do not programmatically identify which specific field. A future revision should surface field-level error text. |
| 3.3.4 Error Prevention (Legal, Financial, Data) | AA | Not Applicable | Site forms are informational inquiries; no legal commitments, financial transactions, or user data deletion occur. |
4. Robust
| Criterion | Level | Conformance | Remarks |
|---|---|---|---|
| 4.1.1 Parsing | A | Supports | Markup is generated by React/Next.js, which produces well-formed HTML by construction; no duplicate IDs identified in review. |
| 4.1.2 Name, Role, Value | A | Supports | ARIA attributes (aria-label, aria-expanded, aria-controls, aria-modal, role) are used correctly on custom components (e.g. the mobile navigation dialog); automated ARIA-validity scanning passed with zero critical/serious findings across the 42 representative routes covering every distinct page template (see /accessibility). |
| 4.1.3 Status Messages | AA | Supports | Dynamic status text (partner-directory result counts, the contract-vehicle recommendation panel, and the Request Center form error) is wrapped in aria-live or role="alert" regions so assistive technology announces updates without requiring a focus change. |
Chapter 4: Hardware
Not Applicable. This product is a website; StorSoft does not manufacture or distribute any hardware component as part of it, so Chapter 4’s provisions (400–417, including closed-functionality requirements for hardware) do not apply.
Chapter 6: Support Documentation and Services
Not Applicable. StorSoft does not distribute separate end-user product documentation or a dedicated support-services product distinct from the website itself, so Chapter 6’s provisions (602–603) do not apply. Accessibility support and barrier reporting for the website are handled through the https://www.storsoftcorp.com/accessibility statement and info@storsoftcorp.com, referenced throughout this report.
Legal disclaimer
This report reflects StorSoft Technology Corp’s good-faith self-assessment as of the report date above, based on the evaluation methods disclosed. It is not a certification and has not been reviewed by an independent third party. To report an accessibility barrier, see the accessibility statement or contact info@storsoftcorp.com.
VPAT® is a registered service mark of the Information Technology Industry Council (ITI), used here per ITI’s published terms for vendor-authored conformance reports. This document follows the VPAT 2.5 Revised Section 508 Edition report structure published by ITI at itic.org/vpat.