Track, Escalate, and Resolve Section 508 Defects

Section 508 of the Rehabilitation Act requires federal agencies to ensure that information and communication technology (ICT) is accessible to people with disabilities. When testing reveals a defect, the agency's obligation does not end — it shifts to remediation. Agencies that manage accessibility defects consistently, escalate them appropriately, and verify fixes before closing them reduce legal risk and keep services accessible to the people who depend on them.

This article provides Section 508 program managers, IT project managers, and contracting officers with a recommended eight-step process for managing Section 508 defects from discovery through closure. It also includes escalation guidance, sample templates, and suggested contract language. The guidance applies whether the work is performed by internal teams or external contractors.

Effective defect management depends on clearly defined roles and consistent coordination across the organization. Each stakeholder in the remediation process has distinct responsibilities that support, but do not replace, the authority of the CO. Table 1 summarizes the key responsibilities by role for tracking, escalating, and resolving Section 508 defects.

Table 1. Key Responsibilities by Role

Managing Section 508 Defects

A Section 508 defect that is identified but not tracked is a defect that may never get fixed. Agencies that test regularly, document findings consistently, and follow a clear remediation process are better equipped to close defects, reduce recurrence, and demonstrate better Section 508 conformance over time. The following eight steps provide a recommended procedure for managing Section 508 defects from initial discovery through closure. Apply these steps consistently across ICT products and development efforts.

1. Document the Defect

   Log every Section 508 defect in your agency's approved tracking system — such as Jira, ServiceNow, GitHub Issues, or an equivalent tool — as soon as it is identified. Use the same system you use for other product defects so that accessibility issues receive the same visibility and management attention. Adapt the sample fields below (Table 2) for your tracking system and needs.

   Table 2. Defect tracking fields

   Field	Entry
   Defect ID	[Unique tracking number — auto-assigned or manual]
   Date Identified	[MM/DD/YYYY]
   Identified By	[Tester name, role, team]
   Product or System Name	[Name, version, module, URL, or document title]
   Environment	[e.g., Production, Staging, or Development — include URL if applicable]
   Test ID	[For example, if using DHS Trusted Tester process, cite the applicable test ID]
   WCAG Success Criterion or Section 508 Standard	[e.g., WCAG 1.1.1, WCAG 1.3.1,]
   Defect Description	[Plain-language description of what is wrong]
   Defect Location	[Specific location(s) of where the defect occurs]
   User Impact	[How this defect affects users with disabilities]
   Steps to Reproduce	[Series of steps to replicate the defect]
   Expected Result	[What should happen when the steps are followed]
   Testing Tool(s) Used	[e.g., ANDI, Color Contrast Analyzer, screen reader name and version]
   Browser or Platform	[e.g., Chrome, Edge, Windows, iOS]
   Severity	[Critical, Major, or Minor; See Step 2 below]
   Priority	[Assigned by product owner or PM based on risk and release schedule; may be directly associated with Severity]
   Owner	[Responsible internal team, vendor, contractor name, or contract number]
   Due Date	[Target remediation date based on severity and contract requirements]
   Evidence	[Attach screenshots, video recording, code snippet, or test report]
   Workaround Available	[Yes or No — if yes, describe the interim alternate access method]
   Status	[e.g., Open, Accepted, In Remediation, Ready for Validation,Closed, Deferred, or Escalated]
   Escalation Level	[If escalated, note current escalation step and date]
   Validation Result	[Pass or Fail; to be completed after fix is deployed]
   Validated By	[Tester name, role, date]
   Closure Notes	[Fix description, evidence, and deployment confirmation]
   Contract Reference	[Contract number, contract section, deliverable number — if vendor work]
   CO or COR Notified	[Yes or No — date notified]

   Tip: When documenting defects, write descriptions that a developer, contracting officer, or legal counsel can understand without specialized accessibility knowledge. Avoid jargon and focus on describing what the user experiences and what the expected behavior should be.

