Logging and resolving accessibility issues

This guidance is intended for colleagues who are responsible for addressing accessibility issues on websites or digital services.

Identifying accessibility barriers is only the first step. Logging and tracking issues helps ensure that problems are not only found, but fixed, verified, and documented properly.

This page outlines how to record, prioritise, and resolve accessibility issues, and how to prepare for internal reviews or external audits.

Why logging issues matters 

• Ensures accountability and follow-through; 
• Helps track recurring problems or patterns; 
• Creates evidence for audits, complaints, or improvement plans; 
• Allows content owners, developers, and project leads to coordinate effectively. 

Even small issues - like low-contrast text or missing alt text - can significantly affect a user’s experience. Tracking them ensures they’re not overlooked. 

What to log 

Each issue you record should include enough detail to understand, reproduce, and address the problem. A useful logging entry might include: 

• Issue title: for example “Low contrast on homepage banner text”; 
• Location: URL or document section; 
• Description: What’s wrong and how it affects accessibility; 
• WCAG reference (for example WCAG 2.2 - 1.4.3 Contrast Minimum); 
• Severity/impact: High (blocks access), Medium (causes difficulty), Low (minor issue); 
• Date identified and tester’s name; 
• Assigned to: Content editor, developer, or team; 
• Status: Open / In progress / Resolved / Verified; 
• Actions taken: Description of fix, workaround, or plan; 
• Retest date (optional). 

A simple spreadsheet or project tracking tool can help manage this process. 

Prioritising issues 

You may find dozens of issues across a site or document. Prioritise them using the following approach: 

• High priority: Content that blocks access or is legally non-compliant (for example no keyboard access, missing form labels); 
• Medium priority: Content that causes frustration but doesn’t block use (for example poorly structured headings, unclear links); 
• Low priority: Minor usability or styling issues that don’t prevent access (for example decorative images missing alt text). 

Focus on high-impact and high-traffic content first, such as key landing pages, forms, application portals, or downloadable documents. 

Assigning and resolving 

• Assign each issue to the relevant content owner, developer, or editor; 
• Work with IT Services, your web team, or procurement teams if the issue involves platform-wide changes; 
• When fixing issues, use the relevant accessibility standard as a reference (usually WCAG 2.2 Level AA); 
• Involve third-party suppliers if their tools or platforms are causing the issue (document your communications). 

Once resolved, retest the fix manually or using automated tools to confirm the issue is properly addressed. 

Verifying and closing issues 

A fix isn't complete until it has been verified. Make sure to: 

• Test using the same method or tool that identified the issue; 
• Document who verified the fix and when; 
• Mark the status as “Resolved” and, once confirmed, “Verified” or “Closed”. 

If a workaround is applied instead of a full fix, note this clearly and explain it in your accessibility statement, where applicable. 

Reporting and continuous improvement 

Keep records of resolved issues as part of your accessibility improvement plan. These logs may be requested during: 

• External audits (for example from the Government Digital Service); 
• Internal reviews; 
• Freedom of Information requests; 
• User complaints. 

Regularly review your logs to identify training needs or recurring problems - especially if similar issues are raised across multiple sites or departments.