Conducting accessibility audits and producing ACRs

This is an example process for conducting accessibility audits. The results could feed into an ACR (Accessibility Conformance Report).

1. Make a page-level testing list.
   1. If the previous ACR contains a page-level testing list in the appendix, use that as a starting point.
   2. Note: WCAG 2.1 conformance at any level can only be claimed for whole pages (not parts of pages).
2. Run the aXe browser extension. This is a good tool to run first since its philosophy of 'zero false positives' means the list of errors is usually short.
3. Run the ARC toolkit browser extension (Chrome only). This is a good tool to run next since it will flag more errors, and provides an easy way of inspecting the accessibility of semantic structures such as headings, landmarks, links, buttons, form controls, and alt text.
4. Do the assessment option of Microsoft Accessibility Insights browser extension (Chrome only). This is a good tool to use next because it offers good coverage of the WCAG SC (Success Criteria). It's a reasonably lengthy process, but gets faster with practice.
5. Test with a screen reader.
   1. As a minimum, we test with NVDA with Firefox on Windows (via a VM, for Ubuntu users) or VoiceOver with Safari on MacOS.
   2. Where possible we also test with JAWS on Windows, TalkBack on Android, and VoiceOver on iOS.
6. Do a final read-through of the WCAG SC. How to Meet WCAG (Quick Reference) (filtered for levels A and AA, excluding SMIL, PDF, Flash, and Silverlight) is more readable way of doing this than going straight to the official specification.
7. Log tickets with the results, filed as high-priority bugs.
8. Complete the ACR for each SC (Supports, Partially Supports, Does Not Support, Not Applicable). 
   1. In Remarks and Explanations note:
      1. How we're meeting the SC for Supports.
      2. That bugs have been filed for Partially Supports or Does Not Support.
   2. Update the Summary section.