After Your Scan

A scan tells you where to start, not when you are finished. The steps below turn a report into fixes, in the order that usually saves the most time. For how each part of the report works, see Report Anatomy.

1. Start with what blocks people

Work through Critical issues first, then Serious. These are the problems most likely to stop someone using the site at all, such as buttons with no name, images with no text alternative or form fields with no label.

Use At a Glance and Top Issues & Pages to see which problems appear most often and on which pages. A single issue type with hundreds of instances is often one fix in one place.

2. Review the Needs Review items

axe-core can't always decide whether something fails, for example text over a background image. If Include Needs Review Section was turned on for the scan, these items have their own Needs Review tab, each with an Approve button. An item's ticket shows a Review Priority when the engine was unsure.

1. Open the page and check the element yourself.
2. Select Approve if it is a real problem. It moves into its severity group.
3. Select Remove if it doesn't apply.

Needs Review1 issue type1 page affected Elements must meet minimum color contrast ratio thresholdsView TicketApproveRemoveBack to Moderate Issues Details DescriptionEnsure the contrast between foreground and background colors meets WCAG 2 AA minimum contrast ratio thresholds RuleColor-contrast · Rule documentation ImpactNeeds Review · WCAG 2aa · WCAG 143 · 1.4.3 Contrast (Minimum) (Level AA) Instances Found4 instances across 1 page.

Text description: a Needs Review item, with View Ticket, Approve, Remove and Back to Moderate Issues buttons and its details

Example of a Needs Review group with 1 issue type and 1 page affected. The item Elements must meet minimum color contrast ratio thresholds has View Ticket, Approve, Remove and Back to Moderate Issues buttons. Its Details list the description, the rule Color-contrast, the impact Needs Review with WCAG 2aa, WCAG 143 and 1.4.3 Contrast (Minimum) (Level AA), and 4 instances across 1 page.

If you disagree with a severity for your site, use Move To. To keep these decisions, select Save & Download HTML to save a copy you can share.

3. Turn findings into tickets

Select View Ticket on an issue, then Copy Ticket Content to paste it into your issue tracker. A ticket includes the affected pages, why the issue matters, how to fix it, steps to recreate it and any screenshots. Give whoever is fixing it the ticket's instance list, or the companion CSV for the full set of instances across the site.

If the ticket shows a Review Priority, the item came from Needs Review, so confirm it by hand before raising it.

Accessibility TicketButton-Name1 / 11 TitleButtons must have discernible text Issue DescriptionIt has been identified that 4 buttons on 2 pages have no name that a screen reader can announce. Buttons must have discernible text, such as a visible label or an aria-label. Why This MattersCustom controls without proper names, roles and states are announced as meaningless elements. Screen reader users cannot tell what a control is, what it does or whether it is selected. Recommended FixElement does not have inner text that is visible to screen readers WCAG Criteria & Axe Rule Success criterion4.1.2 Name, Role, Value Conformance levelLevel A Axe ruleButton-name DocumentationRule documentation CloseCopy Ticket Content

Text description: Accessibility Ticket overlay for the rule Button-Name, ticket 1 of 11

Example of the Accessibility Ticket overlay for the rule Button-Name, ticket 1 of 11, with previous, next and close buttons. Sections show the Title, Buttons must have discernible text; the Issue Description, saying that 4 buttons on 2 pages have no name that a screen reader can announce and that buttons must have discernible text, such as a visible label or an aria-label; Why This Matters, explaining that custom controls without proper names, roles and states are announced as meaningless elements; the Recommended Fix; and WCAG Criteria and Axe Rule, listing success criterion 4.1.2 Name, Role, Value, conformance level A, axe rule Button-name, and rule documentation. The footer has Close and Copy Ticket Content buttons.

4. Fix the pattern, not the page

Most sites are built from shared templates and components. When the same issue appears on many pages, look for the header, footer, card, form or menu they have in common, and fix it there. One change to a shared component can clear an issue across the whole site.

Use Copy Selector and Copy HTML on each instance to find the component in your code.

5. Check what automation can't

Automated testing finds a meaningful share of accessibility problems, but not all of them. Before calling a site accessible, check these by hand:

• Keyboard: Reach and use every link, button and form control with Tab, Enter, Space and the arrow keys. Check that focus is always visible, follows a logical order and never gets stuck in a menu or dialog.
• Screen readers: Listen to the page with a screen reader such as VoiceOver or NVDA. Check that headings, labels, buttons and status messages make sense when read aloud, in a sensible order.
• Zoom and reflow: Zoom to 200% and 400%. Check that nothing is cut off and that you don't need to scroll sideways to read text.
• Meaning and content: Check that text alternatives are accurate, link text makes sense out of context, error messages explain how to fix the problem and instructions don't rely on colour or shape alone.
• Media: Check that videos have accurate captions and that audio has a transcript.
• Movement and time: Check that moving content can be paused, nothing flashes and time limits can be extended or turned off.
• What the scan didn't reach: Check the report's Skipped Pages and error sections, and test any pages, states or signed-in areas the scan didn't cover.

Scope of Automated Testing explains why these areas need a person.

6. Re-scan to confirm

Run the same scan again after fixes are released. Save your settings as a configuration in Save & Load Configurations, or use the report's Export Settings and import the file with Import File. Compare the new report with the old one to confirm that issues have gone and nothing new has appeared.

Octopus Scanner doesn't compare reports for you, but the companion CSVs make it straightforward in a spreadsheet:

1. Open the companion CSV from each scan in your spreadsheet app. The column headings are on the fifth row, after three lines of notices and a blank line, or on the sixth row if the scan finished early.
2. In each sheet, add a column that joins Issue ID, URL/File, Viewport and CSS Selector, so every instance has its own key.
3. Look up each key from the old sheet in the new one. Keys that are missing have been fixed, and keys that appear only in the new sheet are new or have moved.
4. For a summary, count the rows for each Issue ID in both sheets and compare the totals.

Selectors can change when a page's markup changes, so check any instance that seems to have moved before you count it as fixed. Report File Formats describes every CSV column.

Keep each report. Together they show progress over time, and they are useful evidence when you write or update an accessibility statement.

7. Related guides

The User Guide covers each scan setting. If something isn't working as expected, see the Troubleshooting Guide.