Do you have a documented and implemented process for reporting and tracking accessibility issues?
Explanation
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.).
In a security assessment context, this question appears because:
- Accessibility is increasingly considered part of overall compliance requirements (like ADA, Section 508, WCAG standards)
- Proper handling of accessibility issues demonstrates organizational maturity in addressing all types of user needs
- Accessibility issues can sometimes overlap with security concerns (e.g., screen reader compatibility with secure forms)
The guidance specifically notes that simply having a general feature request system that might include accessibility issues is NOT sufficient. You need a dedicated process specifically for accessibility issues.
A good answer should include:
- Documentation of your accessibility reporting process
- How issues are tracked from report to resolution
- Who is responsible for addressing these issues
- How you prioritize and implement fixes
- How you verify the fixes meet accessibility standards
This demonstrates that your organization takes accessibility seriously as a compliance matter, not just as optional feature requests.
Guidance
Reporting and fixing accessibility issues is critical to a mature process. If the process for this question is merely a "feature request" and tracker, the answer to this question should be "no."
Example Responses
Example Response 1
Yes Our organization has implemented a dedicated Accessibility Issue Management Process (AIMP) documented in our IT Governance framework Users can report accessibility issues through a specific form on our help portal that captures detailed information about the barrier encountered, assistive technologies being used, and impact severity These reports are automatically routed to our Accessibility Team who triage issues within 24 hours using WCAG 2.1 standards as evaluation criteria Issues are tracked in our JIRA instance with a specific 'Accessibility' tag and priority level Our process requires Level A and AA violations to be addressed within 30 days, with emergency fixes for critical barriers implemented within 72 hours The Accessibility Team conducts validation testing with various assistive technologies before closing any ticket We maintain metrics on resolution time and issue categories, which are reviewed quarterly by our Compliance Committee.
Example Response 2
Yes We maintain a dedicated accessibility issue tracking process that is separate from our general feature request system Our process includes a specialized intake form on our support portal that collects specific information about the accessibility barrier, including device type, assistive technology used, and steps to reproduce These reports are assigned to our UX team with accessibility expertise who evaluate each issue against WCAG 2.1 standards and Section 508 requirements We use a dedicated project in Azure DevOps to track these issues with custom fields for accessibility standards violated, impact level, and remediation approach Our development teams receive accessibility training annually, and we have established SLAs for addressing issues based on severity (P1: 1 week, P2: 2 weeks, P3: next release cycle) Before closing any accessibility ticket, our QA team verifies the fix using multiple assistive technologies including JAWS, NVDA, and VoiceOver We generate monthly reports on accessibility compliance for our executive team.
Example Response 3
No While we do have a general bug reporting system where users can submit any issues they encounter with our software, we don't currently have a process specifically dedicated to accessibility issues When accessibility-related reports come in, they are handled through our standard bug triage process and prioritized against all other feature requests and bugs Our developers do try to follow WCAG guidelines when implementing new features, but we don't have specialized tracking, dedicated personnel, or specific timelines for addressing accessibility concerns We recognize this is an area for improvement in our process maturity, and we're currently developing a more formal accessibility program that we expect to implement within the next six months.
Context
- Tab
- IT Accessibility
- Category
- IT Accessibility
Related questions
- Solution Provider Accessibility Contact Name
- Solution Provider Accessibility Contact Title
- Solution Provider Accessibility Contact Email
- Solution Provider Accessibility Contact Phone Number
- Web Link to Accessibility Statement or VPAT
- Has a VPAT or ACR been created or updated for the solution and version under consideration within the past 12 months?

