If you read nothing else
Virginia’s HB 2541 established a legal requirement to systematically track and prioritize accessibility issues across state information and communication technology (ICT) applications. At the time, no such system existed. I designed and implemented the ITC Remediation Triage Register in Azure DevOps, developing the work item schema, custom fields, risk-weighted scoring, dashboards, and training documentation for 75 cataloged applications, each averaging 17 issues. This project demonstrates how accessibility operations function within a regulated government context, where compliance infrastructure presents a significant design challenge.
Overview
HB 2541, signed into Virginia law as an amendment to the Information Technology Accessibility Act (ITAA) in the Code of Virginia, required the Virginia Information Technologies Agency (VITA) to formally prioritize and document non-conforming information and communication technology (ITC). No process existed, no central repository, and no shared accountability across system owners.
As Accessibility Lead, I designed and developed the ITC Remediation Triage Register in Microsoft Azure DevOps, encompassing the work item schema, custom fields, scoring methodology, filters, dashboards, and a comprehensive usage wiki. I subsequently trained all system owners to operate the system independently.
- Formally prioritize all non-conforming ITC across the agency
- A documented process on file for achieving state-level compliance
- Annual reports to the General Assembly on non-conforming, non-exempt ITC
- Cost estimates for bringing non-conforming systems into compliance
- Shared accountability across system owners agency-wide
- An incomplete spreadsheet of ~75 applications, many missing system owner info
- No issue log or remediation tracking of any kind
- No prioritization framework — no way to determine what to fix first
- No reporting infrastructure to support the annual General Assembly report
- Issues surfaced ad hoc via email and Teams — no intake, no urgency signal
The Problem
Accessibility issues were confined to individual inboxes, resulting in information silos and making effective prioritization impossible.
Before implementing this system, VITA managed the entire accessibility remediation workflow through my inbox and Microsoft Teams messages. System owners reported issues on an ad hoc basis, frequently at the last minute and without a clear understanding of remediation scope or required effort. As a result, issues were often overlooked, forgotten, or duplicated, and no single authoritative record existed.
A spreadsheet listed applications at VITA, but it was incomplete: many rows lacked system owner information, and the document gave no indication of what issues existed, how serious they were, or what order they should be addressed in. No mechanism existed to generate the annual report to the General Assembly that HB 2541 required.
The organization had 75 internally owned applications, many lacking documented owners. No issue log, prioritization framework, or reporting infrastructure existed, and one individual managed all information.
The primary challenge was institutional rather than technical. System owners represented diverse backgrounds and generally lacked accessibility training. The agency had no established process, and any solution needed to be sufficiently straightforward for non-specialists to use independently, without requiring ongoing support from me.
Process
The first step was to conduct a comprehensive audit, then design a system the agency could maintain over time.
I started by reviewing the existing application spreadsheet, identifying system owners for entries missing that information, and conducting individual audits across all 75 internally owned or custom-built applications. This process provided the necessary data and revealed significant inconsistencies in information tracking.
Based on the audit findings, I developed a prioritization scoring methodology consisting of seven criteria tailored for system owners without accessibility expertise. Instead of requiring technical assessment of WCAG conformance, the criteria focused on factors system owners could readily evaluate, such as user demographics, usage frequency, availability of alternatives, financial implications, and system lifecycle stage.
- Each criterion scores 1–3, with a maximum total of 21 points
- Scores ≥ 17 map to Tier 1 (highest priority / immediate action); 12–16 to Tier 2; ≤ 11 to Tier 3
- Criteria include: Criticality, Audience, User Impact, Accessibility Barriers, Availability of Alternatives, Financial Impact, and Lifecycle Status
- The model is documented in the agency's formal Digital Accessibility Prioritization Process, grounding it in HB 2541 and Title II of the ADA
After establishing the scoring framework, I designed the DevOps architecture, including custom work item types to differentiate applications from individual issues, field schemas to capture essential metadata (such as system owner, risk profile, remediation timeline, and financial impact), and filters and dashboards to facilitate efficient triage. Additionally, I authored a comprehensive wiki detailing the workflow so system owners can operate independently.
| # | Criterion & description | Points |
|---|---|---|
| 1 |
Criticality
Statutory obligation, mission-critical, or supportive function?
|
1–3 |
| 2 |
Audience
Public-facing, agency-to-agency, or strictly internal?
|
1–3 |
| 3 |
User Impact
Large public audience, defined user group, or small user base?
|
1–3 |
| 4 |
Accessibility Barriers
Blocks key tasks entirely, reduces usability, or none known?
|
1–3 |
| 5 |
Availability of Alternatives
No accessible path exists, manual workaround, or robust alternative?
|
1–3 |
| 6 |
Financial Impact
High, moderate, or low estimated remediation cost?
|
1–3 |
| 7 |
Lifecycle Status
New or strategic investment, stable system, or near retirement?
|
1–3 |
Scoring Outcomes
Documented in VITA's Digital Accessibility Prioritization Process · grounded in HB 2541 & Title II ADA
Solution
A unified system of record was established for every ITC application, issue, owner, and remediation plan.
The ITC Remediation Triage Register in Azure DevOps serves as the authoritative source for VITA's accessibility posture. Every one of the 75 applications is cataloged with its system type classification, risk profile, remediation priority tier, system owner, and any known accessibility issues — each logged as a linked work item with status tracking.
The register consolidates multiple stakeholder groups within a shared environment. As Accessibility Lead, I can monitor the overall compliance landscape, while system owners manage their assets and log issues directly. Agency leadership gains visibility into aggregate compliance status. This approach eliminates the need for emails and Teams messages that lack context or urgency.
"Wow, this is so much easier to work with."
— System owner, during vendor handoff training
Importantly, the register is designed to generate the data required for VITA's annual report of non-conforming ITC to the General Assembly, as mandated by HB 2541. Instead of compiling information at the last minute, the register now collects relevant data continuously throughout the year.
The scoring model also accommodates vendor relationships. When third-party vendors transfer systems, the register offers a structured intake process, and the wiki provides necessary context, enabling vendors to participate without requiring my direct involvement.
VITA Contract Assistant
Description
Public-facing AI chat tool that answers contractor questions about VITA procurement processes. Multiple WCAG 2.1 A and AA failures across the interface — screen reader users are effectively blocked from using the primary support channel.
Justification for Rating
Child Issues (18 total)
Show more (13 of 18 not shown)
Outcomes
From zero infrastructure to a fully operational compliance system.
The register transitioned from concept to full operation across all 75 applications, with system owners trained to work independently. The transformation in VITA’s approach to accessibility is both qualitative and quantitative.
- All 75 ITC applications cataloged with owners, system type classifications, and risk profiles assigned
- Approximately 1,275 issues logged and tracked (averaging 17 per application) — all of which previously had no formal home
- Remediation now flows through a structured, at-a-glance backlog rather than an inbox
- Multiple stakeholder groups — system owners, Accessibility Lead, agency leadership — operate under one shared system
- Annual reporting to the General Assembly is now supported by live, continuously updated data rather than manual compilation
- Vendor handoffs have a structured intake process, reducing dependency on me as a single point of contact