I was recently told by an instructional designer on campus that tables are not "accessible" in Canvas, meaning that screenreaders cannot parse and read them.
My understanding from reading Canvas documents (see below) is that a properly formatted/coded is accessible, although this is more implied than explicitly stated. I also am familiar with other recommendations, for example, that we should avoid using tables for design, that tables should be simple and not nested, and that large and complex tables should be broken down into simpler ones.
I would like to be able to respond to this person definitively, with whatever caveats the community is finding in practice.
There is no reason why a table in Canvas would not be accessible, assuming it was created properly. All of the elements are available to make it accessible so I'm not sure why you would be told that.
Thanks for responding to my query and providing the confirmation that I wanted! I'll have to find out what the person's reservations are; they might be related to a specific browser or the fact that few people know how to set up the tables properly.
I am constantly pushing training out on how to properly format tables. It's right up there with using headings properly.
I agree with Mark; this is a continual conversation. I think the key here is understanding what a "properly formatted table" actually means. The information provided in the Canvas General Accessibility Design Guidelines for tables is important information (excerpt included below). I've found that many faculty have reservations about using tables because headings for columns and rows must be formatted in HTML. If you have the skills to edit the HTML, it shouldn't be a problem. However, as mentioned, using tables for layout should be avoided as all tables should have headers for easy navigation using keyboard controls and screenreading assistive technology; however, when using tables for layout headers are often omitted or may not make sense. I would recommend using DIVs for layout (which also requires HTML knowledge and editing).
Excerpt from Canvas General Accessibility Design Guidelines about tables:
Tables should be used for data display, not layout. Headings should always be included for columns and rows.
In Canvas, headings for table columns and rows can only be changed in the HTML editor.
Thanks, Anna, for your references--I do have the Canvas accessibility guide bookmarked and refer to it. I think as @Mark Worden said, it's a training issue. However, with all the other concerns facing faculty, I don't see many of them trying to use the table menu in Canvas (I don't know what many of the options mean--on my list to research) let alone the HTML editor.
This may be a misapprehension or miscommunication of an issue with Canvas when it was first implemented at Bellevue. At that time the table editor in the RCE did not allow you to create accessible tables. You had to edit the HTML. When I was at Bellevue and doing faculty training, I know I told people that, in general, if they needed a table, they should make it somewhere else (either an online table creator, Dreamweaver, something that produced clean table code) and paste in the code. The RCE underwent a pretty big overhaul 12-18 months ago, and the table editor now works like it should, and accessible tables are possible for non-coders (though you do have to know what the settings mean).
The other difficulty with tables, generally, is that they require people to shift their thinking about the way that they arrange the data within the table, which turns out to be a fairly significant shift in schema for most people. It's not just training them about the tags and labels. People want to make tables that look something like the screenshot, below, because that's what they put in their printed documents. But because the data is read left-to-right, top-to-bottom, this table is non-functional in its basic construction, even if it's tagged correctly. Because it duplicates the columns, left to right, it's going to be a frustrating maze for someone relying on machine reading. People still conceive documents (understandably and without even realizing it) based on the constrained 8.5"x11" page, and make space economizing choices based on that scope. It's a hard row to hoe, to convince someone that all that horizontal white space is irrelevant when making a table.
And trying to explain to someone when a simple table might actually be okay for layout and when it might not--it's really something that you have to learn with experience and testing. It's sort of like teaching someone when it's okay to compose a sentence fragment or start a sentence with a conjunction and when it isn't.
Hi Tom . . . Thanks so much for taking the time to provide this background! I forwarded your posting to my team, with links to General Accessibility Design Guidelines and Accessibility within Canvas. Your example was especially illuminating because I ran into this very table construction in a syllabus I was editing last week. I hope in the future that Canvas will make accessible tables easier to create for the non-HTML users.
An accessible table is a simple data table with a caption and headers (row, column, or both) specified. The Canvas guidelines do not mention needing a caption. Also while you can make an accessible table in Canvas, it's a frustrating authoring experience (better than it used to be, but not as good as Dreamweaver or some other tool), so it is a good idea to create the table somewhere else and paste the code into Canvas.
Thank you for your follow-up, especially on adding the caption; although I usually add one, I was unaware that this was also an accessibility requirement. I will try using the HTML editor I have for the tables and see if I can create a properly-coded template that I can reuse. (I use Microsoft Expression Web4, which is available as a free download.)
Although somewhat redundant, I also "sign post" the tables in narrative before they appear. For example, stating "the table below..." or "the following table shows..."