WebAIM - Web Accessibility In Mind

E-mail List Archives

Thread: Tables with clickable rows

for

Number of posts in this thread: 5 (In chronological order)

From: Renato Iwashima
Date: Wed, May 05 2021 2:52PM
Subject: Tables with clickable rows
No previous message | Next message →

Hi,

What's the best/recommended way to create data tables where each row is
entirely focusable and clickable?

Looking at stackoverflow there's plenty of answers that disregard
accessibility. The only one I found that makes sense uses aria roles with
grid, row, and gridcell which doesn't use the <table> tag anymore. Is this
a good approach? This problem comes from the fact that it is invalid to
wrap table rows with an anchor tag.

Any help is appreciated.

Renato

From: glen walker
Date: Wed, May 05 2021 3:46PM
Subject: Re: Tables with clickable rows
← Previous message | Next message →

I would not use the grid role unless your table behaves like a spreadsheet
with editable cells. It doesn't sound like that's your behavior.

What happens when you select a row in the table?

You could have the first column be a checkbox for selection and that would
be the only keyboard focusable element for the row. You can get fancy with
CSS and cause the entire row to be highlighted when you tab to the checkbox.

You could still use an anchor tag but you have to play tricks to make it
appear like it spans multiple columns. But an anchor isn't the right
semantic element unles clicking on the row navigates you to another page.


On Wed, May 5, 2021 at 2:52 PM Renato Iwashima < = EMAIL ADDRESS REMOVED = > wrote:

> Hi,
>
> What's the best/recommended way to create data tables where each row is
> entirely focusable and clickable?
>
> Looking at stackoverflow there's plenty of answers that disregard
> accessibility. The only one I found that makes sense uses aria roles with
> grid, row, and gridcell which doesn't use the <table> tag anymore. Is this
> a good approach? This problem comes from the fact that it is invalid to
> wrap table rows with an anchor tag.
>
> Any help is appreciated.
>
> Renato
> > > > >

From: Renato Iwashima
Date: Wed, May 05 2021 4:05PM
Subject: Re: Tables with clickable rows
← Previous message | Next message →

Yes, in my case clicking on a row would take to another page. It's a master
list/detail flow. I'm assuming the tricks you mentioned is to expand the
anchor on top of the entire row with css?

On Wed, May 5, 2021 at 4:47 PM glen walker < = EMAIL ADDRESS REMOVED = > wrote:

> I would not use the grid role unless your table behaves like a spreadsheet
> with editable cells. It doesn't sound like that's your behavior.
>
> What happens when you select a row in the table?
>
> You could have the first column be a checkbox for selection and that would
> be the only keyboard focusable element for the row. You can get fancy with
> CSS and cause the entire row to be highlighted when you tab to the
> checkbox.
>
> You could still use an anchor tag but you have to play tricks to make it
> appear like it spans multiple columns. But an anchor isn't the right
> semantic element unles clicking on the row navigates you to another page.
>
>
> On Wed, May 5, 2021 at 2:52 PM Renato Iwashima < = EMAIL ADDRESS REMOVED = >
> wrote:
>
> > Hi,
> >
> > What's the best/recommended way to create data tables where each row is
> > entirely focusable and clickable?
> >
> > Looking at stackoverflow there's plenty of answers that disregard
> > accessibility. The only one I found that makes sense uses aria roles with
> > grid, row, and gridcell which doesn't use the <table> tag anymore. Is
> this
> > a good approach? This problem comes from the fact that it is invalid to
> > wrap table rows with an anchor tag.
> >
> > Any help is appreciated.
> >
> > Renato
> > > > > > > > > >
> > > > >

From: Mark Magennis
Date: Thu, May 06 2021 8:46AM
Subject: Re: [EXTERNAL] Tables with clickable rows
← Previous message | Next message →

Renato,

You have to be very careful when using the grid role because basically you no longer have a table that behaves in the expected way for a <table> with a screen reader. Also, it may disable the screen reader's general page navigation and other functionality. Using JAWS or NVDA, if you arrow into a grid in browse mode everything works as normal for a table. But when you Tab into the grid (using the default screen reader settings) the screen reader enters application mode and the standard table navigation using Ctrl+Alt+Arrow keys no longer work. Plus, standard screen reader commands like 'h' to jump to the next heading or Ctrl+Home to jump to the top of the page no longer work. The same happens if you arrow into the table (which doesn't trigger application mode) but then use a widget within it that does trigger application mode, such as a dropdown menu (role="menu"). When you close the menu, you are back in the grid but still in application mode so normal screen reader functionality is supressed. To get back your standard table navigation and other screen reader functionality, you have to manually exit application mode. A lot of screen reader users don't know how to do this, and don't even know what application mode is. So in practice, if you use a grid instead of a table, you will probably need to provide instructions for screen reader user explaining this and telling them how to recover their normal functionality. This isn't ideal, so you should avoid using grids for data tables unless you need functionality that a <table> can't support.

Mark

From: Mallory
Date: Thu, May 06 2021 3:01PM
Subject: Re: [EXTERNAL] Tables with clickable rows
← Previous message | No next message

Do you want something like Selectable Rows?
https://stommepoes.nl/work/tables/elements_table.html
(scroll to that heading)
or rows with links?
https://stommepoes.nl/work/tables/table.html

These are both super-old and were made as things to work with at an old job, but maybe they give you ideas.

For both of these kinds of tables, I try to keep regular table-table-ness as much as possible and just use JS to make mouset/touch a little more like what you're describing. I keep in mind that there is always an actionable element inside a th/td: a link or a checkbox or a button or something.

just a thought
_mallory

On Thu, May 6, 2021, at 4:46 PM, Mark Magennis wrote:
> Renato,
>
> You have to be very careful when using the grid role because basically
> you no longer have a table that behaves in the expected way for a
> <table> with a screen reader. Also, it may disable the screen reader's
> general page navigation and other functionality. Using JAWS or NVDA, if
> you arrow into a grid in browse mode everything works as normal for a
> table. But when you Tab into the grid (using the default screen reader
> settings) the screen reader enters application mode and the standard
> table navigation using Ctrl+Alt+Arrow keys no longer work. Plus,
> standard screen reader commands like 'h' to jump to the next heading or
> Ctrl+Home to jump to the top of the page no longer work. The same
> happens if you arrow into the table (which doesn't trigger application
> mode) but then use a widget within it that does trigger application
> mode, such as a dropdown menu (role="menu"). When you close the menu,
> you are back in the grid but still in application mode so normal screen
> reader functionality is supressed. To get back your standard table
> navigation and other screen reader functionality, you have to manually
> exit application mode. A lot of screen reader users don't know how to
> do this, and don't even know what application mode is. So in practice,
> if you use a grid instead of a table, you will probably need to provide
> instructions for screen reader user explaining this and telling them
> how to recover their normal functionality. This isn't ideal, so you
> should avoid using grids for data tables unless you need functionality
> that a <table> can't support.
>
> Mark
>
>