2. Assign Severity, Priority, and Timeframes

   Severity reflects the impact of the defect on users with disabilities. Use severity to drive prioritization and escalation timelines. Agencies should adjust these definitions based on their policies:

   • Critical: A critical accessibility failure prevents people with disabilities from accessing or completing core functionality. This may include completing an essential task, accessing required information, submitting a required form, receiving a service, or performing required job duties.
     • Example: A lack of keyboard access to focusable elements.
     • Priority: Fix immediately; if you cannot, require a remediation plan and interim alternative means of access.
   • Major: A major accessibility issue substantially impairs access to important functionality, but users may still complete tasks through a workaround or alternate method.
     • Example: Link context cannot be programmatically determined.
     • Priority: Prioritize for the current or next sprint, release, or contract deliverable correction.
   • Minor: A minor accessibility issue causes usability challenges or partial barriers for some users but does not prevent completion of core tasks.
     • Example: A decorative image is not marked as decorative.
     • Priority: Low; add to the remediation backlog and correct during routine maintenance.

   ---

   Reference the Section 508 Government ACR Supplement.

   ---

   Track patterns, not just individual defects. Regularly review open defects for aging issues, recurring failures, and systemic problems across products or vendors. Report defect trends to program leadership and the Section 508 Program Manager. A high volume of aging Major defects or recurring Critical defects on the same system signals a process or resource problem that may require escalation beyond the individual ticket.

   Agencies should set timelines based on mission risk, contract requirements, user impact, and release cycles. Use the model below in Table 3 as a starting point and adjust for your environment.

   Table 3: Target correction timeframe by severity

   Severity	Remediation Plan Due	Target Correction
   Critical	2 business days	As soon as practicable; ideally within 5 business days; immediate for public-facing or mission-critical systems
   Major	5 business days	Current sprint, release, or deliverable cycle
   Minor	As needed	Routine sprint or maintenance cycle or within 60–90 business days

   Note: For vendor ICT, the CO or COR should establish timelines in writing. For internal teams, the product owner or manager should set and document timelines in the team’s task tracking system.

3. Notify the Responsible Team

   Notify the team responsible for the fix as soon as the defect is documented and triaged. Use clear, factual language.

   For Internal Development Teams

   Notify the responsible party for remediation, such as the product owner, development lead, quality lead, or Section 508 lead. Use your agency's standard project communication channel, such as a ticketing system comment, a team channel, or a project status meeting. Your agency's defect tracking system may automate this notification.

   For External Vendors and Contract Support

   The COR or project manager may share technical findings with the vendor's technical point of contact. However, coordinate with the CO before issuing any direction that could affect contract scope, schedule, price, or terms.

   • Sample vendor defect notification template

     ---

     Subject: Section 508 Defect Notification — Contract No. [XXXXXX] — [Deliverable Name] — Defect ID [XXXX]

     [Vendor Technical Point of Contact Name],

     During the Section 508 review of [deliverable name / system name / document title] submitted under Contract No. [XXXXXX], [agency name] identified a Section 508 conformance defect that requires your attention.

     Defect ID: [ID]

     Applicable Section 508 Requirement: [Section 508 standard or WCAG Success Criterion — cite specifically]

     Description: [Plain language description of the defect]

     Defect Location: [Module, screen, etc]

     Severity: [Critical, Major, or Minor]

     Evidence: [Attached screenshots or test report]

     Contract Reference: [Performance Work Statement (PWS) or Statement of Work (SOW) section that establishes the accessibility requirement]

     Per [PWS/SOW Section X.X], deliverables must conform to the applicable Section 508 standards. Please review the attached defect documentation and respond with a remediation plan within [X] business days. The Contracting Officer will review the plan and determine the appropriate next steps.

     Please direct questions to [COR name, contact information].

     [COR name, title, contract number, contact information]

