Accessibility Test Scenario: Checkout Page

Test Details

• Test Name: Accessibility Compliance for Checkout Page
• Objective: Ensure the checkout page complies with WCAG 2.1 AA guidelines, providing an inclusive experience for users with disabilities.

Here is the app that we are going to test:

Preconditions

1. Access the checkout page on a browser with keyboard navigation, screen reader (e.g., NVDA, JAWS), and accessibility tools (e.g., Lighthouse or axe).
2. Ensure the browser supports ARIA and semantic HTML elements. To check this you have to go to browser settings and find the accessibility settings there.
3. Set the viewport to standard desktop (1366px) and mobile (375px) dimensions.

Test Steps and Observations

1. Page Structure Validation
   • Step: Verify the page structure using a screen reader.
   • Expected: The screen reader announces the page title “Checkout Page” and reads the headings, labels, and inputs in a logical, hierarchical order.
   • Observed:
     • Headings are appropriately structured (e.g., <h1> for the page title).
     • Labels are associated with their inputs using for attributes.
2. Keyboard Navigation
   • Step: Navigate the page using the Tab key.
   • Expected:
     • Focus moves sequentially through all actionable elements (e.g., input fields, dropdown, buttons).
     • Focus indicators are clearly visible.
   • Observed:
     • All interactive elements are tabbable, and focus indicators are prominent.
3. Form Field Accessibility
   • Step: Verify each input field’s label and aria-required attributes.
   • Expected:
     • Labels are read correctly.
     • Errors are announced when fields are invalid or empty.
   • Observed:
     • Error messages use aria-live="polite" to ensure screen readers announce them dynamically.
     • Required fields are marked with aria-required="true".
4. Dynamic Content Updates
   • Step: Select “Credit Card” from the “Payment Method” dropdown.
   • Expected:
     • The credit card field becomes visible and is focusable.
     • Screen reader announces its presence and availability.
   • Observed:
     • The credit card field visibility toggles dynamically, and its accessibility attributes adjust accordingly.
5. Color Contrast
   • Step: Use a color contrast tool to check the contrast ratio of text and backgrounds.
   • Expected:
     • Text contrast meets WCAG 2.1 AA requirements (4.5:1 for normal text, 3:1 for large text).
   • Observed:
     • Text color (#333) on a white background passes contrast checks.
     • Buttons have sufficient contrast against their backgrounds.
6. Validation Feedback
   • Step: Submit the form with missing or invalid inputs.
   • Expected:
     • Error messages are displayed below each invalid field.
     • Screen readers announce the errors in real time.
   • Observed:
     • Validation feedback is dynamically updated and announced via aria-live.
7. Mobile Responsiveness
   • Step: Resize the viewport to 375px (mobile).
   • Expected:
     • Form fields and buttons adjust to fit the screen without horizontal scrolling.
   • Observed:
     • The layout remains accessible and visually consistent.
8. Semantic HTML
   • Step: Inspect the HTML structure.
   • Expected:
     • Semantic elements like <form>, <label>, and <button> are used appropriately.
   • Observed:
     • All elements are semantic and correctly structured.
9. Error Prevention
   • Step: Submit the form after selecting “Credit Card” but leaving the card number field blank.
   • Expected:
     • A clear error message appears.
     • Form submission is prevented.
   • Observed:
     • Error message “Card number is required” is displayed, and submission is blocked.

Test Results

Recommendations

1. Add visual hints (e.g., asterisk *) to required fields for additional clarity.
2. Include skip links for quick navigation to the main content.
3. Test with additional assistive technologies (e.g., VoiceOver on macOS/iOS).