Tables in Canvas Pages

[RobertGibson]

Odd thing...

We have some Canvas generated tables on a page. We save them. We look at them as a student. We put the cursor in the first cell block. We then try to tab from cell to cell to test keyboard accessible functionality. But rather than tabbing cell to cell, it jumps us to the Next Page button (skipping the entire table). We've tried this repeatedly. It's not an image. It's a table.

We're confused. The only way to 'read' the table is using Immersive Reader.

What is going on?

[jenn_stevens · Accepted solution]

Except @RobertGibson says that this is a data table, NOT a layout table - so this advice would be the opposite of accessibility in this case. His particular question is about keyboard navigation, but for anyone else who happens by, following the advice to use <divs> for a data table would make it inaccessible to anyone who uses a screen reader. 

I would strongly recommend using semantic html for data tables, like Canvas uses. To quote WHATWG, "Authors are strongly encouraged to view the div element as an element of last resort, for when no other element is suitable. Use of more appropriate elements instead of the div element leads to better accessibility for readers and easier maintainability for authors."

[Chris_Hofer]

@RobertGibson ...

I don't really have a solution for you at this time, but I do have a question.  What is the purpose for your table on the page?  Is it for design/layout of the page?  If so, tables should really only be used to hold data...at least, that's what I've seen others here in the Community say.  If you are using tables for design/layout, are there other ways you can design your page that would eliminate the need for tables?  If you have the DesignPLUS product from Cidi Labs, you could use their Columns feature to help in the design of your page.

I think we need more information from you on the purpose of your table so that we can help you further.  Thanks!

[RobertGibson]

Chris, it's for holding data

[LauraF1]

For read-only tables displayed as content, data tables as data tables don't need keyboard accessibility in the individual cells. Keyboard-reliant users can generally see the data in the table and visually read it. There's nothing in the individual table data cells containing data that requires interactivity, and thus don't require keyboard focusability. This is typical and expected table behavior. 

The exception is if the application puts action buttons or elements into table data cells. Those action elements in the table must be keyboard focusable.

Screen readers provide a way to navigate and read the table data that isn't reliant on keyboard focusability using screen-reader specific keyboard commands. These users can navigate up and down rows and columns with the screen reader to explore the table. Again, this doesn't use keyboard focusability.

[RobertGibson]

This was actually new to me as I thought all tables required keyboard focus. From ChatGPT:

Yes, tables generally require tab key focus to be accessible, especially when it comes to interactive elements within tables like links, buttons, or form inputs. Here's how this works in terms of web accessibility:

1. Non-Interactive Content: For tables that are used purely for displaying data (non-interactive), it is not necessary for the table cells themselves to be focusable via the tab key. Instead, ensuring that the table is properly marked up with <table>, <th>, and <td> tags, along with appropriate use of scope attributes, is crucial for screen readers to interpret the table correctly.

2. Interactive Elements: If a table includes interactive elements such as links, buttons, form controls, or any other widget that requires user interaction, these elements should be focusable with the tab key. This ensures that all users, including those using keyboards and assistive technologies, can access and interact with these elements.

3. Navigation Aids: For complex tables, especially those used in applications with a lot of data and interactive features (like sorting or filtering), providing additional keyboard navigation aids (such as shortcuts to jump between rows and columns) can enhance usability and accessibility.

Properly coding and structuring tables with clear headers and readable content ensures accessibility for all users, including those with disabilities.

[LauraF1]

Hi- ChatGPT essentially says the same thing I said, that noninteractive data presented in a table does not need to be keyboard focusable.

There are instances if you are trying to replicate a spreadsheet-type experience in an online application that you might have the web application support keyboard navigation through the various data cells.

Screen reader software has built-in commands to navigate and read table data. 

[RobertGibson]

Laura, thank you. For argument sake, let's say the cells contain interactive elements, such as links. Will Canvas automatically make those cells keyboard focusable using the Tab key?

[LauraF1]

You would need to insert the links using the rich text editor commands like you would any other link in content. If you just type in the web address as content, its not going to automatically convert it to a clickable element like you sometimes have with Word, Google Docs, or gmail. 

Laura

Attached image shows the insert link menu item from the rich text editor toolbar.

[asaylor]

I just ran a test in one of my courses and realized this is also an issue I am having. With all the accessibility changes coming this year, this concerns me!

Thank you, Robert, for this post!!!

[jaiyoung]

Replace Tables with <div>s in Canvas for the solution and improved ADA Compliance

Reformatting layout tables into <div>-based structures helps improve accessibility, especially for screen reader users. Below are key practices that support ADA and WCAG compliance:

1. Use Semantic Class Names
   Replace <table>, <tr>, and <td> with <div> elements using clear class names like .row, .column, or .cell. This avoids misuse of tables and supports clearer content structure.
2. Leverage CSS Grid or Flexbox
   Use display: grid or flex for layout instead of table-based design. These methods provide better control over responsiveness and maintain a logical reading order.
3. Maintain Logical DOM Order
   Structure your div layout top-to-bottom and left-to-right. Screen readers follow code order, not visual order, so keeping this flow ensures content makes sense.
4. Use ARIA Roles or Landmarks When Needed
   Enhance navigation by using HTML5 elements like <section> or adding role="region" to identify meaningful areas of the page.
5. Ensure Good Contrast and Focus Styles
   Maintain accessible color contrast and visible keyboard focus indicators when styling your layout. This benefits users with visual impairments or who navigate via keyboard.
6. Use Relative Units for Sizing
   Avoid fixed px widths and heights. Use %, em, or rem units to support zooming and flexible screen sizes.
7. Include Proper Heading Structure
   Use correct heading levels (<h2>, <h3>, etc.) within div layouts to provide clear structure and improve screen reader navigation.

[jenn_stevens · Accepted solution]

Except @RobertGibson says that this is a data table, NOT a layout table - so this advice would be the opposite of accessibility in this case. His particular question is about keyboard navigation, but for anyone else who happens by, following the advice to use <divs> for a data table would make it inaccessible to anyone who uses a screen reader. 

I would strongly recommend using semantic html for data tables, like Canvas uses. To quote WHATWG, "Authors are strongly encouraged to view the div element as an element of last resort, for when no other element is suitable. Use of more appropriate elements instead of the div element leads to better accessibility for readers and easier maintainability for authors."

[LauraF1 · Accepted solution]

To support what  Jenn posted; the semantic elements are the <table>, <th>, and <td> elements. CSS class names are not used for accessibility.

Laura