♿ TetraLogical: Accessibility notes for the documentation (#30018)

* Accessibility notes for the documentation

Add pointers to accessibility in some of the most appropriate sections of the initial documentation.

Includes addition of a new design principle around inclusivity/accessibility.

* Update contributing/getting-started-e2e.md

Co-authored-by: Caroline Liu <10456171+caroqliu@users.noreply.github.com>

Co-authored-by: Caroline Liu <10456171+caroqliu@users.noreply.github.com>

contributing/DESIGN_PRINCIPLES.md

@@ -28,6 +28,10 @@ Don’t introduce components or features to AMP that can’t reliably run at 60f
 
 Some things can be made fast and are still a terrible user experience. AMPs should deliver a fantastic user experience and speed is just one part of that. Only compromise when lack of support for something would stop AMP from being widely used and deployed.
 
+## Be inclusive
+
+Remember that people have different abilities and use AMP in different ways, on different devices, and sometimes with assistive technologies. Make sure that AMP is accessible and usable by everyone.
+
 ## No "nicelists" or "allowed lists".
 
 We won’t give any special treatment to specific sites, domains or origins except where needed for security or performance reasons.

contributing/contributing-code.md

@@ -77,6 +77,9 @@ Once you have found a guide, make sure to @-mention them on any issues / PRs rel
       - Learn to create your first component in this [codelab](https://codelabs.developers.google.com/codelabs/creating-your-first-amp-component/#0)
       - Watch this [YouTube video](https://youtu.be/FJEhQFNKeaQ?list=PLXTOW_XMsIDTDXYO-NAi2OpEH0zyguvqX) to learn about "Building a new AMP component"
     - **Integrating third-party software, embeds, services**: [Guidelines](../3p/README.md)
+    - **Accessibility**:
+      - [Web Fundamentals - Accessibility](https://developers.google.com/web/fundamentals/accessibility/)
+      - [web.dev Lighthouse accessibility audits guide](https://web.dev/lighthouse-accessibility/)
   - [Put your change behind an experiment flag](./building-an-amp-extension.md#experiments) unless it is a minor fix or your reviewer indicates this is not needed.
   - [Commit your files](./getting-started-e2e.md#edit-files-and-commit-them).
 - [Test your changes](./getting-started-e2e.md#testing-your-changes).

contributing/getting-started-e2e.md

@@ -464,6 +464,12 @@ Testing tips:
 
 For more help, see [How to get help](#how-to-get-help).
 
+# Perform manual tests
+
+Beyond technical/automated tests, manually test your changes and make sure that they work as expected, and that they follow AMP's [design principles](https://github.com/ampproject/amphtml/blob/master/contributing/DESIGN_PRINCIPLES.md). In particular, make sure that your changes are accessible - see [W3C WAI Easy Checks](https://www.w3.org/WAI/test-evaluate/preliminary/) for an initial set of suggested manual tests. Some aspects of manual testing can be semi-automated, using tools such as [Lighthouse](https://developers.google.com/web/tools/lighthouse) (which includes an accessibility audit report) and [Microsoft's Accessibility Insights](https://accessibilityinsights.io/).
+
+Note that for more extensive automated accessibility testing, there are further options available that integrate directly within existing test/integration workflows, such as [Deque's axe-core](https://github.com/dequelabs/axe-core).
+
 # Push your changes to your GitHub fork
 
 Up to this point you've been making changes in a branch on your local repository. Those changes aren't visible anywhere else--not even your GitHub fork--so if you want other people to see your changes you will need to push your branch to your GitHub fork. This is a necessary step to request a code review (known as a pull request) and to ultimately get your changes added to the amphtml repository.