Problem/Motivation

The project pins @vardot/varbase-e2e at ^2.0.5. 2.0.7 makes the impact gate cumulative, so no serious accessibility violations now also fails on critical, adds a one step full check and an element level rule check, and makes the structural probes skip anything assistive technology cannot reach. Release: varbase-e2e 2.0.7.

The accessibility coverage in tests/features/15-quality is 10 scenarios, and nearly all of them look at the homepage, so a regression on any other public page goes unnoticed.

Steps to reproduce

  1. Install Varbase 11 from this project template and run the 15-quality suite.
  2. 10 accessibility scenarios run, and only the front page is really audited.

Proposed resolution

  • Update @vardot/varbase-e2e to ^2.0.7 and regenerate yarn.lock. CI runs yarn install and yarn 4 is immutable in CI, so a package.json bump without the lock fails the job.
  • Rewrite 15-02-accessibility.feature to 34 scenarios: one gate per public page, with the rules that matter pinned by id.
  • Add 15-05-accessibility-structure.feature, 15 scenarios for the page title, the language attribute, a single h1, heading order, landmarks, the skip link, zoom, control names, ARIA references and roles, and positive tabindex.

49 of 49 scenarios pass on a fresh Varbase 11 install with vartheme_bs5 5.0.4.

Remaining tasks

  • ✅ File an issue
  • ✅ Addition/Change/Update/Fix
  • ❌ Raise About Varbase, Features, Blog and Contact Us from a level A audit to no serious accessibility violations once the colour contrast of .btn-outline-primary text on a bg-secondary-subtle card is resolved. About 3.6:1 against the 4.5:1 AA threshold, 2 to 3 nodes per page. Owned by vartheme_bs5 and the recipe content, not by this change.
  • ❌ Turn I print the full accessibility check into the asserting the page should pass the full accessibility check once the site wide search block has an accessible label. views.view.search exposes its keyword filter with an empty label and only a Search by keyword placeholder, and it ships from the drupal_cms_search recipe, so it affects the Varbase base too. The full check always runs the structural probes, so no audit level avoids it.
  • ❌ Restore the form field label probe on Contact Us and Blog once that same search label is fixed. It is pinned to /user/login for now.
  • ❌ Renumber 15-05-accessibility-structure.feature if the unpushed local work that already uses 15-04-drimage-images.feature does not land.
  • ✅ Testing to ensure no regression
  • ✅ Automated unit/functional testing coverage
  • ✅ Developer Documentation support
  • ➖ User Guide Documentation support
  • ➖ UX/UI designer responsibilities
  • ➖ Accessibility and Readability
  • ❌ Reviewed by a human
  • ❌ Code review by maintainers
  • ❌ Full testing and approval
  • ❌ Credit contributors
  • ❌ Review with the product owner
  • ✅ Update Release Notes
  • ✅ Release

User interface changes

  • N/A

API changes

  • N/A

Data model changes

  • N/A

Release notes snippet

  • Updated @vardot/varbase-e2e to 2.0.7 and widened the automated accessibility coverage from 10 to 49 scenarios across every public page.
Command icon Show commands

Start within a Git clone of the project using the version control instructions.

Or, if you do not have SSH keys set up on git.drupalcode.org:

Comments

rajab natshah created an issue. See original summary.

  • rajab natshah committed 0c264a1d on 11.0.x
    task: #3625609 Update @vardot/varbase-e2e to 2.0.7 and widen the...
rajab natshah’s picture

Issue summary: View changes
Status: Active » Fixed
Issue tags: +varbase_project-11.0.10

Now that this issue is closed, review the contribution record.

As a contributor, attribute any organization that helped you, or if you volunteered your own time.

Maintainers, credit people who helped resolve this issue.