4. Request a Remediation Plan

   For Critical and Major defects, and any defect affecting a pending deliverable or deployment, require the responsible team to submit a written remediation plan. This creates accountability and gives the agency visibility into the approach that will be taken to remediate the defect.

   The remediation plan should include:

   • Root cause of the defect.
   • Proposed fix and technical approach.
   • Scope of impact: list all pages, components, templates, documents, or modules the defect affects, and identify whether similar defects exist elsewhere.
   • Test approach: how the team will validate the fix, including assistive technology and regression testing.
   • Target completion date.
   • Interim workaround or alternate means of access during remediation.
   • Dependencies or risks that may affect the timeline.
   • Name and role of the person responsible for the fix.
   
   

   Tip: A remediation plan is only as effective as the follow-through. A specific individual should be tasked with tracking the progress against each milestone, following up before deadlines pass, and triggering escalation when dates slip or the fix stalls.

5. Address Section 508 Failures During Acceptance Testing

   Acceptance testing is the agency's last opportunity to enforce Section 508 requirements before a deliverable enters production. Test every ICT deliverable against the applicable standards before accepting it. When a deliverable fails, the Contracting Officer, in coordination with the COR, Section 508 Program Manager, and legal counsel, determines the appropriate action.

   A deliverable fails Section 508 acceptance testing when:

   • It does not conform to the Section 508 standards specified in the contract.
   • The contractor's ACR materially misrepresents the product's conformance.
   • Defects prevent users with disabilities from accessing required content or completing required tasks.
   • The deliverable does not meet the acceptance criteria specified in the PSW or SOW.

   Options When a Deliverable Fails

   1. Reject and require resubmission. Under acceptance clauses, the government may reject non-conforming deliverables and require the contractor to correct and resubmit at no additional cost to the government. Document the specific defects, cite the applicable contract requirements, and set a resubmission deadline.
   2. Conditional acceptance with documented defects. In some cases, the agency may accept a deliverable with known defects when the defects are low severity, a remediation plan is in place, and alternate means of access are available. Document the decision, the risk, and the remediation plan. Do not routinely accept non-conforming deliverables. Repeatedly accepting non-conforming deliverables may weaken the agency's position if the CO needs to take formal action later.
   3. Partial acceptance. When most of a deliverable conforms but specific components have defects, the CO may accept the conforming portions and reject the non-conforming portions. Document the accepted and rejected components clearly.
   4. Withhold payment. Depending on the contract type and applicable clauses, the CO may withhold payment for non-conforming deliverables until the contractor remediates the defects and the deliverable passes testing.
   5. Document contractor performance. When accessibility deficiencies contribute to a contractor performance issue, document the facts, communications, remediation efforts, and outcomes in the contract file. When appropriate, the CO should consider the contractor's performance in accordance with applicable past-performance evaluation requirements, including CPARS. Do not characterize a Section 508 defect as a performance deficiency unless the facts and contract requirements support that determination.
   6. Escalate to cure notice or show cause. For repeated failures, significant non-conformance, or contractor unwillingness to remediate, the CO may issue a cure notice or show cause letter. A cure notice formally identifies the contractor's failure to meet contract requirements and provides an opportunity to correct the deficiencies within a specified period. A show cause letter asks the contractor to explain why the government should not terminate the contract for default or cause, typically when insufficient time remains to correct the deficiencies. Both actions require careful consideration of applicable contract terms and procedures.

