[shethj]

Description

We run a11y tests with E2E on per-pr as well as nightly workflows. The current setup was split up between running a11y on public client storefront for nightly and private client for per-pr workflows.

This caused storefront setups with different storefrontdata and required different sets of snapshots.
A snapshot for a11y is basically a set of known violations for a storefront.

The issue now is whenever a PR updates snapshots (removes violations because they fixed something), we need to sync snapshots on the other workflow.

To avoid this, a better idea is to run both per-pr and nightly workflow against a private client setup so the storefront setup is the same and we can use 1 set of snapshots and avoid having to maintain a sync between the two.

This PR updates tests, workflows and playwright config to run against a single set of snapshots.

Types of Changes

• Bug fix (non-breaking change that fixes an issue)
• New feature (non-breaking change that adds functionality)
• Documentation update
• Breaking change (could cause existing functionality to not work as expected)
• Other changes (non-breaking changes that does not fit any of the above)

Breaking changes include:

• Removing a public function or component or prop
• Adding a required argument to a function
• Changing the data type of a function parameter or return value
• Adding a new peer dependency to package.json

Changes

• Update playwright config
• Update e2e and e2e-pr workflows to run updated a11y test
• Rename snapshot directories

How to Test-Drive This PR

• https://github.com/SalesforceCommerceCloud/pwa-kit/actions/runs/18725700686

Checklists

General

• Changes are covered by test cases
• CHANGELOG.md updated with a short description of changes (not required for documentation updates)

Accessibility Compliance

You must check off all items in one of the follow two lists:

• There are no changes to UI

or...

• Changes were tested with a Screen Reader (iOS VoiceOver or Android Talkback) and had no issues
• Changes comply with WCAG 2.0 guidelines levels A and AA
• Changes to common UI patterns and interactions comply with WAI-ARIA best practices

Localization

• Changes include a UI text update in the Retail React App (which requires translation)

[cc-prodsec]

✅ Snyk checks have passed. No issues have been found so far.

Status	Scanner	Critical	High	Medium	Low	Total (0)
✅	Licenses	0	0	0	0	0 issues
✅	Open Source Security	0	0	0	0	0 issues

💻 Catch issues earlier using the plugins for VS Code, JetBrains IDEs, Visual Studio, and Eclipse.

[alexvuong]

Which instance are snapshots created on? Some of the violations are gone which look strange to me. We know there are some violations that can't be fixed due to the fact it comes from Chakra UI.

[alexvuong]

This one can't never be fixed, it requires the change from Chakra UI component which we have no control off, I am wondering why it is not detected

[shethj]

Umm... I still see the violation as a part of the snapshot. So it is being detected. This deletion change is not really removing the violation. We had 2 separate copies of snapshots and I deleted one of them. But the violations are still a part of the other copy.

[shethj]

Yeah. Agreed. It is still a part of the snapshots as known violation.

[alexvuong]

oh i see, sorry I did not realize we are having 3 snapshot batches. Makes sense!

[alexvuong]

@shethj Dumb question, using the same private setup is a good start, but may not be enough.
I am wondering how are these sites look like on MRT? Are they sharing the same config on deployment (e.g if RefArch vs RefArchGlobal in same client, or if the Productile Config is also affect the data being returned from api despite using the same client/store data)

[shethj]

@shethj Dumb question, using the same private setup is a good start, but may not be enough. I am wondering how are these sites look like on MRT? Are they sharing the same config on deployment (e.g if RefArch vs RefArchGlobal in same client, or if the Productile Config is also affect the data being returned from api despite using the same client/store data)

After this PR is merged the setups will be identical. Both using the same instance, same site, same SLAS Client.