This epic groups all issues that aim to set up GitLab with automates accessibility checks using axe-core-gem. > [!NOTE] Shifting to Dedicated Accessibility Feature Specs for User Journeys > GitLab has been integrating axe automated accessibility checks into feature tests across the codebase. The current approach includes accessibility assertions within existing functional feature specs. However, as of ~"FY26::Q4" we are shifting to a new strategy: **dedicated accessibility-only feature specs that focus on complete user journeys**. ## The Strategic Shift **From:** Accessibility checks embedded in every feature spec\ **To:** Dedicated accessibility specs that test complete golden user journeys This represents a fundamental change in how we approach accessibility testing at GitLab. ## Why This Change Matters ### Resource efficiency * Eliminates redundant testing of shared elements (navigation, breadcrumbs) that appear across multiple views * Reduces test execution time by consolidating accessibility checks * Focuses resources on high-impact user flows rather than individual page components ### Test reliability * Uses mocked data for consistent, reproducible results * Isolates accessibility checks from functional test failures * Prevents functional test flakiness from blocking accessibility validation ### Better ownership and scalability * Separate folder structure makes accessibility specs easy to identify and maintain * Clear delegation model enables stage groups to own their journey coverage * Provides reusable boilerplate and guidelines for consistent implementation ### Journey-focused coverage **Key principles:** * **Mocked data**: Controlled test environment ensures consistent results * **Isolated checks**: Accessibility assertions separate from functional tests * **Journey-based**: Tests complete workflows, not individual pages * **Comment-driven templates**: Engineers fill in implementation details based on existing specs * Tests accessibility across complete user workflows, not just isolated pages * Mirrors how real users interact with GitLab * Prioritizes golden journeys based on actual user traffic data ## What This Means for Teams **Stage groups will:** * Receive boilerplate templates and clear implementation guidelines * Focus on translating golden journeys relevant to their stage * Own accessibility coverage for their critical user flows * Use reference implementations as examples **We're starting with:** * ~"devops::create" and ~"devops::plan" stages (highest user traffic) * Golden journey test cases as the foundation * One reference implementation to demonstrate best practices ## Technical Context This approach addresses limitations discovered during technical investigation: * E2E tests with real data produced inconsistent results * Coupling between functional and accessibility checks created dependencies * Test ownership transfer to stage groups required more maintainable structure The new approach builds on existing accessibility testing infrastructure while providing a more scalable, reliable framework for comprehensive coverage. --- ## Metrics :chart_with_upwards_trend: - Historical trends for included axe checks in feature tests: https://gitlab-org.gitlab.io/frontend/playground/accessibility-scanner/history - Accessibility scanner dashboard with the current state of implementation: https://gitlab-org.gitlab.io/frontend/playground/accessibility-scanner/