Templates to Use Accessibility Audit Checklist: A template to guide the audit of the SayPro website, ensuring that all key accessibility criteria are tested and documented from SayPro Monthly January SCMR-17 SayPro Monthly Inclusive Design: Ensure the site is accessible to users with disabilities by SayPro Online Marketplace Office under SayPro Marketing Royalty SCMR
An Accessibility Audit Checklist serves as a valuable tool to guide the audit process, ensuring that SayPro’s website complies with WCAG 2.1 standards and is accessible to all users, including those with disabilities. The checklist should be thorough, covering all key accessibility criteria that need to be tested and documented.
The following template outlines the key sections of an accessibility audit checklist for SayPro’s website under the SayPro Monthly January SCMR-17 initiative for Inclusive Design.
SayPro Accessibility Audit Checklist Template
1. Visual Accessibility Criteria
A. Text Contrast
- Test Criteria: Ensure that text has sufficient contrast against the background to improve readability for users with low vision or color blindness.
- WCAG Requirement: Text should have a contrast ratio of at least 4.5:1 for normal text and 3:1 for large text.
- Test Method: Use a contrast checking tool (e.g., WCAG Contrast Checker) to verify contrast ratios across headings, body text, links, buttons, and other textual elements.
- Status: [ ] Passed [ ] Failed [ ] Needs Fixing
- Notes: List any elements that do not meet the contrast requirements and need adjustment.
B. Font Size and Readability
- Test Criteria: Ensure that text is resizable and legible without loss of content or functionality.
- WCAG Requirement: Content should remain readable when zoomed up to 200% without horizontal scrolling.
- Test Method: Zoom in on the website (up to 200%) and verify that text remains legible and content is not cut off.
- Status: [ ] Passed [ ] Failed [ ] Needs Fixing
- Notes: Include any issues where text becomes illegible or misaligned when zoomed.
2. Keyboard Navigation and Focus
A. Keyboard Accessibility
- Test Criteria: Ensure that the site is fully navigable using a keyboard (no reliance on mouse).
- WCAG Requirement: All interactive elements should be accessible via keyboard (tabbing through content, pressing Enter/Space for buttons, etc.).
- Test Method: Test navigation using the Tab key, Arrow keys, and Enter key. Ensure every interactive element (links, forms, buttons) is reachable and usable.
- Status: [ ] Passed [ ] Failed [ ] Needs Fixing
- Notes: List any elements that are not keyboard-navigable (e.g., forms, buttons).
B. Focus Indicators
- Test Criteria: Ensure focus indicators (e.g., borders or highlights) are visible when navigating with the keyboard.
- WCAG Requirement: Focus should be clearly visible as users navigate through interactive elements.
- Test Method: Use Tab to navigate through the page. Ensure that every focusable element (links, form fields, buttons) has a clear, visible indicator (e.g., outline or background color).
- Status: [ ] Passed [ ] Failed [ ] Needs Fixing
- Notes: Identify any focusable elements without clear indicators and document the fixes needed.
3. Image and Media Accessibility
A. Alternative Text for Images
- Test Criteria: Ensure that all images, including decorative images, have appropriate alt text.
- WCAG Requirement: Alt text must be provided for all non-decorative images, and decorative images should be marked as empty alt (
alt=""
). - Test Method: Review each image to ensure an accurate, descriptive alternative text is provided for non-decorative images.
- Status: [ ] Passed [ ] Failed [ ] Needs Fixing
- Notes: Include any images missing alt text or using vague descriptions (e.g., “image1”).
B. Video and Audio Content
- Test Criteria: Ensure all multimedia (videos, audio files) have captions, transcripts, or descriptions as needed.
- WCAG Requirement: Videos and multimedia should have synchronized captions or transcripts for accessibility.
- Test Method: Check videos for captions, verify that transcripts are available for audio content, and ensure descriptions are provided for complex media.
- Status: [ ] Passed [ ] Failed [ ] Needs Fixing
- Notes: Document any videos/audio that lack captions or descriptive content.
4. Forms and Input Fields
A. Form Field Labeling
- Test Criteria: Ensure that all form fields (input boxes, checkboxes, dropdowns, etc.) have proper labels and accessible names.
- WCAG Requirement: Every form field should be clearly labeled with a descriptive text (via the
label
element) or an accessible name. - Test Method: Inspect form fields to ensure that each one is properly labeled using visible text or ARIA attributes for accessibility.
- Status: [ ] Passed [ ] Failed [ ] Needs Fixing
- Notes: Include any fields that do not have visible labels or accessible names.
B. Error Handling and Instructions
- Test Criteria: Ensure that form errors are communicated clearly, with instructions to correct them.
- WCAG Requirement: Errors must be programmatically associated with the form fields, and users should be notified of validation issues.
- Test Method: Submit a form with invalid input and verify that error messages are clearly associated with the respective fields and accessible to screen readers.
- Status: [ ] Passed [ ] Failed [ ] Needs Fixing
- Notes: List any issues related to form validation messages or unclear error notifications.
5. ARIA (Accessible Rich Internet Applications)
A. ARIA Roles and Landmarks
- Test Criteria: Ensure that ARIA roles and landmarks are used correctly to define regions of the page (e.g., header, navigation, main content).
- WCAG Requirement: Correct ARIA roles and landmarks should be used to provide structure for users with screen readers.
- Test Method: Review the code and use screen reader tools to verify that ARIA roles and landmarks are properly implemented and accessible.
- Status: [ ] Passed [ ] Failed [ ] Needs Fixing
- Notes: Document any missing or incorrect ARIA roles.
B. ARIA Live Regions
- Test Criteria: Ensure ARIA live regions are used appropriately to notify users of dynamic content changes (e.g., updating a cart or submitting a form).
- WCAG Requirement: Live regions should be implemented to alert screen reader users to real-time updates.
- Test Method: Test dynamic content and ensure that updates are announced by the screen reader (e.g., when a form is submitted or content changes without page refresh).
- Status: [ ] Passed [ ] Failed [ ] Needs Fixing
- Notes: Include any dynamic content that does not trigger updates to screen readers.
6. Mobile and Touch Accessibility
A. Touch Target Size
- Test Criteria: Ensure that touch targets (buttons, links, etc.) are appropriately sized for users with motor impairments.
- WCAG Requirement: Touch targets should be at least 44×44 pixels.
- Test Method: Measure the size of touch targets (e.g., buttons, icons) on mobile devices.
- Status: [ ] Passed [ ] Failed [ ] Needs Fixing
- Notes: Identify any small touch targets that need resizing.
B. Mobile Screen Reader Testing
- Test Criteria: Ensure that the site is usable with screen readers on mobile devices.
- WCAG Requirement: The website should be fully operable and readable on mobile devices, with no degradation of accessibility features.
- Test Method: Test with a screen reader app on a mobile device to verify that content and navigation are accessible.
- Status: [ ] Passed [ ] Failed [ ] Needs Fixing
- Notes: Highlight any issues with screen reader functionality on mobile devices.
7. Final Evaluation and Recommendations
- Overall Status: [ ] Passed [ ] Failed [ ] Needs Fixing
- Summary of Findings: Provide a summary of the key accessibility issues identified during the audit, focusing on high-priority items.
- Recommendations: Include actionable steps to address the issues, along with timelines for resolution.
Conclusion
By using this Accessibility Audit Checklist, SayPro can ensure that all key accessibility criteria are tested and documented thoroughly. This process will help ensure compliance with WCAG 2.1 standards, improve the user experience for people with disabilities, and foster an inclusive digital environment. The checklist should be updated periodically to reflect any changes in the platform or updates to accessibility standards.