Accessibility testing in Testing Fundamentals - Framework Patterns

Framework Mode - Accessibility testing

Folder Structure

accessibility-testing-project/
├── tests/
│   ├── accessibility/
│   │   ├── homePageAccessibility.test.js
│   │   ├── loginPageAccessibility.test.js
│   │   └── formAccessibility.test.js
│   └── utils/
│       └── axeHelper.js
├── reports/
│   └── accessibility-reports/
├── config/
│   └── accessibility.config.js
├── package.json
└── cypress.config.js
  

Test Framework Layers

• Test Scripts: Located in tests/accessibility/, these contain accessibility tests for different pages or components.
• Utilities: Helpers like axeHelper.js wrap accessibility tools (e.g., axe-core) for easy use in tests.
• Configuration: Holds environment settings, browser options, and accessibility rules in config/accessibility.config.js.
• Reports: Stores generated accessibility reports in reports/accessibility-reports/ for review.
• Test Runner Config: cypress.config.js or similar config files set up the test environment and plugins.

Configuration Patterns

Accessibility testing configuration includes:

• Environment Settings: Define URLs and environments (dev, staging, prod) in config files.
• Accessibility Rules: Customize axe-core rules to enable/disable specific checks based on project needs.
• Browser Settings: Configure browsers and viewports to test accessibility across devices.
• Credentials: Store securely if tests require login to access pages.

// Example: config/accessibility.config.js
export const accessibilityConfig = {
  baseUrl: "https://example.com",
  axeOptions: {
    rules: {
      'color-contrast': { enabled: true },
      'label': { enabled: true }
    }
  },
  browsers: ['chrome', 'firefox'],
  credentials: {
    username: process.env.TEST_USER,
    password: process.env.TEST_PASS
  }
};
  

Test Reporting and CI/CD Integration

• Accessibility Reports: Generate detailed reports (HTML or JSON) showing violations and their locations.
• CI/CD Integration: Run accessibility tests automatically on code push using pipelines (GitHub Actions, Jenkins, etc.).
• Fail Builds on Violations: Configure pipelines to fail if critical accessibility issues are found.
• Notifications: Send reports or alerts to developers and testers for quick fixes.

// Example GitHub Actions snippet
name: Accessibility Tests
on: [push]
jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - name: Setup Node.js
        uses: actions/setup-node@v3
        with:
          node-version: '18'
      - run: npm install
      - run: npm run accessibility-test
      - name: Upload Accessibility Report
        uses: actions/upload-artifact@v3
        with:
          name: accessibility-report
          path: reports/accessibility-reports/
  

Best Practices

1. Use Automated Tools with Manual Checks: Combine tools like axe-core with manual keyboard and screen reader testing.
2. Test Early and Often: Run accessibility tests during development, not just before release.
3. Keep Tests Maintainable: Organize tests by page or component and reuse helpers for common checks.
4. Customize Rules: Adjust accessibility rules to fit your project’s needs but avoid disabling critical checks.
5. Integrate with CI/CD: Automate tests and reporting to catch issues quickly and keep the team informed.

Self Check

Where would you add a new accessibility test for the "Profile" page in this framework structure?

Key Result

Organize accessibility tests in dedicated folders with config, utilities, and automated reporting integrated into CI/CD.