6. Escalate When the Issue Is Not Resolved

   Escalate unresolved Section 508 deficiencies when they cannot be addressed through routine remediation or when their severity, impact, or potential consequences warrant additional management attention. Conditions that may trigger escalation include:

   • The defect is classified Critical or Major severity.
   • The defect prevents acceptance of a deliverable or completion of a required task.
   • The responsible team or contractor fails to respond within the agreed timeline.
   • The same defect persists or recurs after remediation.
   • The contractor disputes an accessibility finding or applicable contractual requirement, and the disagreement cannot be resolved through technical review.
   • The defect significantly affects public access, employee access, or mission-critical services.
   • Remediation may materially affect cost, schedule, scope, or contract obligations.
   • The contractor or vendor submits a corrected deliverable that still fails testing.

   Escalation should generally be progressive, beginning at the lowest level capable of resolving the issue. However, significant accessibility barriers, contractual concerns, or other high-risk conditions may warrant escalation directly to the appropriate authority. Document escalation decisions and use Table 4 to guide the process..

   Table 4: Escalation levels and actions

   Level	Internal Development Teams	External Vendors
   1	The developer or content owner fixes the defect.	Vendor technical point of contact fixes the defect.
   2	Product owner or technical lead prioritizes and resources the fix.	Vendor project manager escalates within the vendor organization.
   3	IT Project Manager adjusts the sprint or release schedule.	COR documents deficiencies, coordinates with the contractor within delegated authority, notifies the Contracting Officer, and monitors corrective actions.
   4	Section 508 program manager provides technical guidance and documents risk.	CO determines appropriate contractual remedies, including formal notices, rejection of deliverables, or other actions authorized by the contract.
   5	Program manager or system owner directs remediation, establishes interim accessibility measures, and elevates unresolved compliance risks to the appropriate agency authority.	CO consults agency legal counsel, as appropriate, regarding contractual remedies, disputed requirements, claims, or potential litigation.
   6	Agency governance board or CIO engages for systemic issues or high-risk systems.	Agency senior leadership and acquisition officials engage to address systemic contractor non-performance. Refer suspected fraud, deliberate misrepresentation, or other misconduct to the agency Inspector General , as appropriate.

   Contractor Performance Documentation

   Document significant accessibility deficiencies, corrective actions, and outcomes throughout contract performance. When applicable, incorporate this information into contractor performance evaluations in the Contractor Performance Assessment Reporting System (CPARS), consistent with FAR Subpart 42.15 and agency procedures.

   Document Escalation Outcomes

   Record the deficiency, affected requirements, responsible parties, corrective actions, deadlines, and final disposition. Verify that remediation resolves the accessibility issue before closing it. For unresolved deficiencies, document any interim accessibility measures and the agency's plan for achieving compliance.

   Sample Cure and Show Cause Notice Templates to Contractors

   A cure notice is a formal contract action issued by the Contracting Officer under 49.607 Delinquency notices (Federal Acquisition Regulation) when the contractor's failure to perform is so serious that it endangers performance of the contract.

   • Cure Notice

     ---

     Date: [Date] Contract No.: [XXXXXX] Contractor: [Contractor legal name and address] Subject: Cure Notice — Failure to Conform to Section 508 Accessibility Requirements

     You are notified that the Government considers your ____ [specify the contractor’s failure or failures] a condition that is endangering performance of the contract. Therefore, unless this condition is cured within 10 days after receipt of this notice [or insert any longer time that the Contracting Officer may consider reasonably necessary], the Government may terminate for default under the terms and conditions of the _______ [insert clause title] clause of this contract.

     (End of notice)

   If the contractor responds to the cure notice but does not demonstrate a credible remediation path, the CO may issue a show cause notice before considering termination for default. Consult agency legal counsel before pursuing termination. Document all communications and performance issues throughout the process.

   • Show Cause Notice

     ---

     Date: [Date] Contract No.: [XXXXXX] Contractor: [Contractor legal name and address] Subject: Show Cause Notice — Failure to Conform to Section 508 Accessibility Requirements

     Since you have failed to ____ [insert "perform Contract No. ___ within the time required by its terms," or "cure the conditions endangering performance under Contract No _____ as described to you in the Government’s letter of _____ (date)"], the Government is considering terminating the contract under the provisions for default of this contract. Pending a final decision in this matter, it will be necessary to determine whether your failure to perform arose from causes beyond your control and without fault or negligence on your part. Accordingly, you are given the opportunity to present, in writing, any facts bearing on the question to ____ [insert the name and complete address of the contracting officer], within 10 days after receipt of this notice. Your failure to present any excuses within this time may be considered as an admission that none exist. Your attention is invited to the respective rights of the Contractor and the Government and the liabilities that may be invoked if a decision is made to terminate for default.

     Any assistance given to you on this contract or any acceptance by the Government of delinquent goods or services will be solely for the purpose of mitigating damages, and it is not the intention of the Government to condone any delinquency or to waive any rights the Government has under the contract.

     (End of notice)

   ACR Review During Acceptance

   When the contract requires the vendor to submit an ACR for each deliverable of ICT throughout the period of performance:

   1. Review the ACR for completeness. An ACR that lists "Supports" for every criterion without explanation is not credible. Look for specific descriptions of how the product meets each requirement. See Understanding Vendor Claims in Accessibility Conformance Reports for Section 508 Conformance.
   2. Conduct testing against the ACR. Validate the contractor's claims through independent testing using the DHS Trusted Tester process or an equivalent methodology.
   3. Document discrepancies. If internal testing reveals that the product does not conform in direct conflict with claims found in the ACR, document any discrepancies and raise them with the Contracting Officer. A materially inaccurate ACR may have contract and legal implications.
   4. Do not rely exclusively on conformance claims found in the ACR. The ACR is a self-reported document. Agencies should independently verify conformance through internal validation testing.

