This task covers the creation of a new version of TablePager that implements the Codex Table component for use in the CheckUser-GlobalContributions feature (T337089: [Epic] Implement global contributions feature).
When the subtasks are completed, developers should be able to opt into the Codex Table when working with a sub-class of TablePager, and have access to features such as a table caption and cell alignment configuration, which do not currently exist in TablePager.
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Resolved | AnneT | T366530 [EPIC] Create a Codex version of TablePager for Special:GlobalContributions | |||
| Resolved | AnneT | T366531 TablePager: Create CodexTablePager class | |||
| Resolved | AnneT | T366533 TablePager: Add visually-hidden caption element | |||
| Resolved | AnneT | T366846 TablePager: enable different text alignment options | |||
| Resolved | AnneT | T366847 TablePager: Codex-ify the sort UI | |||
| Resolved | AnneT | T366849 TablePager: Codex-ify the pagination UI | |||
| Resolved | AnneT | T379012 TablePager: Set up a testing environment for Codex version | |||
| Resolved | AnneT | T379018 TablePager: support empty state | |||
| Resolved | egardner | T379019 CodexTablePager: Set up PHP unit tests | |||
| Resolved | AnneT | T380404 [placeholder] Prototype using CodexTablePager in an existing UI |
Could we please make sure this component is accessible for people using screen readers like JAWS, NVDA, ZoomText, and Speechify?
Most screen readers have special table modes and it turns out that several popular third-party table pager components are simply not compatible with these (for example because the necessary parts of the table are simply not present in the DOM where the screen reader can get at them). Retrofitting accessibility into components like this is extremely hard, so making accessibility a hard requirement (a primary design criteria) at the outset is most likely going to be the fastest and most efficient way to get to the desired result.
And to be super-clear: I am saying most other components can get away with dealing with accessibility later in the development process, but for tables and table pagers there are special challenges that makes it necessary to consider accessibility from the start.
Yes, we plan to incorporate accessibility support for this work, as we do for all Codex components. We strive to design and build accessible UIs as an initial acceptance criterion for all of our work, and complete accessibility testing as part of our design review process. Of course, we don't always get everything exactly right during initial implementation, but we will prioritize accessibility bugs as they are reported. We have tested the new Codex Table component with some screen readers but not all of the ones you listed, and I will recommend to the Design System Team that we consider completing some extra testing of the Table component given the concerns you've raised. I've been thinking about the same thing and want to validate that we've built proper support into the Codex Table.
Just to be clear, we also do not plan to build something completely new here, or use a third-party table pager - we plan to create a new display format of the existing TablePager class in MediaWiki core, which will include Codex CSS classes/styles and a few new features that don't yet exist in TablePager. So we will at least get everything that's already built into TablePager/IndexPager for free.