Skip to content
Gravity Tables

Accessibility

The data is for everyone. So the table has to work for everyone.

Gravity Tables targets WCAG 2.1 Level AA on every shortcode output. This page documents what that means in practice, six pillars, the standards we test against, the known gaps, and how to report an issue.

Report an issue See the pillars

WCAG 2.1

Level AA target

Plugin output

6/6

Six pillars covered

See below

axe + NVDA

Tested with

Plus VoiceOver, JAWS

14d

A11y bug response SLA

Patch window

The six pillars

Keyboard, screen reader, focus, contrast, motion, forms.

01

Keyboard navigation

Every interaction works without a mouse.

  • Tab / Shift-Tab cycles through editable cells in row order; Enter saves and moves down the column; Escape cancels an in-flight edit. Documented in the keyboard-nav release post.
  • Bulk selection: row checkboxes are reachable via Tab, toggleable with Space. Bulk-action toolbar items follow standard button keyboard semantics.
  • Filter chips and pagination: standard button + dropdown patterns, all reachable and operable from the keyboard.
  • No keyboard traps: at any point, Escape returns focus to the previous editable surface or yields focus to the host page.

02

Screen-reader semantics

Tested with NVDA, VoiceOver, and JAWS. Tables announce as data tables, not generic content.

  • Real <code class="rounded bg-ink-100 px-1 py-0.5 font-mono text-[0.85em] text-ink-900 dark:bg-ink-800 dark:text-ink-100">&lt;table&gt;</code> markup with <thead> / <tbody> / <tfoot>, screen readers announce column headers, row counts, and footer totals correctly.
  • <code class="rounded bg-ink-100 px-1 py-0.5 font-mono text-[0.85em] text-ink-900 dark:bg-ink-800 dark:text-ink-100">aria-labelledby</code> on every cell linking to its column header so the column context is announced when navigating cell-by-cell.
  • <code class="rounded bg-ink-100 px-1 py-0.5 font-mono text-[0.85em] text-ink-900 dark:bg-ink-800 dark:text-ink-100">aria-live=&quot;polite&quot;</code> on the toast region so undo/redo / save confirmations / error messages are announced without stealing focus.
  • Filter chip state announced via aria-pressed toggling; clear-x announced as a button with the column name.
  • Skip-link from the page hero to the first table interaction, so screen-reader users can bypass the toolbar if they prefer.

03

Visible focus states

Every interactive element shows a visible focus ring. No 0-outline reset wipes them out.

  • Two-color focus ring (light + dark mode) using the design-system focus token. Contrast ratio ≥ 3:1 against the host theme background.
  • Focus ring on cells during keyboard editing, separate styling from cell-hover so the keyboard user always knows which cell will receive their next keystroke.
  • Skip-to-content links on the host site templates we ship; on hosts that have their own, our table's focus management is additive, not conflicting.

04

Color and contrast

WCAG AA contrast (4.5:1 for body text, 3:1 for UI controls and large text) on the default theme. Configurable from the customizer.

  • Default palette tested with axe and WAVE on light and dark modes, clean.
  • Status colors (active green, trial amber, cancelled red) ship with text + icon + label, never color-alone, so color-blind users always have a non-color signal.
  • Theme customizer ships with a contrast warning if a user picks a color combo below AA, see the theme customizer tool.
  • Dark mode independently audited; status pills swap to dark-friendly variants automatically.

05

Reduced motion

Honors `prefers-reduced-motion: reduce` at the OS level.

  • Animations (auto-refresh fade, cell-edit transitions, toast slide-ins) become instant when the user has reduced-motion enabled.
  • No essential information conveyed via animation alone, every state change has a text + icon equivalent that screen readers and reduced-motion users can perceive.
  • Auto-refresh is opt-in per table (auto_refresh="true"); when reduced-motion is set, the polling still runs but the page-update transition is instant.

06

Forms inside tables

Inline editing inherits Gravity Forms' own accessibility work, plus a few additions.

  • Inline editors use the same <input> / <select> / <textarea> element as the source field, no custom widgets that re-implement accessibility from scratch.
  • Validation errors are announced via aria-describedby on the field, with aria-invalid="true" on failure. Same UX as a fresh form submission.
  • Required field indicators carry into inline editing, both the visual asterisk and the screen-reader-announced "required" attribute.
  • Date fields open a keyboard-navigable calendar picker, escapable with Escape, with arrow-key day navigation and Enter selection.

Scope

What this statement covers.

Accessibility claims only mean something when scoped honestly. Here's what we own and what we don't.

In scope
The HTML output of the [gravity_table], [gravity_chart], and [gravity_map] shortcodes, plus the admin builder UI shipped with the plugin.
Out of scope
Your host theme, your other plugins, your custom JavaScript. The plugin's output is accessible; how a host site composes that output is outside our control.
Standards target
WCAG 2.1 Level AA across plugin-generated content. Section 508 (US federal) compliance follows from WCAG 2.1 AA conformance.
Testing methodology
Automated: axe-core in CI for every release. Manual: NVDA + Firefox, VoiceOver + Safari, JAWS + Edge before each minor release. Real-world: the plugin runs on accessibility-mandated sites in production.

Known limitations

What's not perfect yet, named.

Most accessibility statements list certifications and stop. Honest ones name the gaps. Three things we know aren't fully resolved, and the workaround for each.

Map view (`[gravity_map]`)

Leaflet itself has good a11y for map navigation, but the underlying map is fundamentally visual data. We render an accessible list view alongside the map (toggle in the toolbar) so non-sighted users get the same data in tabular form.

Donut chart (`[gravity_chart type="donut"]`)

Donut charts are visually compelling but inherently spatial. We attach <title> + <desc> elements to the SVG with the underlying data as a labeled list. Bar charts are preferable for screen-reader users; consider type="bar" as the default if your audience includes them.

Frontend "Add Entry" modal

The modal traps focus correctly and returns focus to the trigger on close, but a multi-step form inside it inherits Gravity Forms' multi-step pattern, which is mostly accessible but has known issues with focus management on step transitions. A patch upstream is in progress; track it in the roadmap.

Reporting

Found a barrier? Tell us.

We treat accessibility issues as bugs, not feature requests. Reports get the same triage queue as security reports.

info@fahdmurtaza.com
What to include
URL where you saw the issue, browser + assistive tech (e.g. NVDA + Firefox), and a description of what was hard or impossible. Reproduction steps if you have them.
Acknowledgement
Within 24 hours.
Patch window
Critical (blocks usage with assistive tech): ≤ 14 days. Major (significant friction): ≤ 30 days. Minor: next minor release.
VPAT / formal documentation
A current VPAT (Voluntary Product Accessibility Template) is available on request for procurement evaluations. Email the address above with "VPAT request" in the subject.

Ready when you are

Stop exporting CSVs. Start shipping dashboards.

10 days of full Pro access. If it doesn't pay for itself in the first week, you don't have to keep it.

Start free trial Talk to Fahd