Vendor Corner: Accessibility requirements for doing business with the State of Connecticut

The State of Connecticut serves everyone. That includes people who are blind or low-vision, deaf or hard of hearing, have mobility or cognitive disabilities, older adults, and people using phones or slow internet. 

Accessible products help more people do their work and get services. Accessibility is also required by federal law and state policy. When you sell digital products to the State, your product must be accessible. 

We recently hosted an information session where we shared our goals and commitment to fostering a collaborative partnership with our vendors. Together, we can improve access to products, services, and content in the State of Connecticut.

Watch the Vendor Information Video

Your product must meet WCAG 2.1 Level AA.

This applies to:

• Websites and web apps (front end and admin)
• Mobile apps (iOS and Android)
• Electronic documents (PDF, Word, PowerPoint, Excel)
• Videos, audio, captions, transcripts, and player controls
• User help, knowledge bases, and support portals
• Product documentation, onboarding guides, and templates

You must also provide proof of accessibility:

• A current Accessibility Conformance Report (ACR) based on the VPAT® template (WCAG 2.1 Level AA).
• A short testing report showing how you tested, the tools you used, and the issues you fixed.
• If anything isn’t fully compliant, a time-bound Remediation Plan with clear owners and dates.

With your proposal (RFP/RFQ response)

• Product name and version being offered.
• ACR (VPAT-based) that maps to WCAG 2.1 AA.
• Summary of testing (tools, assistive tech, browsers, OS, mobile).
• Accessibility point-of-contact (name, role, email).
• Roadmap showing how you maintain accessibility in future releases.

Before user acceptance (pre-production / pilot)

• Updated ACR for the release we will receive.
• Test evidence (see checklist below).
• Remediation Plan for any open issues (with dates).
• Statement that all customer-facing documents and support content are accessible (templates, help articles, PDFs, videos).

After go-live (maintenance)

• New ACR when you release major updates.
• Notice of breaking changes that may affect accessibility.
• Ongoing issue tracking and timely fixes.

Your ACR should: 

• Use the latest WCAG 2.1 AA VPAT® template from ITI. 
• Cover all modules the State will use (not just public pages). 
• List platforms and versions tested (Windows, macOS, iOS, Android; Chrome, Edge, Safari, Firefox).
• List assistive technologies tested (e.g., NVDA on Windows; built-in zoom; keyboard-only). 
• Give clear, honest statements for each success criterion (Supports / Partially Supports / Does Not Support) and short notes with evidence or workarounds. 
• Include date, product version, and contact for follow-up.

Tip: Do not copy generic statements. We check for accuracy by testing live builds.

Your product will be evaluated against at least these WCAG 2.1 AA topics:

1. Keyboard access everywhere (no keyboard traps; visible focus at all times).
2. Headings and structure make sense and follow an order (H1, H2, H3).
3. Links and buttons have clear, descriptive names (no “click here”).
4. Colors and contrast meet AA (4.5:1 for normal text, 3:1 for large text and UI).
5. Images have useful alt text or are marked decorative.
6. Forms have programmatic labels, instructions, clear errors, and no “visual puzzle-only” authentication.
7. Tables use proper headers and relationships.
8. Media has captions (video) and transcripts (audio).
9. Zoom and reflow: content works at 200%+ without loss of function.
10. No content that flashes more than allowed; respect “reduced motion”.

If any item fails, we may require fixes before acceptance or a remediation plan with near-term deadlines.

Daily / during development

1. Run axe DevTools in your browser; fix issues early.
2. Use ANDI to check headings, links, images, and tables.
3. Try keyboard-only: Tab/Shift+Tab/Enter/Space/Arrow keys.
4. Check contrast of text and interactive elements with WebAIM Contrast Checker.

Pre-release

1. Test with NVDA on Windows (free):
   • H to step through headings.
   • D for landmarks.
   • K for links.
   • F for form fields.
   • Ensure labels, focus order, and error messages are read.
2. Test reflow and zoom (up to 200–400%).
3. Verify captions and transcripts for all media.
4. Re-run automated checks and fix remaining high-impact issues.

• Documents (PDF, Word, PowerPoint, Excel) you deliver must be accessible.
• Use real headings, lists, alt text, table headers, document language.
• Tag PDFs and set reading order; avoid scanned PDFs when possible.
• Videos must include closed captions; provide transcripts for audio-only content.
• Templates and guides you provide must also meet WCAG 2.1 AA.

• Tell us which criteria are not met, where, and why.
• Provide an Equally Effective Alternative (temporary workaround) if possible.
• Submit a Remediation Plan with dates, owners, and milestones.
• We may hold acceptance or withhold payment until required fixes are delivered, per contract terms.

• our offer may score lower in evaluation.
• We may require changes before acceptance.
• We may ask for a stronger remediation plan or adjust payments and timelines per the contract.

Our goal is partnership and success. Clear, early communication helps everyone.

• ANDI (bookmarklet): quick checks for images, links, headings, tables.
• axe DevTools (free version): browser extension that finds many code-level issues.
• WebAIM Contrast Checker: verify color contrast for text and UI.
• NVDA (Windows screen reader): test headings, landmarks, forms, and reading order.