EcomBack Website Accessibility Checklist
Making Accessibility Simple for everyone.
This guide is designed for you and your team—including developers, designers, content writers, data specialists, and any third-party partners working on your website. Each tab of this sheet covers a specific page type (Homepage, Product Page, Collection Page, Blog, Content Pages, Contact Page) and lists accessibility requirements along with role assignments.
By following this guide, you will ensure that every future update—whether code, design, content, or data—maintains web accessibility compliance and provides an inclusive experience for all users.
What is Web Accessibility?
Web accessibility means making websites usable for everyone, including people with disabilities. It ensures that all users, regardless of visual, auditory, motor, or cognitive impairments, can navigate, understand, and interact with your website.
At EcomBack, we implement WCAG (Web Content Accessibility Guidelines) to make your website accessible. These standards help create an inclusive experience, reduce legal risks, and improve overall usability for all visitors.
What is an Accessible Website?
An accessible website follows WCAG guidelines and is built on the POUR principles:
1. Perceivable – Content must be presented in ways users can recognize.
- Designers & Content Writers: Ensure strong color contrast, readable text, alt text for images, and captions for media.
- Data Teams: Structure and label data properly.
2. Operable – All users must be able to navigate and interact with the site.
- Developers: Ensure full keyboard navigation, visible focus indicators, and support for assistive tech.
- Designers: Avoid hover-only interactions and create intuitive interfaces.
3. Understandable – Information and operations must be easy to follow.
- Content Writers: Use simple language, logical heading structures, and clear link text.
- Designers: Maintain consistent layout and behavior across pages.
4. Robust – Content must work with different devices, browsers, and assistive technologies.
- Developers: Use semantic HTML, proper ARIA attributes, and test across platforms.
- Data Teams: Ensure structured data remains compatible and accessible.
By following these principles, your website stays inclusive, legally compliant, and user-friendly, while keeping teamwork aligned and efficient.
Free Accessibility Checker Tools
Use these free tools regularly to monitor and maintain accessibility:
WAVE (Web Accessibility Evaluation Tool)
https://wave.webaim.org/
Browser-based tool for identifying accessibility issues visually.
Google Lighthouse
1. Built into Chrome DevTools (F12 > Lighthouse > Accessibility)
2. Runs accessibility audits and provides actionable reports.
How to Use These Tools:
Developers – Identify and fix code-level accessibility issues.
Designers – Verify color contrast, layout, and visual accessibility.
Content Writers – Check heading structures, alternative text, and content clarity.
Incorporate these tools into your regular review process to proactively address accessibility barriers.
Before You Start: Recommended Accessibility Training
Before diving into the EcomBack Accessibility Checklists, we recommend taking this free online course:
Introduction to Web Accessibility by W3C (via edX)
W3Cx: Introduction to Web Accessibility
This course helps developers, designers, content writers, and other team members understand the foundations of building inclusive digital experiences.
Completing it will help align your team and improve collaboration across departments.
How to Use This Checklist
1. Review Each Tab by Page Type
Each tab focuses on a specific page of your website (Homepage, Product Page, Collection Page, etc.). Review the accessibility elements listed under each page.
2. Check Assigned Responsibilities
Next to every accessibility point, you’ll see which team (Developer, Designer, Content Writer, Data Team) is responsible for handling it. Share tasks accordingly.
3. Track Progress and Maintain Compliance
Use the "Checklist" column to track progress ( Checked / Unchecked ) and make sure accessibility is maintained during every update or new design change.
| Element on Page | Assigned To | Accessibility Requirement | Notes/Details | Checklist |
|---|---|---|---|---|
| Skip Links | Developer | Provide skip to main content link at the top of the page | Should be the first interactive element. | |
| Back to Top Button | Developer | Must be keyboard accessible and labeled for screen readers | Should announce its purpose clearly. | |
| Landmarks | Developer | Use landmarks (header, main, footer, nav) for easy navigation | Proper HTML5 elements or ARIA landmarks. | |
| Logo | Designer / Content | Add meaningful alt text describing the company | E.g., "EcomBack Official Logo." | |
| Main Navigation | Developer | Fully keyboard navigable with logical tab order | Navigation order should match visual order. | |
| Hero Image / Banner / other Images | Designer / Content | Must have appropriate alt text | Alt should convey key message. | |
| Headings (H1, H2, H3) | Developer / Content Writer | Use correct heading hierarchy (no skipping levels) | Logical structure from H1 downward. | |
| Call-to-Action Buttons | Designer / Content | Clear, descriptive button text (not "Click Here") | Must convey action purpose. | |
| Search Bar | Developer | Proper label or aria-label; keyboard accessible | Screen readers must announce it clearly. | |
| Logical Focus Order | Developer | Focus should move logically through content | No jumps or disorienting movement. | |
| Color Contrast | Designer | Maintain 4.5:1 contrast ratio minimum (normal text) | Check using color contrast tools. | |
| Hyperlinks | Developer / Designer | Descriptive link text; distinguishable from surrounding text | Underline or clear visual distinction. | |
| Warning for 3rd Party Links | Developer | Warn users before opening external links (optional best practice) | E.g., "(opens in a new tab)" next to link text. | |
| Homepage Sections | Developer / Designer | Proper headings, focusable product cards | Keyboard and screen reader friendly. | |
| Prices (Regular/Sale Labels) | Developer | Clearly label prices and differentiate regular vs. sale prices | E.g., "Sale Price", "Original Price." | |
| Decorative Images | Designer / Developer | Use blank alt text (alt="") for purely decorative images | Decorative images should not distract screen readers. | |
| Video Content (if present) | Content Writer / Developer | Must have captions, transcripts, and audio descriptions | Make videos fully accessible. | |
| Complex Images (Charts, Diagrams) | Content Writer / Developer | Provide a full text description nearby or on a separate page | Must describe key information. | |
| Footer Links | Developer / Content | Must be navigable, descriptive, and logically organized | Avoid generic link text like "More." | |
| Accessibility Statement Link | Developer / Content | Must be clearly visible in the footer | Easy to find for users seeking support. |
| Element on Page | Assigned To | Accessibility Requirement | Notes/Details | Checklist |
|---|---|---|---|---|
| Product Title | Content Writer | Clear, descriptive, and marked as heading (H1) | Should accurately describe the product. | |
| Product Images | Designer / Content | Meaningful alt text for main images and gallery thumbnails | Avoid generic alt like "image1.jpg"; be descriptive. | |
| Decorative Images | Designer / Developer | Use blank alt (alt="") for purely decorative visuals | PNo distraction for screen readers. | |
| Price (Regular and Sale) | Developer | Clearly label price and sale price separately | Use proper labels like "Sale Price," "Regular Price." | |
| Product Variants (Size, Color) | Developer | Proper labeling for dropdowns, buttons, or swatches | Variants should be screen reader accessible. | |
| Add to Cart Button | Developer | Clear, descriptive text (e.g., "Add to Cart" not "Submit") | Button must be focusable and labeled properly. | |
| Product Description Section | Content Writer | Structured with proper headings and easy-to-read content | Use headings (H2, H3) and bullet points where possible. | |
| Tabbed Content (Description, Reviews, Shipping Info) | Developer | Tabs should be keyboard accessible and ARIA compliant | Use ARIA roles and ensure tabs are operable by keyboard. | |
| Reviews Section | Developer / Content | Clearly structured; use heading for reviews start | Assistive tech should easily navigate to this section. | |
| Star Ratings (if visible) | Developer | Provide accessible labels (e.g., "4 out of 5 stars") | Use aria-labels to announce star ratings. | |
| Quantity Selector | Developer | Fully keyboard operable and properly labeled | Users must increase/decrease quantity via keyboard. | |
| Additional Product Info (if available) | Content Writer / Data | Ensure tables or bulleted lists are accessible | Size charts, specifications should be screen reader friendly. | |
| 3rd Party Apps (Reviews, Wishlist, etc.) | Developer / Data | Verify accessibility compliance | Confirm integrations meet accessibility standards. | |
| Product Video (if any) | Content Writer / Developer | Must include captions, transcripts, and audio descriptions | Ensure full accessibility for multimedia. | |
| Color Contrast | Designer | Ensure text (price, options, descriptions) has proper contrast | Especially on hover or selected variant states. | |
| Error Messages (Add to Cart, Variant Selection) | Developer / Content | Clear, descriptive error feedback | Example: "Please select a size before adding to cart." | |
| Focus Management (when actions happen) | Developer | Maintain logical focus (e.g., after Add to Cart click) | Announce changes or move focus correctly. |
| Element on Page | Assigned To | Accessibility Requirement | Notes/Details | Checklist |
|---|---|---|---|---|
| Product Title | Content Writer | Clear, descriptive, and marked as heading (H1) | Should accurately describe the product. | |
| Collection Title | Content Writer | Must be clear, descriptive, and marked with a heading (H1) | Example: "Men’s Shoes Collection." | |
| Collection Image (if used) | Designer / Content | Add meaningful alt text or use blank alt if decorative | Should describe the theme of the collection if meaningful. | |
| Product Listing (Grid or List) | Developer | Each product card must be fully keyboard and screen reader accessible | Focusable, logical tab order through products. | |
| Product Images (Thumbnails) | Designer / Content | Ensure all product thumbnails have descriptive alt text | E.g., "Black Leather Laptop Bag – Front View." | |
| Product Titles | Content Writer | Should be linked with clear, descriptive text | Avoid vague text like "Hats" | |
| Prices on Product Cards | Developer | Ensure prices are visible, labeled properly (sale/regular) | Include labels like "Sale Price" if applicable. | |
| Filters/Faceted Navigation (Size, Color, Price, etc.) | Developer | Must be keyboard accessible and properly labeled | Use ARIA roles, fieldsets, labels. | |
| Sort By Dropdown | Developer | Fully operable by keyboard, properly labeled for screen readers | Example: "Sort by Price Low to High." | |
| Pagination (if applicable) | Developer | Pagination links/buttons should be keyboard focusable and announced | Include aria-current on the current page link. | |
| Infinite Scroll or Load More Button | Developer | Must be keyboard operable and announce content updates | Provide "Load More" button as accessible alternative to infinite scroll where possible. | |
| Color Contrast | Designer | Ensure text, filters, and button contrast meet 4.5:1 minimum | Important for product cards, filters, and active states. | |
| Hover/Focus States on Products | Developer | Clear visible focus indicator on hover/focus | Not just color change — border or underline preferred. | |
| Error Handling for Filters | Developer / Content | Clear, descriptive messages if no products match filter criteria | Example: "No products found matching your selection." | |
| Accessibility of Quick View Modals (if present) | Developer | Quick view must trap focus, be keyboard operable, and announced correctly | Must return focus to product grid after closing. |
| Element on Page | Assigned To | Accessibility Requirement | Notes/Details | Checklist |
|---|---|---|---|---|
| Page Title (H1) | Content Writer | Clear, descriptive page title using H1 | Example: "About EcomBack" or "Privacy Policy." | |
| Heading Structure (H2, H3) | Content Writer | Proper heading hierarchy throughout content | No skipping heading levels; H2 under H1, H3 under H2. | |
| Body Text Readability | Content Writer | Use plain language, short paragraphs, and bullet points | Improve readability for all users. | |
| Internal Links (if any) | Content Writer | Descriptive link text; avoid vague terms like "Click here" | Links should describe the destination. | |
| External Links (if any) | Developer | Warn users if links open external sites (optional best practice) | Example: "(opens in new tab)" note if external. | |
| Policy Content Clarity (for Terms, Privacy, etc.) | Content Writer | Information must be structured clearly and easy to understand | Break into sections using clear subheadings. | |
| FAQs Section (if present) | Developer | FAQs must use expandable/collapsible sections that are keyboard accessible | Accordion widgets must be accessible with screen readers and keyboard. | |
| Expand/Collapse Buttons (FAQ) | Developer | Buttons must have aria-expanded, aria-controls attributes | Must indicate state change to assistive tech users. | |
| Focus Management (FAQ Expand/Collapse) | Developer | Keyboard focus should stay logical when expanding/collapsing | No loss of focus after interaction. | |
| Color Contrast | Designer | Ensure text, icons, and expandable sections meet contrast standards | Minimum 4.5:1 for regular text. | |
| Alt Text for Illustrations (if used) | Designer / Content | Provide meaningful alt text or mark decorative if applicable | Decorative images must have alt="". | |
| Downloadable Files (if linked) | Data Team | Ensure linked PDFs or files are accessible | Offer accessible HTML alternatives if possible. | |
| Table Content (if present) | Data Team / Content Writer | Tables must have proper headers, captions, and summaries | Clear labeling for screen reader users. | |
| Video or Multimedia (if any) | Content Writer / Developer | Must include captions, transcripts, and audio descriptions | Applies if About or FAQ page has any embedded media. |
| Element on Page | Assigned To | Accessibility Requirement | Notes/Details | Checklist |
|---|---|---|---|---|
| Blog Listing Title (Page Title) | Content Writer | Clear and descriptive, marked with a heading (H1) | Example: "EcomBack Accessibility Blog." | |
| Blog Post Titles (Individual) | Content Writer | Descriptive link text to full articles, properly structured (H2) | Titles should be clickable and meaningful. | |
| Featured Images (Post Thumbnails) | Designer / Content | Add descriptive alt text for featured blog images | Alt text should briefly describe the image content. | |
| Excerpts / Summaries | Content Writer | Provide short, clear summaries of articles | Helps users understand the article without clicking. | |
| Read More Links | Content Writer | Use descriptive text ("Read full article: Accessibility Tips") | Avoid generic "Read More" links without context. | |
| Pagination or Load More Button | Developer | Ensure pagination controls are accessible and keyboard operable | Highlight current page with aria-current attribute. | |
| Search Bar (for Blogs) | Developer | Properly labeled and fully keyboard accessible | Use a visible label or aria-label attribute. | |
| Filter or Categories (if present) | Developer | Keyboard accessible, properly labeled | Ensure dropdowns or links for categories are accessible. | |
| Color Contrast (Text and Links) | Designer | Ensure all text, buttons, and links meet contrast ratios | Minimum 4.5:1 contrast ratio for body text. | |
| Focus Management | Developer | Ensure clear focus indicators when navigating posts or links | Ensure visible focus on post titles, pagination links. | |
| Article Metadata (Date, Author) | Content Writer | Make sure metadata is readable and screen reader accessible | Example: "Posted on April 25, 2025 by EcomBack Team." | |
| Video or Multimedia in Blog | Content Writer / Developer | Provide captions, transcripts, and audio descriptions if used | Ensure videos are fully accessible. | |
| Blog Comment Form Requirements | ||||
| Comment Form (Fields) | Developer | All form fields must have proper visible labels or aria-labels | Labels for Name, Email, Website, Comment fields. | |
| Required Fields (Indication) | Developer / Content | Indicate required fields clearly (visually + programmatically) | Example: Add * and aria-required="true" where necessary. | |
| Error Messages | Developer / Content | Provide clear, descriptive error messages near the relevant field | E.g., "Name is required." Avoid generic errors like "Error occurred." | |
| Success Message After Submission | Developer | Provide clear success confirmation once comment is submitted | Example: "Your comment has been successfully posted." | |
| Focus on Error or Success Message | Developer | Shift focus automatically to error/success message after form action | Helps screen reader and keyboard users notice the response. | |
| Keyboard Navigation for Form | Developer | Entire form should be navigable and submittable by keyboard | Tab order should follow logical flow from field to field. | |
| Form Validation (Client and Server Side) | Developer | Validate input fields without blocking accessibility | Provide real-time error feedback while typing if possible. | |
| Element on Page | Assigned To | Accessibility Requirement | Notes/Details | Checklist |
|---|---|---|---|---|
| Page Title (H1) | Content Writer | Clear and descriptive, using a heading structure | Example: "Contact EcomBack" | |
| Address Information | Content Writer | Ensure physical address is presented in text format | Should not be image-only; real text needed. | |
| Phone Number and Email | Developer | Ensure clickable "tel:" and "mailto:" links are properly labeled | Must be keyboard focusable and screen reader friendly. | |
| Embedded Map (if used) | Developer | Ensure map iframe is keyboard accessible or provide alternative text | Also link to external map if iframe is not accessible. | |
| Form Accessibility Requirements | ||||
| Form Fields (Name, Email, Message, etc.) | Developer | Each field must have visible labels and/or aria-labels | Each field must have visible labels and/or aria-labels | |
| Required Fields | Developer / Content | Clearly mark required fields visually (e.g., *) and programmatically | Use aria-required="true" and visual indicators together. | |
| Placeholder Text | Developer | Do not rely on placeholder text as the only label | Placeholder is supplementary, not a replacement for label. | |
| Field Instructions (if needed) | Content Writer | Provide clear, simple field instructions if special formatting is required | E.g., "Enter a valid phone number including area code." | |
| Error Messages for Fields | Developer / Content | Clear, descriptive inline error messages close to the field | Example: "Please enter a valid email address." | |
| Form Validation (Client and Server Side) | Developer | Validate entries without blocking assistive tech users | Should not rely solely on color to indicate errors. | |
| Focus on Error Messages | Developer | Automatically move focus to first error message after submit fails | Helps screen reader users notice errors immediately. | |
| Success Message After Form Submission | Developer / Content | Provide clear confirmation message once successfully submitted | Example: "Thank you for contacting us. We'll get back to you soon." | |
| Focus on Success Message | Developer | Move focus to success message once form submission is successful | Ensures screen reader users are informed. | |
| Accessible Submit Button | Developer | Ensure submit button is clearly labeled and keyboard operable | Example: Label as "Send Message" instead of generic "Submit." | |
| Keyboard Navigation for Form | Developer | Entire form must be navigable and submittable using only keyboard | Logical tabbing order without skipping fields. | |
| Spam Prevention / CAPTCHA (if any) | Developer | Ensure CAPTCHA is accessible (use accessible alternatives like honeypot fields) | ReCAPTCHA v3 or accessible methods preferred. | |
Please contact us for any questions or concerns. We are here to help you in your website accessibility goals.
