wpaccessibility · rianrietveld · Apr 29, 2026 · Apr 29, 2026 · May 5, 2026 · Jun 17, 2026
diff --git a/docs/about/disclaimer.md b/docs/about/disclaimer.md
@@ -17,4 +17,4 @@ When relevant in the documentation, we add links to the official WCAG documentat
 
 If you are conducting an accessibility review, an accessibility audit, or researching legal requirements, please refer directly to the [official WCAG documentation](https://www.w3.org/WAI/standards-guidelines/wcag/) by the W3C.
 
-If you find documentation on this website that is in conflict with WCAG 2.2 AA, please let us know by  [contacting the team]({{site.baseurl}}//docs/about/contact/).
+If you find documentation on this website that is in conflict with WCAG 2.2 AA, please let us know by  [contacting the team]({{site.baseurl}}/docs/about/contact/).
diff --git a/docs/accessibility-ready/theme-guidelines/skip-to-content.md b/docs/accessibility-ready/theme-guidelines/skip-to-content.md
@@ -39,6 +39,12 @@ For every template being tested:
 
 The skip link must be tested on all page templates provided by the theme (home page, blog archive, post single, etc.), as its functionality on one page does not guarantee that it will work throughout the theme.  
 
-## WCAG resources
+## Resources
 
-* [Understanding: Bypass Blocks](https://www.w3.org/WAI/WCAG22/Understanding/bypass-blocks.html)
+### WCAG Success Criteria for skip links
+
+Adding a skip link is necessary to meet the WCAG success criterion [2.4.1 Bypass Blocks](https://www.w3.org/WAI/WCAG22/quickref/#bypass-blocks), (Level A).
+
+### Related pages in this documentation
+
+- Standards and best practice - Frontend code - Components: [Skip links]({{site.baseurl}}/docs/topics/code/components/skip-links/).
diff --git a/docs/testing/automated/index.md b/docs/testing/automated/index.md
@@ -1,83 +1,49 @@
 ---
-title: Automated validation
+title: Automated testing
 layout: default
 parent: Test for accessibility
 description: Learn about automated accessibility testing and validation.
-nav_order: 5
+nav_order: 2
+contributors:
+  - Rian Rietveld
 ---
 
 # Automated accessibility testing
 
-## WCAG 2 AA automated validation
+With automated accessibility testing, it is important to check against the generated DOM, the frontend of your web project. This is different from, for example, PHP code standard checks where you can perform checks on the code base. You need to run checks on a working WordPress site.
 
-The generated DOM, the front end of your web project, must conform to WCAG 2 AA. You can use automated validation to get a limited scope of your success at this.
+Automated accessibility testing doesn't catch all accessibility errors at this moment, so additional manual testing stays needed. Testing in the browser and manual keyboard testing still need to be part of your workflow.
 
-Recommended:
+## Recommended testing tools
 
-- [aXe browser addon](https://www.deque.com/aXe/) for Chrome and FireFox. The addon adds a tab to your inspector with a validate button. After validating you see the errors and warnings for that particular webpage and how to fix them. Make sure to also test in different views and with the menu open and closed, for example.
-- [HTML_CodeSniffer](http://squizlabs.github.io/HTML_CodeSniffer/)
-- Accessibility Inspector in the [Firefox Developer Tools](https://developer.mozilla.org/en-US/docs/Tools). A good read about this by Marco Zehe:  How to use [NVDA and Firefox to test your web pages for accessibility](https://www.marcozehe.de/how-to-use-nvda-and-firefox-to-test-your-web-pages-for-accessibility/)
+### Axe-core
 
-More tools:
+[Axe-core](https://github.com/dequelabs/axe-core-npm) by DeQue is an accessibility testing engine for websites and other HTML-based user interfaces.
 
-- [React-a11y](https://github.com/reactjs/react-a11y), Identifies accessibility issues in your React.js elements
-- Static AST checker for [a11y rules on JSX elements](https://github.com/evcohen/eslint-plugin-jsx-a11y)
-- More [Toolbars and toolkits ](https://make.wordpress.org/accessibility/handbook/which-tools-can-i-use/useful-tools/#toolbars-toolkits) in the Accessibility Handbook
+[axe-core-npm](https://github.com/dequelabs/axe-core-npm) offers packages like @axe-core/cli and @axe-core/react, which can be used for automated accessibility testing powered by axe core.
 
-## Automated testing
+[Playwright Accessibility testing](https://playwright.dev/docs/accessibility-testing) uses Axe. Accessibility tests work just like any other Playwright test. You can either create separate test cases or integrate accessibility scans and assertions into your existing test cases. NPM package: [@axe-core/playwright](https://www.npmjs.com/package/@axe-core/playwright).
 
-The big difference between PHP and JavaScript code standard checks and accessibility checks is that the accessibility checks need to be performed on the generated DOM, not on the code base. You need to run checks on a working WordPress site. This can be done using automation that sets up your environment dynamically, but still requires a fully built and run installation.
+Axe is also available as [aXe Devtools browser addon](https://www.deque.com/axe/devtools/extension/). The addon adds a tab to your inspector with a "validate" button. After validating you see the errors and warnings for that particular webpage and how to fix them. Available as a free limited version and as a paid Pro version. 
 
-There are several command line tools for automated testing like [aXe-cli](https://github.com/dequelabs/axe-cli) and [pa11y](https://github.com/pa11y/pa11y).
+[Google LightHouse for Chrome](https://developer.chrome.com/docs/lighthouse) uses axe-core under the hood.
 
-{: .callout  .info }
-**Info:** Automated accessibility testing doesn’t catch all the issues, rarely more than 30%. Testing in the browser and manual keyboard testing still needs to be part of your workflow.
+### IBM Equal Access Accessibility Checker
 
-### Setup for aXe-cli
+On the Wiki Page of [The IBM Equal Access Accessibility Checker](https://github.com/IBMa/equal-access/wiki) is an open-source freely available set of tools for web developers and accessibility auditors. 
 
-Install axe-core for CLI first:
+- The **accessibility-checker-engine** uses a set of rules that map to accessibility standards to detect accessibility issues in web content and applications. 
+- The **accessibility-checker-extension** integrates into browser DevTools, providing an integrated scanning experience, a keyboard checker mode visualization, and helps users quickly identify the source of accessibility issues, understand what to do, and try fixes. The Checker is also available as a package for CI/CD environments and automated testing frameworks.
 
-```
-npm install axe-cli -g
-npm install chromedriver –g`
-```
 
-Then run axe in the command line:
+### W3C Validators and tools
 
-```
-axe url -b c
-```
+The W3C maintains a page with [links to the test tools](https://www.w3.org/developers/tools/) they provide, like the Nu HTML Checker, CSS Validator, and Link Checker to test your work. Including a W3C API.
 
-The url can be any url, also a local one. You get a report of the accessibility issues for that url. The **-b** stands for browser, **c** for chrome, as this browser gives the best results (better than the default PhantomJS). You will get the errors and warnings in your console.
+### Pa11y
+[Pa11y](https://github.com/pa11y/pa11y), runs accessibility tests on your pages via the command line or Node.js, so you can automate your testing process. 
 
-You can provide more (space separated) urls to the command like
+## Resources
 
-```
-axe url url2 url3 -b c
-```
+Research by Adrian Roselli: [Comparing Manual and Free Automated WCAG Reviews](https://adrianroselli.com/2023/01/comparing-manual-and-free-automated-wcag-reviews.html). This recommended post is updated regularly.
 
-or call a file with urls like:
-
-```
-axe $( cat list-of-urls.txt ) -b c
-```
-
-**Note**:  You can run [axe-cli on more than one url](https://make.wordpress.org/accessibility/handbook/best-practices/test-for-web-accessibility/test-for-web-accessibility-frontend-code/#setup-for-axe-cli) in one command, but axe-cli is not build to run on a large amount of urls or on a complete site, axe-cli is not a crawler. Deque Labs recommends to use the [axe-webdriverjs](https://www.npmjs.com/package/axe-webdriverjs), a chainable aXe API for Selenium’s WebDriverJS for testing on a large amounts of urls.
-
-### Setup for pa11y
-
-The [setup for pa11y](https://github.com/pa11y/pa11y) is well documented in the GitHub repository.
-
-
-## Browser Toolbars & Toolkits
-
-- [aXe accessibility testing tool](https://www.deque.com/products/axe/) — available as browser extension and npm module ([axe-core](https://github.com/dequelabs/axe-core))
-- [WAVE](http://wave.webaim.org/toolbar) — run the WAVE accessibility evaluation tool within Firefox and Chrome.
-- Accessibility inspector in the FireFox developer tools
-- [AInspector for WCAG Accessibility Evaluation](https://addons.mozilla.org/en-US/firefox/addon/ainspector-wcag/) — Inspect web pages for potential accessibility issues.
-- [Tota11y](http://khan.github.io/tota11y/) — An accessibility visualization toolkit that can be dragged into your bookmarks bar or installed as a plugin.
-- [Total Validator](http://www.totalvalidator.com/) — an HTML validator, accessibility validator, spell checker, and broken link checker all rolled into one tool. Free & commercial versions available.
-- [HeadingsMap](https://chrome.google.com/webstore/detail/headingsmap/flbjommegcjonpdmenkdiocclhjacmbi?hl=es) — A [Chrome](https://chromewebstore.google.com/detail/headingsmap/flbjommegcjonpdmenkdiocclhjacmbi?pli=1) or [Firefox extension](https://addons.mozilla.org/en-us/firefox/addon/headingsmap/) that shows the structure of headings on a webpage.
-- [Visual ARIA Bookmarklet](http://whatsock.com/training/matrices/visual-aria.htm) — A bookmarklet to visually display ARIA attributes on a webpage.
-- [Accessibility Testing Tools for Desktop and Mobile Websites](https://www.24a11y.com/2017/accessibility-testing-tools-desktop-mobile-websites/) – A review of testing tools by Paul J. Adam.
-- [Accessibility Bookmarklets](https://www.digitala11y.com/accessibility-bookmarklets-testing/) – A collection of bookmarklets useful for accessibility testing.
diff --git a/docs/testing/checklists/code.md b/docs/testing/checklists/code.md
diff --git a/docs/testing/checklists/content.md b/docs/testing/checklists/content.md
Original file line number	Diff line number	Diff line change
Expand Up		@@ -17,4 +17,4 @@ When relevant in the documentation, we add links to the official WCAG documentat

		If you are conducting an accessibility review, an accessibility audit, or researching legal requirements, please refer directly to the [official WCAG documentation](https://www.w3.org/WAI/standards-guidelines/wcag/) by the W3C.

		If you find documentation on this website that is in conflict with WCAG 2.2 AA, please let us know by [contacting the team]({{site.baseurl}}//docs/about/contact/).
		If you find documentation on this website that is in conflict with WCAG 2.2 AA, please let us know by [contacting the team]({{site.baseurl}}/docs/about/contact/).