How to fix tabindex on WordPress.org

Remove or replace all positive tabindex values (tabindex="1" or higher) on your page elements, using tabindex="0" for focusable elements and tabindex="-1" only when programmatic focus is needed.

Steps for WordPress.org

  1. Access your theme files via Appearance → Theme File Editor in the WordPress admin, or connect via FTP/SFTP to wp-content/themes/[your-theme]/.
  2. Search all PHP, HTML, and JavaScript files for 'tabindex' — pay special attention to header.php, footer.php, functions.php, and any page-builder output.
  3. Change any tabindex value greater than 0 to '0' or remove the attribute from natively interactive elements.
  4. If the issue is in a page builder (Elementor, Divi, Beaver Builder), open the affected element's advanced settings in the page builder UI — look for an 'Accessibility' or 'Custom Attributes' panel where tabindex may be set, and correct it there.
  5. For plugin-generated markup, check the plugin's settings panel or contact the plugin author.
  6. After saving, purge your cache (if using a caching plugin) and verify by tabbing through the page.
Official WordPress.org documentation ↗

What is tabindex?

The `tabindex` attribute controls the order in which keyboard users move through interactive elements on a page using the Tab key. A value of `tabindex="0"` means an element joins the natural tab order based on where it appears in the HTML. A value of `tabindex="-1"` removes the element from the tab order but still allows it to receive focus via JavaScript. A positive value — like `tabindex="1"`, `tabindex="5"`, or any number above zero — forces a custom tab order that almost always creates a confusing, broken experience for keyboard and screen-reader users. This accessibility rule flags any element with a tabindex value greater than 0.

Positive tabindex values hijack the natural reading and navigation order, causing keyboard-only users and screen-reader users to jump around the page unpredictably — often skipping important links, buttons, or form fields entirely, or hitting them in an illogical sequence. This directly violates WCAG 2.1 Success Criterion 2.4.3 (Focus Order) and can expose your store to legal accessibility complaints or lawsuits, which are increasingly common in e-commerce. Beyond legal risk, a broken keyboard experience means customers who rely on keyboard navigation (including many users with motor disabilities) may be unable to complete checkout, contact forms, or product searches — directly costing you conversions and revenue. Fixing this is also a signal of overall code quality that can indirectly support SEO through improved Core Web Vitals and reduced bounce rates from frustrated users.

See the complete Tabindex guide for every platform and the full background.

Not sure if your WordPress.org store has this?

Run a free SEOLZ scan — we’ll find tabindex and every other issue across your whole site.

Scan my site free

Fix tabindex on another platform