Presentation role conflict
Moderate effortFound on 6% of audited stores.
Remove conflicting ARIA attributes (global ARIA properties and tabindex) from any element that has been marked as purely presentational with role="presentation" or role="none".
What it is
When an HTML element is given `role="presentation"` or `role="none"`, it signals to screen readers: "ignore this element — it carries no meaning, it's only here for visual layout." However, if that same element also carries global ARIA attributes (like `aria-label`, `aria-describedby`, `aria-hidden`, etc.) or a `tabindex`, a direct conflict is created. The browser and screen reader receive two contradictory instructions at once: "treat this as meaningless" and "here's meaningful information about it." Different screen readers resolve this conflict differently — some honour the role and ignore the ARIA, others do the opposite — leading to unpredictable and broken experiences for assistive-technology users.
Why it matters
Screen reader users — including many shoppers who are blind or have low vision — may hear garbled, repeated, or missing announcements when navigating your store if this conflict exists on interactive or decorative elements. This directly harms conversions by making it harder to browse products, read descriptions, or complete checkout. Under WCAG 2.1 Success Criteria 4.1.2 (Name, Role, Value), this is a recognized failure that can create legal exposure under accessibility laws such as the ADA (US), EN 301 549 (EU), and the Equality Act (UK). Resolving it also improves your overall accessibility audit score, which is increasingly scrutinized in enterprise purchasing decisions and legal compliance reviews.
How to fix it
- Audit your HTML for any element that has role="presentation" or role="none" — these are typically decorative images, spacer elements, layout tables, or wrapper divs.
- For each such element, check whether it also has any global ARIA attribute (aria-label, aria-labelledby, aria-describedby, aria-hidden, aria-live, aria-atomic, aria-owns, aria-controls, aria-expanded, aria-haspopup, aria-relevant, etc.) or a tabindex attribute.
- Decide on the correct intent: if the element is truly decorative and should be ignored by screen readers, keep role="presentation" (or role="none") and remove all conflicting ARIA attributes and tabindex.
- If the element does convey meaning or needs to be focusable/describable, remove role="presentation"/role="none" and instead assign the correct semantic role (e.g. role="img" with aria-label for a meaningful image, or use a native semantic HTML element like <button>, <nav>, <img alt="...">).
- For decorative images specifically, the simplest and most compatible fix is to use a native <img> tag with an empty alt attribute (alt="") and no role attribute at all — this is universally understood by all screen readers.
- Re-test with an automated checker (axe DevTools, WAVE, or Lighthouse) and manually verify with a screen reader (NVDA + Firefox, VoiceOver + Safari) to confirm the conflict is resolved.
Fix it on your platform
Pick your platform for the exact steps.
How to fix presentation role conflict on Shopify
- In your Shopify admin, go to Online Store → Themes → Actions → Edit code.
- Search across all Liquid/HTML files for occurrences of role="presentation" or role="none" using the search bar at the top of the code editor (search for 'role="presentation"' and 'role="none"').
- Open each flagged file (commonly layout/theme.liquid, sections/.liquid, snippets/.liquid) and inspect the element for conflicting ARIA attributes or tabindex.
- Remove the conflicting attribute(s) following the decision logic in the generic steps above.
- Save the file and preview your storefront. Use Chrome's axe DevTools extension to re-scan and confirm the issue is resolved.
- If your theme is from the Theme Store and you cannot safely edit it, consider reaching out to the theme developer or installing an accessibility-focused app (e.g. UserWay or accessiBe) as a temporary measure — but note these cannot fully substitute for clean code.
How to fix presentation role conflict on WooCommerce
- In your WordPress admin, go to Appearance → Theme File Editor (or use a child theme and edit files via FTP/SFTP).
- Search your active theme's template files (header.php, footer.php, page.php, single.php, woocommerce/ templates) for role="presentation" or role="none".
- For each match, check the element for conflicting ARIA attributes or tabindex and remove them as described in the generic steps.
- If the conflict originates inside a plugin's output, install the 'Code Snippets' plugin and use a PHP filter (e.g. ob_start / ob_get_clean on the relevant hook) to post-process the HTML, or contact the plugin developer.
- Save your changes, clear any caching plugin (e.g. WP Rocket, W3 Total Cache) under Plugins → Settings → Clear Cache, then re-scan with axe DevTools in Chrome.
How to fix presentation role conflict on BigCommerce
- In your BigCommerce admin, go to Storefront → My Themes → click Customize on your active theme → Advanced → Edit Theme Files.
- Search for role="presentation" or role="none" across your Handlebars (.html) and JavaScript files using the editor's search.
- Open each flagged template (e.g. templates/layout/base.html, templates/components/*.html) and remove conflicting ARIA attributes or tabindex from the offending element.
- Save changes and use the Preview function to test. Run axe DevTools in Chrome against the preview URL to confirm the fix.
- Publish the theme update from the theme editor when satisfied.
How to fix presentation role conflict on Wix
- Open the Wix Editor for your site. Identify the specific element flagged (use Chrome DevTools or axe to pinpoint it visually).
- Click the element in the editor, open its Settings or Accessibility panel (the icon that looks like a person), and look for any custom ARIA label or role that has been set.
- Remove any manually entered ARIA attributes that conflict with a presentational role.
- For elements with role="presentation" set by Wix itself (e.g. decorative images), use the Image Settings panel and ensure the image is marked as 'Decorative' rather than given an alt text or label — Wix will then handle the role correctly.
- If conflicting attributes were injected via Wix Velo (JavaScript), open the Velo Editor (Dev Mode) and search your page code for setAttribute calls setting role, aria-*, or tabindex, then resolve the conflict there.
- Publish your site and re-scan with axe DevTools.
How to fix presentation role conflict on Squarespace
- In Squarespace, direct HTML editing is limited. Start by identifying which element triggers the issue using Chrome DevTools → Elements panel.
- If the element is a built-in Squarespace block (e.g. a decorative image or spacer block), check whether a custom Code Block or CSS injection is adding ARIA attributes — go to Pages → (your page) and look for any Code Blocks, or check Design → Custom CSS.
- Remove or correct any custom ARIA attributes in the offending Code Block or Custom CSS/JS injection under Settings → Advanced → Code Injection (header/footer).
- If the issue is in Squarespace's own theme output and you cannot edit it directly, document the element and submit a support request to Squarespace, or use the Code Injection area to inject a small corrective JavaScript snippet that removes the conflicting attribute after DOM load (see code snippet below).
- Republish and re-scan with axe DevTools.
How to fix presentation role conflict on Webflow
- Open the Webflow Designer and select the element flagged by the accessibility checker (use the Navigator panel to find it by tag/class).
- With the element selected, open the Element Settings panel (the gear icon, 'D' shortcut) and scroll to the Custom Attributes section.
- Review any custom attributes set: if role="presentation" or role="none" is present alongside an aria-* attribute or tabindex, remove the conflicting attribute(s).
- If the element is a decorative image, open the Image Settings and check the 'Decorative image' checkbox — Webflow will automatically add alt="" and remove conflicting roles/labels.
- Publish your site and run axe DevTools in Chrome to verify the fix.
How to fix presentation role conflict on Adobe Commerce (Magento)
- Identify the offending template file using Chrome DevTools → Elements panel. Note the surrounding HTML and any nearby Magento block or template hint comments (enable template hints via Stores → Configuration → Advanced → Developer → Debug → Enabled Template Path Hints).
- Locate the corresponding .phtml template file in your custom theme directory: app/design/frontend/<Vendor>/<Theme>/.
- Edit the file to remove the conflicting ARIA attribute or tabindex from the element that carries role="presentation" or role="none".
- If the element is in a core or third-party module template, copy it to your theme directory first (following Magento's theme override pattern) rather than editing core files directly.
- Run bin/magento cache:clean && bin/magento cache:flush from the CLI, then reload your storefront and re-scan with axe DevTools.
How to fix presentation role conflict on Headless / Custom (I build in code)
- Search your codebase (JSX, TSX, HTML templates) for role="presentation" and role="none" — e.g. grep -r 'role="presentation"' src/.
- For each match, inspect the element for any aria-* props/attributes or tabindex. Remove the conflicting attribute following the decision logic in the generic steps.
- For decorative images in React/Next.js/Nuxt, prefer <img alt="" /> or the framework's Image component with alt="" rather than role="none" + aria-label conflicts.
- Run automated tests (jest-axe, Playwright with axe-core) in CI to catch future regressions.
- Manually test with VoiceOver (Mac/iOS) and NVDA (Windows) to confirm screen readers skip the element silently.
Does your site have this issue?
Run a free SEOLZ scan to find presentation role conflict — and every other issue — across your whole site in minutes.
Scan my site freeFrequently asked questions
What is Presentation role conflict?
When an HTML element is given `role="presentation"` or `role="none"`, it signals to screen readers: "ignore this element — it carries no meaning, it's only here for visual layout." However, if that same element also carries global ARIA attributes (like `aria-label`, `aria-describedby`, `aria-hidden`, etc.) or a `tabindex`, a direct conflict is created. The browser and screen reader receive two contradictory instructions at once: "treat this as meaningless" and "here's meaningful information about it." Different screen readers resolve this conflict differently — some honour the role and ignore the ARIA, others do the opposite — leading to unpredictable and broken experiences for assistive-technology users.
Why does presentation role conflict matter?
Screen reader users — including many shoppers who are blind or have low vision — may hear garbled, repeated, or missing announcements when navigating your store if this conflict exists on interactive or decorative elements. This directly harms conversions by making it harder to browse products, read descriptions, or complete checkout. Under WCAG 2.1 Success Criteria 4.1.2 (Name, Role, Value), this is a recognized failure that can create legal exposure under accessibility laws such as the ADA (US), EN 301 549 (EU), and the Equality Act (UK). Resolving it also improves your overall accessibility audit score, which is increasingly scrutinized in enterprise purchasing decisions and legal compliance reviews.
How do I fix presentation role conflict?
Remove conflicting ARIA attributes (global ARIA properties and tabindex) from any element that has been marked as purely presentational with role="presentation" or role="none".
Authoritative references
- How to fix this specific rule — Deque/axe (rule reference)
- WCAG 2 overview — W3C WAI
- ARIA basics — MDN