The Accessibility jobs dashboard came about due to personal curiosity about building a web scraper using Python to collect and filter accessibility job listings from a11yjobs.com, then send notifications. I found the site to be a great resource for accessibility roles, but until their recent site updates, I couldn’t get emails about the new posted jobs. As an accessibility consultant, working with a team 6+ hours away can disqualify me from a role before I even apply. Generic job alert emails don’t account for that.
When I built the scraper, I implemented filtered notifications: a daily email with accessibility jobs posted in North America that are remote, and Seattle-area roles that are hybrid or on-site. All the new jobs are scraped and saved into a database; the dashboard fetches the API data and displays it on the page with sorting, filtering and search of the accessibility jobs.
The dashboard needed to be accessible too. Building it that way, component by component, is what led to the next piece: I’m extracting an accessible React component library from the dashboard so others can use the same pieces (A11yTable is the first one, in progress now).
Building A11yTable
The dashboard’s table needed to handle sorting, filtering, and search on job listings, and it needed to be accessible by default, not accessible as an afterthought. Most table libraries treat accessibility as something you bolt on with extra props. I wanted the opposite: an accessible table component that could sit on top of different table engines, so the accessibility layer wasn’t tied to one library’s decisions.
That led to a TableEngine interface with two implementations: one backed by TanStack Table, and one a zero-dependency naive engine I wrote from scratch. Both engines expose the same interface, so A11yTable doesn’t care which one powers it underneath. This also meant I could write a dual-engine equivalence test, running the same test suite against both engines and confirming they produce identical output.
A few decisions I settled on for the API:
- `header` is a plain string, not a `ReactNode`. This keeps the accessible name predictable instead of leaving it to whatever markup a consumer passes in.
- `aria-sort` is only ever applied to the active sorted column, never to all columns with a “none” value. This matches how screen readers announce sort state, rather than technically satisfying the spec while adding noise.
- Sorting is toggle-only. No tri-state (ascending, descending, unsorted) cycling. Fewer states, fewer chances for a screen reader user to lose track of what’s happening.
- Filtering is out of scope for the component itself. That’s a deliberate boundary, not a missing feature.
- An `announce={false}` prop lets a consuming app own its own live-region announcements, for cases where the app already has an announcement pattern and doesn’t want A11yTable fighting with it.
Testing is Vitest and Testing Library for behavior, vitest-axe for automated accessibility checks, plus the dual-engine equivalence test. 22 tests are passed right now. Two gotchas worth naming for anyone doing similar work: Vitest requires `globals: true` in its config for Testing Library’s auto-cleanup to run between tests, and Vitest 4 changed custom matcher type augmentation to a unified `Matchers` interface, which broke a few examples I found while setting this up.
Making the chart accessible
The table wasn’t the only piece that needed work. The dashboard also has a Recharts pie chart showing the top job titles by posting count, and Recharts renders a pie chart as a collection of individual SVG shapes and text nodes, each one a slice, a label, a path. None of that has any inherent meaning to a screen reader. Depending on how it’s exposed, a screen reader user either gets nothing, or gets a stream of disconnected fragments as they navigate into the SVG.
The fix was to wrap the whole chart in a <figure> with a single aria-label that’s built from the actual data: something like “Top 5 job titles by posting count: Accessibility Specialist (12 jobs), Front End Developer (8 jobs), …” generated by mapping over the same data the chart renders from. Adding tabIndex={0} to the figure makes it focusable, so a keyboard or screen reader user can tab to the chart and get one complete, accurate description in a single stop, instead of the SVG internals being announced piecemeal or skipped entirely.
Because the aria-label already carries the full description, there’s no separate visually-hidden text needed alongside it, one label, one source of truth, no risk of the visible chart and the accessible description drifting out of sync as the data changes.
It’s a small pattern, but an easy one to skip, since a chart can look complete visually while giving a screen reader user nothing meaningful to work with.
Where this is headed
Both of these, the table and the chart, came from the same underlying rule: accessibility isn’t something to check for after the component works, it’s part of what “working” means. That’s slower to build. It’s also the only way I know of to end up with something I’d actually want to ship to a client.
A11yTable is the first component coming out of the dashboard; a few more are on the way as I keep extracting pieces from it.