How do you test complex interactive components such as date pickers, carousels, and data tables for accessibility?

The ARIA Authoring Practices Guide (APG) at aria.w3.org/apg is the specification for accessible widget design. It defines, for each widget type, the expected keyboard interactions and the required ARIA roles/states/properties. Use it as your test specification.

Date picker (based on the APG dialog-modal pattern):

• Opening the picker moves focus to the calendar dialog.
• Arrow keys navigate between dates in the grid; Page Up/Down change month; Ctrl+Page Up/Down change year.
• Enter/Space select a date; Escape closes without selection and returns focus to the trigger.
• The dialog has role="dialog" with an accessible name, dates are role="gridcell", the selected date has aria-selected="true".

Carousel/slider (tabpanel or generic pattern):

• Auto-play must stop when a user hovers or focuses any element in the carousel. This is a WCAG 2.2.2 requirement.
• Previous/next buttons must have descriptive labels, not just ">" and "<".
• The current slide position must be communicated — e.g. "Slide 3 of 5" as the button label or a live region update.

Data table:

• Use semantic <table> markup with <th scope="col" and/or <th scope="row" for cell association.
• Interactive tables (sortable columns, selectable rows): sort state on column header (aria-sort="ascending"), row selection state (aria-selected="true").
• Large tables with column/row header associations must use id/headers attributes if the simple scope approach doesn't cover the layout.

Testing approach: for each component, work through the APG keyboard interaction matrix row by row. Use a screen reader to verify announcements at each state change.