Accessible expand/collapse table row

Viewed 1654

I wanted to ask a question about creating accessible expand/collapse tables. I am trying to create a table with expandable rows that is accessible via screen reader. Here is essentially what we are trying to accomplish:

Example table with expand and collapse functionality

We were able to create table that does this using JQuery, but there are several accessibility issues in the design. These include:

1. How can I show the relationship between the initial row (includes 3 cells) and the expanded row to the screen reader?

Would it work to make the first column a header with a unique id and reference this in the expanded row? Or is this confusing because technically the expanded row is associated to the entire initial row (not just the first cell)?

2. How does the screen reader know what has been expanded?

Are there any aria attributes that could help accomplish this?

and now for the big question...

3. Is this design inherently inaccessible?

When the screen reader access the button (on the left) to perform the expand/collapse; it hasn't yet read any of the cells (to the right) related to new expanded row (e.g. item 1, item 2, item 3). This means that a screen reader user is forced to request more information before they have a chance to read the initial row. Is there any way to fix this so that screen readers have the opportunity to read the entire row before they expand for more information? Is the only solution to have the expand/collapse button at the end of the table?

1 Answers

1. How can I show the relationship between the initial row (includes 3 cells) and the expanded row to the screen reader?

You'll need to use the header and ID's method to associate a header with the data cell using the colspan.

Keep in mind that a single data cell may be associated with multiple header cells using this method.

2. How does the screen reader know what has been expanded?

There are numerous ways that you could approach this, but I would recommend using an accordion system that's already been vetted for accessibility purposes, like jquery-ui or another system, such as those proposed by the a11y project. Going with a known-good solution (even as a starting point) means that you won't have to re-invent the wheel and spend time solving problems that have already been solved.

You could potentially use these solutions as-is (in a table cell) or reverse engineer them to work with your own system. If going with the latter option, I'd specifically pay attention to aria-controls, aria-labelledby, aria-expanded, aria-hidden and aria-selected.

3. Is this design inherently inaccessible?

You make a very good point about the placement of the expander effectively bypassing the reading order. This is an issue, but it could potentially be overcome by putting the expander in the data cell with the colspan attribute.

If it's really necessary that the expander be placed in the place where you currently have it, then I'd recommend hiding that control from screen reader users by using the aria-hidden attribute and then placing a second control in the data cell with the colspan attribute that can only be percieved by screen reader users (e.g. bootstrap .sr-only class or some other method).

Related