PageFly Accessibility Checklist 2026 | WCAG 2.1 AA & EAA
Last updated: 2026-06-01
PageFly is a drag-and-drop page builder app for Shopify and BigCommerce, used to create custom product, landing, and home pages that override a theme's default templates. That role is what makes its accessibility profile specific: a merchant may have chosen an accessible Shopify theme, but the moment a PageFly page replaces the theme's product template, the accessibility of that page is determined by the elements the merchant dragged in - not by the theme. PageFly's element library is broad (image sliders, countdown timers, tabs, accordions, video, product blocks, custom HTML), and most of those interactive widgets ship with the same predictable gaps. Image sliders and galleries auto-advance with no pause control and expose previous/next arrows that are not keyboard operable. Tabs and accordions built from the visual widgets often lack the ARIA roles, states, and keyboard support that let screen reader users know a panel is collapsed or which tab is selected. Product images and gallery thumbnails are frequently published with empty or filename alt text. The add-to-cart and quantity controls a merchant drops in can be styled divs rather than real buttons, so keyboard users cannot operate them and screen readers do not announce them as controls. Countdown timers driving urgency render visually but expose nothing to assistive technology. And the conversion-focused color presets often place pale text on bright buttons below the 4.5:1 contrast ratio. PageFly does include some accessibility-minded settings, but it ships no built-in checker, so every fix here is verified with external tools (axe, WAVE, Lighthouse) and a manual keyboard and screen reader pass on the live storefront page. This checklist covers the product and landing surfaces a shopper actually moves through.
Common Accessibility Issues
PageFly product and gallery blocks pull in store images, but the alt text is often left empty or set to a filename ('product_03_final.jpg'). On a commerce page the images carry the product information a shopper needs, so a blind or low-vision visitor using a screen reader cannot tell what a product looks like, what variant a swatch represents, or what a lifestyle shot is showing.
Set descriptive alt text on every informative product and gallery image that conveys what a sighted shopper sees ('Navy wool overcoat, front view, with notch lapels'). For variant swatch images, make the alt name the variant. Mark purely decorative images (background graphics, dividers) with empty alt so they are skipped. Check the rendered page, not just the editor, since alt entered in the builder must survive to the live storefront.
<img src="/cdn/product_03_final.jpg" alt=""><img src="/cdn/product_03_final.jpg" alt="Navy wool overcoat, front view, with notch lapels">PageFly slider and carousel elements commonly auto-advance on a timer with no pause control, and their previous/next arrows and dot indicators respond only to clicks or swipes. Moving content that starts automatically, lasts more than five seconds, and runs beside other content fails WCAG 2.2.2, and the click-only controls lock keyboard users out of the gallery.
Provide a visible, keyboard-operable pause/stop control for any auto-advancing slider, or disable auto-advance so the shopper controls it. Make the previous/next and indicator controls real buttons reachable and operable by keyboard, give them accessible names, and honor prefers-reduced-motion so motion-sensitive visitors are not subjected to automatic transitions.
<div class="pf-slider" data-autoplay="true">
<span class="arrow next"></span>
</div><div class="pf-slider" data-autoplay="true">
<button type="button" aria-label="Pause slideshow">Pause</button>
<button type="button" aria-label="Next slide" class="arrow next"></button>
</div>
<!-- honor prefers-reduced-motion to disable autoplay -->Product description tabs and FAQ accordions built with PageFly widgets often render as styled divs and spans with no ARIA roles or state. Screen reader users are not told that a section is a tab or that a panel is collapsed or expanded, and keyboard users may be unable to open a panel or move between tabs, so essential product details and shipping or returns information stay hidden.
Ensure accordion triggers are real buttons with aria-expanded reflecting open/closed state and aria-controls pointing at their panel, and that tab sets use the tab/tabpanel pattern with arrow-key navigation and aria-selected. Confirm every panel can be opened with the keyboard and that its state is announced. Where the widget cannot expose this, replace it with a custom HTML element that follows the disclosure or tabs pattern.
<div class="pf-accordion-title">Shipping & Returns</div>
<div class="pf-accordion-body">...</div><h3>
<button type="button" aria-expanded="false" aria-controls="ship">Shipping & Returns</button>
</h3>
<div id="ship" hidden>...</div>When a merchant styles an add-to-cart or quantity stepper as a div or span with a click handler, keyboard users cannot reach or activate it and screen readers do not announce it as a button, so a shopper using assistive technology cannot complete the core action of the page - putting an item in the cart.
Use real <button> (or <a>) elements for add-to-cart, quantity plus/minus, and variant selection so they are focusable and operable by keyboard and announced with the correct role. Give each control a clear accessible name, ensure the quantity field is a labeled input, and confirm the whole purchase action can be completed with the keyboard alone on the live page.
<div class="pf-add-cart" onclick="addToCart()">Add to cart</div><button type="button" class="pf-add-cart" onclick="addToCart()">Add to cart</button>PageFly countdown-timer elements render urgency as animated digits with no text alternative for screen readers, and the conversion color presets frequently pair a bright sale button with white or pale text below the 4.5:1 ratio. The result is a page that pressures and converts sighted shoppers while excluding low-vision and non-visual ones.
Give countdown timers an accessible name and expose meaningful time remaining as text at sensible intervals (not every second), and announce content changes when a timer expires via a polite live region; if the timer enforces a real limit, see WCAG 2.2.1. Check every button and sale label with a contrast tool and adjust until normal text reaches 4.5:1 and large text 3:1.
.sale-btn { background:#ff5a5a; color:#ffd6d6; } /* ~1.7:1 */.sale-btn { background:#c01c1c; color:#ffffff; } /* ~5.5:1 */PageFly-Specific Tips
- Remember that a PageFly page overrides your theme's template: choosing an accessible Shopify or BigCommerce theme does not make a PageFly product or landing page accessible - the elements you dragged in decide that.
- Set descriptive alt text on every product and gallery image inside the builder, and verify it survived to the live storefront, since commerce images carry the information a shopper needs to buy.
- Use real buttons for add-to-cart, quantity steppers, and slider arrows; styled divs look identical but lock out keyboard and screen reader shoppers from the core purchase action.
- Turn off slider auto-advance or add a keyboard-operable pause control, and rebuild any tab or accordion that lacks aria-expanded/role support using a proper disclosure pattern.
- PageFly ships no accessibility checker, so test each published page with axe or WAVE plus one full keyboard and screen reader pass - especially the add-to-cart flow - before making it live.
Recommended Tools
axe DevTools (browser extension)
Run axe on the live PageFly storefront page to catch product images without alt text, divs used as buttons, and tabs/accordions missing roles that the builder will not flag.
WAVE Browser Extension
WAVE's annotations make it quick to spot which gallery images lack alt text and which interactive widgets lack accessible names on a finished product page.
Lighthouse (Chrome DevTools)
Use Lighthouse for a fast baseline on a PageFly page, flagging contrast, label, and name-role-value problems on the add-to-cart and form controls before you publish.
PageFly Accessibility: Builder Elements vs. Fixes
| Plugin / Tool | Element | Common Failure | WCAG Criterion | Fix Direction |
|---|---|---|---|---|
| Product images gallery and thumbnails | Empty or filename alt text | 1.1.1 Non-text Content | Describe each image; name variant swatches | |
| Image sliders auto-advancing carousel | No pause; click-only arrows | 2.2.2 Pause, Stop, Hide | Pause control + keyboard arrows; reduced-motion | |
| Tabs & accordions description / FAQ widgets | No roles, states, or keyboard support | 4.1.2 Name, Role, Value | Disclosure/tabs pattern with aria-expanded | |
| Add-to-cart styled div controls | Not focusable or announced as a button | 4.1.2 Name, Role, Value | Use real buttons; label quantity input | |
| Sale buttons conversion color presets | Text contrast below 4.5:1 | 1.4.3 Contrast (Minimum) | Adjust colors to meet the ratio |
Frequently Asked Questions
If my Shopify theme is accessible, is my PageFly page accessible too?
Not necessarily. A PageFly page overrides your theme's template for that URL, so its accessibility is determined by the elements you dragged in, not by the theme you chose. An accessible theme governs pages PageFly does not touch; on a PageFly product or landing page you have to check alt text, headings, interactive widgets, and the add-to-cart flow yourself on the live storefront.
Are PageFly tabs, accordions, and sliders accessible by default?
Often not. Many render as styled divs without the ARIA roles, states, and keyboard support screen reader and keyboard users need - accordions that do not expose expanded/collapsed state, tabs without arrow-key navigation, and sliders that auto-advance with click-only arrows. Test each widget with the keyboard alone; if you cannot open a panel, move between tabs, or pause and step through a slider, rebuild it using a proper disclosure, tabs, or carousel pattern.
Why can't a keyboard shopper add my product to the cart?
Usually because the add-to-cart or quantity control was styled as a div or span with a click handler instead of a real button. Those elements are not focusable and are not announced as controls, so keyboard and screen reader shoppers cannot operate the most important action on the page. Use real button or link elements with clear accessible names, label the quantity input, and confirm the entire purchase can be completed with the keyboard.
Further Reading
- Shopify Store Accessibility Guide
- Accessible Ecommerce Checkout Guide
- Product Variant Swatches Screen Reader Accessibility
- Image Carousel Accessibility Lawsuits
- Accessible Accordions Faq Guide
Other CMS Checklists
Get our free accessibility toolkit
We're building a simple accessibility checker for non-developers. Join the waitlist for early access and a free EAA compliance checklist.
No spam. Unsubscribe anytime.