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.

Practice

1. What is the main goal of accessibility testing on a website?

easy

A. To improve the website's loading speed

B. To add more images and videos

C. To ensure the website is usable by people with disabilities

D. To increase the number of advertisements

Solution

1. Step 1: Understand the purpose of accessibility testing

   Accessibility testing focuses on making websites usable for everyone, including people with disabilities.

2. Step 2: Compare options to the goal

   Only To ensure the website is usable by people with disabilities matches this goal, while others focus on unrelated aspects like speed or content.

3. Final Answer:

   To ensure the website is usable by people with disabilities -> Option C

4. Quick Check:

   Accessibility testing = usability for all [OK]

Hint: Focus on users with disabilities for accessibility testing [OK]

Common Mistakes:

• Confusing accessibility with performance optimization
• Thinking accessibility means adding more content
• Ignoring users with disabilities

2. Which HTML attribute is important for accessibility to describe images?

easy

A. alt

B. title

C. src

D. href

Solution

1. Step 1: Identify attribute for image description

   The alt attribute provides text descriptions for images, helping screen readers.

2. Step 2: Check other attributes

   title shows tooltips, src is image source, href is for links, none describe images for accessibility.

3. Final Answer:

   alt -> Option A

4. Quick Check:

   Image description attribute = alt [OK]

Hint: Use alt for image descriptions to help screen readers [OK]

Common Mistakes:

• Using title instead of alt for image description
• Confusing src with description
• Missing alt attribute entirely

3. Consider this HTML snippet:

<button>Click me</button>

Which accessibility improvement is best?

medium

A. Remove the button element

B. Add aria-label="Submit button" to the button

C. Change button text to "" (empty string)

D. Add style="color: white;" only

Solution

1. Step 1: Understand button accessibility

   Buttons need clear labels for screen readers; adding aria-label clarifies purpose.

2. Step 2: Evaluate other options

   Empty text or removing button removes meaning; styling alone doesn't improve accessibility.

3. Final Answer:

   Add aria-label="Submit button" to the button -> Option B

4. Quick Check:

   Use aria-label for clear button description [OK]

Hint: Use aria-label to describe buttons clearly [OK]

Common Mistakes:

• Leaving buttons unlabeled
• Removing interactive elements
• Relying only on visual styles

4. You test a form and find keyboard users cannot reach the submit button. What is the likely cause?

medium

A. The button has tabindex="-1"

B. The button has a visible label

C. The button uses type="submit"

D. The button has a high contrast color

Solution

1. Step 1: Understand tabindex effect on keyboard navigation

   A tabindex="-1" removes the element from keyboard focus order, so users can't tab to it.

2. Step 2: Check other options

   Visible label, submit type, and color contrast do not block keyboard focus.

3. Final Answer:

   The button has tabindex="-1" -> Option A

4. Quick Check:

   tabindex="-1" blocks keyboard focus [OK]

Hint: Check tabindex for keyboard focus issues [OK]

Common Mistakes:

• Confusing label visibility with focusability
• Ignoring tabindex attribute effects
• Assuming color affects keyboard navigation

5. You want to test if a website's color choices meet accessibility standards for contrast. Which approach is best?

hard

A. Use random colors to test visually

B. Only rely on automated tools without manual checks

C. Ignore color contrast if text is large

D. Use an automated color contrast checker and manually verify with users

Solution

1. Step 1: Understand color contrast testing methods

   Automated tools quickly check contrast ratios, but manual testing ensures real user experience.

2. Step 2: Evaluate other options

   Relying only on tools misses context; ignoring contrast or random colors do not ensure accessibility.

3. Final Answer:

   Use an automated color contrast checker and manually verify with users -> Option D

4. Quick Check:

   Combine automated and manual checks for best results [OK]

Hint: Combine tools and manual checks for color contrast [OK]

Common Mistakes:

• Trusting only automated tools
• Ignoring contrast for large text
• Testing colors without standards