7. Validate the Fix

   Never close a defect based only on a statement that the issue was resolved. Retest the fix before closing the record.

   Validation should include:

   • The original steps taken to reproduce the issue.
   • The browser, operating system, and testing tools used in the original test.
   • Comprehensive manual and automated Section 508 testing.
   • Regression testing on related pages, templates, components, or documents to confirm the fix did not introduce new defects.
   • Confirmation that the fix is deployed to the correct environment.

   Update the defect record with the validation result, tester name, date, and evidence. If the fix fails validation, reopen the defect if it was closed, update the severity if appropriate, and notify the responsible team.

   Tip: When a fix affects a production system, confirm that the change follows the agency's change control process. See Section 508 Considerations for Change Control Processes.

8. Close or Defer a Defect

   Close the defect only when:

   • The fix passes validation testing.
   • The tester documents the result and evidence.
   • The responsible owner confirms deployment or delivery.
   • The agency accepts the corrected deliverable, if a formal acceptance process applies.

   Defer a defect only when the agency has documented:

   • The specific reason for deferral.
   • The user impact during the deferral period.
   • The interim alternate means of access.
   • The planned correction date.
   • The approving official or governance body.
   • Any contract, legal, or policy considerations.

   Do not use deferral to avoid Section 508 requirements. Agencies should track, report, and resolve deferred defects.

   When a Section 508 defect prevents a user with a disability from accessing ICT, the agency has an obligation to provide an alternate means of access while the defect is being remediated. Alternate means are a temporary measure — they are not a substitute for conformance. Section 508 permits the use of alternate means of access when ICT cannot be made fully conformant, but agencies should ensure that the alternate means provides equivalent access. An inconvenient, delayed, or inaccessible workaround does not satisfy this obligation. See Remediation and Accommodation Planning.

   
   

   Note: Legacy systems present unique challenges for Section 508 compliance. Many were built before current standards existed, have not been updated, or are scheduled for replacement. Known defects in legacy systems still require management, documentation, and a plan for resolution or replacement. Integrate unresolved Section 508 defects for systems into the agency's Plan of Action and Milestones (POA&M) process.

COTS and Open Source Products with Known Defects

Commercial off-the-shelf (COTS) and open source products often have known Section 508 defects that the agency cannot fix directly. These situations require a different approach.

Related Resources

• Define Accessibility Criteria in Contracts
• Determining ICT Exceptions
• ICT Accessibility and Risk Management
• Procuring Section 508 Conformant ICT Products and Services
• Remediation and Accommodation Planning
• Section 508 Considerations for Change Control Processes
• Testing Lifecycle Overview
• Understanding Section 508 Exceptions
• Understanding Vendor Claims in Accessibility Conformance Reports for Section 508 Conformance