HECVAT Category
IT Accessibility
IT Accessibility covers controls and questions related to that domain. It outlines expectations institutions typically require from vendors. The category helps assess risk posture and operational maturity. It provides structure for consistent evaluation during security reviews.
Assessment Questions
Solution Provider Accessibility Contact Name
Identify the individual at your organization who acts as the designated point of contact for accessibility-related questions and concerns. IT accessibility refers to ensuring that technology products and services can be used by people with disabilities. This contact person would typically be responsible for addressing questions about how your solution complies with accessibility standards (like WCAG, Section 508, ADA requirements, etc.).
Solution Provider Accessibility Contact Title
This field records the job title of the person who acts as your organization's primary point of contact for IT accessibility matters. IT accessibility refers to ensuring that your software, services, or products can be used by people with disabilities, including those with visual, auditory, physical, speech, cognitive, and neurological disabilities.
Solution Provider Accessibility Contact Email
Provide the email address for the person or team that handles accessibility concerns at your organization. IT Accessibility refers to ensuring that technology products and services can be used by people with disabilities. This contact would be responsible for addressing questions about how your solution meets accessibility standards (like WCAG, Section 508, ADA compliance, etc.).
Solution Provider Accessibility Contact Phone Number
A direct contact detail is requested here: the phone number for the person or team that handles accessibility concerns at your organization. IT Accessibility refers to ensuring that technology products and services can be used by people with disabilities.
Web Link to Accessibility Statement or VPAT
Accessibility documentation is what's requested here: a working web link to your Accessibility Statement or Voluntary Product Accessibility Template (VPAT).
Has a VPAT or ACR been created or updated for the solution and version under consideration within the past 12 months?
Accessibility documentation currency is what's at stake: reviewers want a VPAT or ACR for the specific version under consideration, refreshed within the last 12 months.
Will your company agree to meet your stated accessibility standard or WCAG 2.1 AA as part of your contractual agreement for the solution?
Accessibility commitments are under review here: whether your company will contractually agree to meet your stated accessibility standard or WCAG 2.1 AA for the solution.
Does the solution substantially conform to WCAG 2.1 AA?
Accessibility conformance is the focus here, asking whether your solution substantially meets the Web Content Accessibility Guidelines (WCAG) 2.1 at the AA level.
Do you have a documented and implemented process for reporting and tracking accessibility issues?
Reviewers want a documented, implemented process dedicated to logging, tracking, and resolving accessibility issues in your software or services. Accessibility refers to how usable your product is for people with disabilities (visual, hearing, motor, cognitive, etc.).
Do you have documentation to support the accessibility features of your solution?
Accessibility documentation is the focus: reviewers want to know that your solution's accessibility features are documented along with guidance on how to use them. Accessibility features are those that make your product usable by people with disabilities, including visual, auditory, physical, speech, cognitive, language, learning, and neurological disabilities.
Has a third-party expert conducted an audit of the most recent version of your solution?
Independent accessibility validation is the subject here, namely whether a third-party expert has audited the most recent version of your solution.
Do you have a documented and implemented process for verifying accessibility conformance?
Accessibility conformance is the focus here: reviewers want a documented process for verifying that your products meet accessibility standards, and evidence that you follow it in practice.
Have you adopted a technical or legal standard of conformance for the solution?
Standards of conformance are the focus: whether your solution adheres to a recognized technical or legal accessibility standard so people with disabilities can use it effectively. IT accessibility refers to designing technology that can be used by people with various disabilities, including visual, auditory, physical, speech, cognitive, and neurological disabilities.
Can you provide a current, detailed accessibility roadmap with delivery timelines?
Forward planning on accessibility is what's sought: whether you can supply a current, detailed roadmap of planned improvements with concrete delivery timelines.
Do you expect your staff to maintain a current skill set in IT accessibility?
Ongoing accessibility competence is the concern, and whether you expect and support your staff in keeping their IT accessibility skills current. IT accessibility refers to ensuring that technology products and services can be used by people with disabilities.
Do you have documented processes and procedures for implementing accessibility into your development lifecycle?
Building accessibility into how software is made is the concern here, namely whether you have documented processes for embedding accessibility throughout your development lifecycle. Accessibility refers to designing and developing products that can be used by people with disabilities, including visual, auditory, physical, speech, cognitive, and neurological disabilities.
Can all functions of the application or service be performed using only the keyboard?
Keyboard accessibility is the concern, namely whether every function of the application or service can be performed using only a keyboard, with no mouse or pointing device required. This is a fundamental accessibility requirement that ensures users with motor disabilities or those who cannot use pointing devices can still access all functionality.
Does your product rely on activating a special "accessibility mode," a "lite version," or using an alternate interface (including “overlay” or AI-based alternates) for accessibility purposes?
At issue is whether accessibility is built into your core product, or whether users must switch to a special accessibility mode, lite version, overlay, or AI-based alternate interface to get it.
ResponseHub is the product I wish I had when I was a CTO
Previously I was co-founder and CTO of Progression, a VC backed HR-tech startup used by some of the biggest names in tech.
As our sales grew, security questionnaires quickly became one of my biggest pain-points. They were confusing, hard to delegate and arrived like London busses - 3 at a time!
I'm building ResponseHub so that other teams don't have to go through this. Leave the security questionnaires to us so you can get back to closing deals, shipping product and building your team.
