0
0
Testing Fundamentalstesting~8 mins

Accessibility testing in Testing Fundamentals - Framework Patterns

Choose your learning style9 modes available
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.