The following columns are included in the report template:
Impact
Using the “Severity Matrix” tab in the spreadsheet, rate the impact or severity of each issue as 1 - HIGH, 2 - MEDIUM, or 3 - LOW. Fixing all accessibility issues is desirable, but assigning priority is useful when working with collaborators and helps ensure critical bugs get addressed first. The rating should be determined by how critical or important the content is, correlated with how easy the site is to operate and understand. As you plot each issue on the graph, you’ll be able to rate its impact to the accessibility of the site. For example, if a website has an application form that is critical to users, but there is an issue that prevents keyboard-only users from completing the form, that issue would fall in the top right quadrant, and would be a 1 - HIGH rating.
Image 1: Severity Matrix
Image 1 Description: A 2 by 2 matrix that identifies the severity of accessibility issues as either Low, Medium or High. The vertical axis of the matrix corresponds to the range of operability and perceivability of content, with operable or perceivable content at the bottom of the axis and inoperable or perceivable content at the top. The horizontal axis corresponds to the range of relevance of content with less relevant content to the left of the axis and very relevant content to the right.
Page Title, URL, and Page Area
If you are testing multiple pages within a site, add the URL for each page with an issue. It can also be helpful to identify the page title, and specify where on the page the issue is occurring, such as in the header, footer, or search box. Make sure to describe the area of the page consistently throughout all of the pages. You might need to adapt these columns to fit your particular site content. For example, if you’re just testing one page, you might forgo the “URL” or “Page Title” columns.
Issue, description, and WCAG criteria
Briefly identify the name of the issue, then provide a detailed but concise description in the next column so that the person fixing the problem can understand it. Cite the WCAG criteria (single or multiple) that the issue is in violation of. If you are testing with Siteimprove, you can copy and paste this information from the sidebar of each flagged issue. You can also find the criteria in the WCAG Quick Reference Guide, linked from the column heading.
Image 2: WCAG Criteria in Siteimprove
Image 2 Description: Screenshot of WCAG sidebar in Siteimprove, with elements labeled to correspond with the assessment template. "Link text used for multiple different destinations" is identified as Issue. "2.4.4 Link Purpose (In Context)" is identified as WCAG Criteria. "Description of this issue: The same link text is used for links going to different destinations. Users might not know the difference if they are not somehow explained," is identified as Description. "How to fix it: Make sure links are distinguishable by just their link texts or WAI-ARIA labels ('aria-labelledby' or 'aria-label') to make it clear that they lead to different destinations," is identified as Action.
Testing method
Indicate how you discovered the issue, so that it will be easy for someone else to replicate using the same method. Testing methods could include things such as Siteimprove, Manual - keyboard, browser, or screen reader.
Screenshot or code snippet
Include a screenshot when the area of the page or issue itself is difficult to understand based on the issue description alone. If the issue is hidden in the code, include the code snippet. You can find the underlying code by right-clicking the element and selecting "Inspect."
Action
Describe action that can be taken to remediate the issue.
Role
Identify which role or team is responsible for addressing this issue, such as Developer, Webmaster, or Content Editor.
Notes
This column allows for any additional observations about the issue that seem secondary to the main description. You might also decide to use this column to record when the issue was fixed in order to track progress.
Sharing Results
When you’ve completed entering issues into the spreadsheet, you might need to share your report with others, such as managers, content editors, or developers. While the spreadsheet is a great resource to share, it may also be helpful to draft a cover sheet that explains at a high level the major issues you found, report on progress over time, or identify key themes from the testing. This will enable you to provide a concise summary of the website’s accessibility issues, without overwhelming the recipient with technical details.