From 06589106800c1cc7f1c61741bbc4e03340911370 Mon Sep 17 00:00:00 2001 From: Emma Mansell <73774046+7emansell@users.noreply.github.com> Date: Tue, 25 Aug 2026 09:52:23 -0400 Subject: [PATCH 1/4] Accessibility testing updates --- standards/accessibility.md | 2 ++ standards/manual-testing.md | 12 ++++++++++-- 2 files changed, 12 insertions(+), 2 deletions(-) diff --git a/standards/accessibility.md b/standards/accessibility.md index aef6c08..8157213 100644 --- a/standards/accessibility.md +++ b/standards/accessibility.md @@ -35,3 +35,5 @@ Developers MUST run their applications through web accessibility tools. Developers SHOULD have repo tools or IDE tools installed to help fix accessibility issues as they code. For example, the [eslint-plugin-jsx-a11y](https://github.com/evcohen/eslint-plugin-jsx-a11y) is an ESLint plugin that can be added to check for errors when running the app's code through ESLint. Some IDEs and text editors (Atom, for example), can pick up the configuration and tell you the errors as you code. +Developers SHOULD test their code with common screenreaders and magnification software. + diff --git a/standards/manual-testing.md b/standards/manual-testing.md index 5328564..4c42c3d 100644 --- a/standards/manual-testing.md +++ b/standards/manual-testing.md @@ -26,9 +26,10 @@ Manual testing should be reserved for scenarios that genuinely benefit from a se - New features or components - Complex integrations - Visual QA\* -- Accessibility testing\* +- Accessibility testing\*\* -_\*Note: Visual QA and Accessibility Testing are currently owned by the accessibility consultant and the design team, and the process for these types of testing remains unchanged at this time._ +\* Visual QA is owned by the design team. +\*\* Accessibility testing is owned by the accessibility consultant, but should be supplemented by manual testing. See [Developer Accessibility Testing](#developer-accessibility-testing). ```mermaid graph TD @@ -81,6 +82,12 @@ For guidance on our overall approach to automated testing, please refer to our [ The responsibility for writing tests isn't strictly divided between Engineers (unit tests) and QA Engineers (Playwright tests). The engineer developing a feature or fixing a bug should write the most appropriate test to ensure their code functions correctly and provides confidence in their work. QA Engineers will then supplement these efforts by identifying and addressing testing gaps, developing additional automated tests based on product requirements, ensuring automated tests are being written as part of the development process, and conducting regular manual testing, as detailed further in this document. +#### Developer Accessibility Testing + +While new patron-facing features always require a formal accessibility review, developers should ensure that all changes, including bug fixes and smaller enhancements, remain accessible to screen reader and magnification software users. This can be as simple as validating the expected user flow with JAWS enabled or with the browser zoomed to 400%. Developers can test with VoiceOver on their own machines, or use the shared Windows laptop to access JAWS, NVDA, and other Windows-only assistive technologies. + +Developers should also make use of automated accessibility testing wherever possible. Unit tests can verify expected ARIA labels, keyboard interactions, and focus management, while tools such as Axe DevTools can identify programmatic WCAG violations, like missing alternative text or improper heading structure. See our [accessibility standards](./accessibility.md) for more details. + ### The "Ready for QA" Column Revisited Historically, the "Ready for QA" column on Jira boards signified that a QA person needed to review and approve a ticket before it could progress. For many teams, this column became a bottleneck, with tickets lingering and waiting for manual testing. Some teams have since removed this column entirely and instead assign manual testing tickets directly to the QA Engineer. Others still use the column. @@ -104,6 +111,7 @@ Examples of how this document has been used for past projects: - [Staff Profiles: Accessibility/QA/UAT and Bug Tracking](https://docs.google.com/document/d/1RiK1fOHdrmJjzWlYlpHC697d-5SBlUirpvUU5qBpxJ8/edit?tab=t.0#heading=h.bngjjr7cfh5e) - [Research Catalog: Collection filter/ advanced search VQA/QA](https://docs.google.com/document/d/1CqQZg5vyHRm-0knUGnX8VBT54i06VLle32j0nyFcLIc/edit?usp=sharing) + ### Exploratory testing or _Spend time with your application_ Exploratory testing is basically where a tester learns about the software, figures out what to test, and then actually tests it all at the same time to find bugs. Instead of following a strict script, it's pretty loose and driven by the tester's gut, what they know, and their creative thinking. It's almost always a good idea to just play around with your app. Try to think like a user. Come up with weird scenarios and give them a shot. From e461c0883f9153c1d1fae7baa5a930ba500442e6 Mon Sep 17 00:00:00 2001 From: Emma Mansell <73774046+7emansell@users.noreply.github.com> Date: Tue, 25 Aug 2026 09:54:24 -0400 Subject: [PATCH 2/4] wording --- standards/manual-testing.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/standards/manual-testing.md b/standards/manual-testing.md index 4c42c3d..321932f 100644 --- a/standards/manual-testing.md +++ b/standards/manual-testing.md @@ -84,7 +84,7 @@ The responsibility for writing tests isn't strictly divided between Engineers (u #### Developer Accessibility Testing -While new patron-facing features always require a formal accessibility review, developers should ensure that all changes, including bug fixes and smaller enhancements, remain accessible to screen reader and magnification software users. This can be as simple as validating the expected user flow with JAWS enabled or with the browser zoomed to 400%. Developers can test with VoiceOver on their own machines, or use the shared Windows laptop to access JAWS, NVDA, and other Windows-only assistive technologies. +While new patron-facing features always require a formal accessibility review, developers should ensure that all changes, including bug fixes and minor features, remain accessible to screen reader and magnification software users. This can be as simple as validating the expected user flow with JAWS enabled or with the browser zoomed to 400%. Developers can test with VoiceOver on their own machines, or use the shared Windows laptop to access JAWS, NVDA, and other Windows-only assistive technologies. Developers should also make use of automated accessibility testing wherever possible. Unit tests can verify expected ARIA labels, keyboard interactions, and focus management, while tools such as Axe DevTools can identify programmatic WCAG violations, like missing alternative text or improper heading structure. See our [accessibility standards](./accessibility.md) for more details. From 9ab651ca9baaca991e53182be993174964887a2d Mon Sep 17 00:00:00 2001 From: Emma Mansell <73774046+7emansell@users.noreply.github.com> Date: Tue, 25 Aug 2026 09:55:45 -0400 Subject: [PATCH 3/4] wordingg --- standards/manual-testing.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/standards/manual-testing.md b/standards/manual-testing.md index 321932f..b5bfecb 100644 --- a/standards/manual-testing.md +++ b/standards/manual-testing.md @@ -84,7 +84,7 @@ The responsibility for writing tests isn't strictly divided between Engineers (u #### Developer Accessibility Testing -While new patron-facing features always require a formal accessibility review, developers should ensure that all changes, including bug fixes and minor features, remain accessible to screen reader and magnification software users. This can be as simple as validating the expected user flow with JAWS enabled or with the browser zoomed to 400%. Developers can test with VoiceOver on their own machines, or use the shared Windows laptop to access JAWS, NVDA, and other Windows-only assistive technologies. +While new patron-facing features always require a formal accessibility review, developers should ensure that all changes, including bug fixes and minor features, remain accessible to screen reader and magnification software users. This can be as simple as validating the expected user flow with JAWS enabled or with the browser zoomed to 400%. Developers can test with VoiceOver (MacOS) on their own machines, or use the shared Windows laptop to access JAWS, NVDA, and other Windows-only assistive technologies. Developers should also make use of automated accessibility testing wherever possible. Unit tests can verify expected ARIA labels, keyboard interactions, and focus management, while tools such as Axe DevTools can identify programmatic WCAG violations, like missing alternative text or improper heading structure. See our [accessibility standards](./accessibility.md) for more details. From 83bb1c4ce596aaa8c057f2684364370eefd0b971 Mon Sep 17 00:00:00 2001 From: Emma Mansell <73774046+7emansell@users.noreply.github.com> Date: Thu, 27 Aug 2026 13:57:09 -0400 Subject: [PATCH 4/4] Clarifications --- standards/accessibility.md | 2 +- standards/manual-testing.md | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/standards/accessibility.md b/standards/accessibility.md index 8157213..c9f4caa 100644 --- a/standards/accessibility.md +++ b/standards/accessibility.md @@ -35,5 +35,5 @@ Developers MUST run their applications through web accessibility tools. Developers SHOULD have repo tools or IDE tools installed to help fix accessibility issues as they code. For example, the [eslint-plugin-jsx-a11y](https://github.com/evcohen/eslint-plugin-jsx-a11y) is an ESLint plugin that can be added to check for errors when running the app's code through ESLint. Some IDEs and text editors (Atom, for example), can pick up the configuration and tell you the errors as you code. -Developers SHOULD test their code with common screenreaders and magnification software. +Developers SHOULD test their code with common screenreaders and magnification software. See [Developer Accessibility Testing](./manual-testing.md#developer-accessibility-testing) for more information. diff --git a/standards/manual-testing.md b/standards/manual-testing.md index b5bfecb..727e143 100644 --- a/standards/manual-testing.md +++ b/standards/manual-testing.md @@ -29,7 +29,7 @@ Manual testing should be reserved for scenarios that genuinely benefit from a se - Accessibility testing\*\* \* Visual QA is owned by the design team. -\*\* Accessibility testing is owned by the accessibility consultant, but should be supplemented by manual testing. See [Developer Accessibility Testing](#developer-accessibility-testing). +\*\* Accessibility testing is owned by the accessibility consultant, but should be supplemented by developers. See [Developer Accessibility Testing](#developer-accessibility-testing). ```mermaid graph TD