Update checklists.md

_playbook/checklists.md

@@ -1,7 +1,7 @@
 ---
 layout: playbook
-title: Use checklists
-description: 
+title: Using checklists in an accessibility strategy
+description:  How to incorporate checklists into a comprehensive accessibility strategy.
 excerpt: 
 sidenav: docs
 categories:
@@ -13,53 +13,43 @@ roles:
   - Project manager
   - UX designer
 ---
-Checklists can be helpful for teams. They are usually insufficient to move an organization beyond a limited compliance mindset. There is no single checklist that covers all WCAG issues. As Intopia warned, [a checklist mentality can actually be harmful for inclusion](https://intopia.digital/articles/announcing-the-accessibility-not-checklist/). That said, if approached as part of a broader strategy, they can be very helpful. We recommend that teams might want to customize one to better meet their needs. Access Armada has some interesting suggestions on [more strategic approaches to checklists](https://www.accessarmada.com/blog/building-accessibility-checklists-that-are-actually-useful/). Ultimately though, regularly reviewing your checklists is important. They can be a powerful tool for teams to keep learning how to create more inclusive content.
+The purpose of an accessibility checklist is to help identify accessibility issues in your product, website, or document. However, incorporating checklists  into an accessibility strategy can often be tricky.  One of the most common pitfalls when using or thinking about checklists is making sure you don’t get stuck in a limited compliance mindset. There is no single checklist that covers all possible accessibility issues and as Intopia warned, [a checklist mentality can actually be harmful for inclusion](https://intopia.digital/articles/announcing-the-accessibility-not-checklist/). That said, if approached as part of a broader strategy, they can be very helpful when used thoughtfully. Access Armada has some interesting suggestions on [more strategic approaches to checklists](https://www.accessarmada.com/blog/building-accessibility-checklists-that-are-actually-useful/). 
 
-Microsoft's [Accessibility Insights](https://accessibilityinsights.io/) has both a FastPass and Assessment component. The Assessment component guides users through doing a manual review. Using this tool, organizations could:
-
-* Run the FastPass's automated axe checks on every page.
-* Check that the Tab stops follow a logical order when navigating with a keyboard.
-* Look over the elements that are marked Needs reviews to see if there are elements where a manual review can identify whether it is an issue or not.
-* Complete the rest of the assessment to ensure that the page meets WCAG requirements.
-
-This is a time consuming process, but would give the reviewer a high level of confidence that the site has good accessibility. 
-
-One could also look to use a tool like WebAim's WAVE, ANDI, or Tota11y to scan a web page for errors. In which case a reviewer could do something like this:
-
-* Scan the page with the WAVE Toolbar:
-    * Look for clear errors (red boxes with an X in them).
-    * See if the alt text effectively describes the images on the page.
-    * Ensure that there is sufficient color contrast.
-* Do keyboard only testing (using just tab, shift-tab, arrow keys & escape) to navigate the page.
-* Evaluate page for plain language using free tools like the [HemingwayApp](https://www.hemingwayapp.com/).
-* Magnify the page up to 200% and look for usability and readability issues.
+## What makes a good accessibility checklist
+* The checklist should build on automated testing approaches.
+* Provide role-based checklists so that different people in the organization are focused on different aspects of accessibility.
+* Checklists should be short, concise and easily understood by the majority of the team.
+* Allow for iteration of the checklists is needed - they may need to change depending on the element or learnings after going through the process a few times. 
 
-There are lots of checklists, rotating through a few of them will help give different people different things to think about accessibility:
+## Example checklists
+Sometimes, you don’t need to reinvent the wheel. If there’s already an existing checklist available, you can customize it to fit the needs of your team and product. Below are a few examples of existing accessibility checklists:
 
 * [W3C's Web Accessibility Initiative (WAI)](https://www.w3.org/WAI/test-evaluate/preliminary/)
+  * Basic checklist, not designed to be fully robust but rather to give you a starting point 
 * [18F - USA Government](https://accessibility.18f.gov/checklist/)
-* [UK's Government Digital Services (GDS)](https://gds.blog.gov.uk/2014/01/13/a-checklist-for-digital-inclusion-if-we-do-these-things-were-doing-digital-inclusion/)
-* [WebAim](https://webaim.org/standards/wcag/checklist)
-* [Elsevier's WCAG 2.1 Checklist](https://romeo.elsevier.com/accessibility_checklist/)
+  * Checklist geared toward US federal websites
 * [A11yProject](https://www.a11yproject.com/checklist/)
+  * Robust checklist using WCAG criteria and broken update into element categories (e.g. Content, Images, etc.) with understandable action items
 * [Heydon Works](https://github.com/Heydon/inclusive-design-checklist)
+  * Checklist that includes not just items regarding accessibility but other inclusive design checks as well - device support, language, etc.
 * [VoxMedia](https://accessibility.voxmedia.com/)
-* [PSU](https://accessibility.psu.edu/checklist/)
-* [Yale](https://usability.yale.edu/web-accessibility/articles/wcag2-checklist)
-* [University of Washington](https://www.washington.edu/accessibility/checklist/)
-* [tmobile's A11yEngineer](https://github.com/tmobile/magentaA11y)
-* [dev.to's Web Accessibility Cheat Sheet](https://dev.to/codegino/web-accessibility-cheat-sheet-3774#aria)
-* [The Book on Accessibility](https://www.thebookonaccessibility.com/)
+  * Checklist broken down into categories for various practices area/role
 * [Intopia's Accessibility Not-Checklist](https://not-checklist.intopia.digital/)
+  * This checklist can be customized directly on the site by specific WCAG standards and it can be filtered to display items by either topic or role
 
-## Checklist
+## Create your own checklist
+While there are many checklists already out there and that can be customized to fit your needs, you don’t necessarily need to use something preexisting. Using an existing automated scanning tool, you could create your own simple checklist process.
 
-* Have a checklist that builds on automated testing approaches.
-* Provide role-based checklists so that different people in the organization are focused on different aspects of accessibility.
-* Change your checklists so that new elements can be improved.
-* Ensure checklists are short and concise enough that they are used.
+For example, using a tool like [WebAim's WAVE](https://wave.webaim.org/), organizations could create a checklist to:
+
+1. Scan the page with the WAVE scanning tool. View the details tab of the results console:
+   1. Review each error - designated by a red box with an X
+   2. Review each alert - designated by an orange triangle with an exclamation point
+2. [Do manual testing](https://accessibility.civicactions.com/playbook/manual-testing) of the page
+3. Evaluate the page for [plain language](https://accessibility.civicactions.com/guide/plain-language) using free tools like the [HemingwayApp](https://www.hemingwayapp.com/).
 
-## Key questions
+## Next steps
+When you are ready to learn more, here are some further guides and resources that may help:
+* [Manual testing](https://accessibility.civicactions.com/playbook/manual-testing)
+* [Automated testing](https://accessibility.civicactions.com/playbook/automated-testing)
 
-* Are you making good use of the time and attention of your staff?
-* Are the checklists boring, or supporting your team?