Accessibility

• The main pages use semantic headings, links, buttons, and form controls.
• Workspace controls use native inputs, selects, buttons, and table markup where practical.
• Crosstab tables include a caption naming the row and column variables, scoped row/column headers, sortable header buttons, and aria-sort state for screen readers.
• Reports preserve text-based audit details rather than relying only on color or charts.
• Workspace mode and data-rail tabs support roving arrow keys, visible focus, polite mode announcements, and Escape from the independently scrolling left rail.

• Full WCAG conformance has not been certified.
• Dense crosstab tables may require additional keyboard shortcuts and screen-reader summaries for large datasets.
• Color-coded significance should continue to be paired with text indicators in reports and detail popovers.

• Continuous integration runs axe-core rules tagged WCAG 2.0 and 2.1 Level A/AA against the home, methods, support, status, and accessibility pages in Chromium.
• Those public-page scans must report zero automatically detectable violations before the browser test suite passes.
• Workspace browser journeys cover the empty-state upload control, populated/project states, keyboard mode switching, independent left-rail scroll, 320-pixel reflow, and a 720-pixel 200%-zoom equivalent without page-level horizontal overflow.

Automated rules cover only issues that software can detect. These checks are evidence for the tested pages and states, not a WCAG conformance claim or a substitute for testing with disabled people, keyboard-only navigation, screen readers, zoom, high contrast, and other assistive technologies.

Manual accessibility QA is still required across upload, populated workspace, export, and sharing.