Tips for creating accessible tables using proper headers, layout, and structure for screen reader users. Presented by Laurie Berry, Laine Amoureux, and Sukha with A11y Idaho.<\/p>\n\n\n\n
Webinar Runtime: 56:09<\/p>\n\n\n\n
Tables should be used only<\/strong> to convey data relationships<\/strong> (headers, cells, and the connections between them).<\/p>\n\n\n\n Using tables for visual layout<\/strong> (e.g., to position text or images in a Word document) is the most common and severe accessibility failure. <\/p>\n\n\n\n Tables must have programmatically defined headers<\/strong> to establish the relationship between the header cell and the data cell.<\/p>\n\n\n\n Data formatted using tabs<\/strong> or columns<\/strong> (which are visually organized but not structurally tagged) is not accessible because the screen reader cannot associate the information with its proper header.<\/p>\n\n\n\n The training introduced table accessibility through the lens of WCAG Success Criteria<\/strong>, mainly focusing on 1.3.1 Info and Relationships<\/strong> (ensuring data relationships are conveyed) and 1.3.2 Meaningful Sequence<\/strong> (ensuring the content is read in the logical order).<\/p>\n\n\n\n The biggest failure is using a table for layout<\/strong> (e.g., to position text and images in Microsoft Word). This is often done because Word is difficult to use as a “publication design tool.” This practice causes a screen reader to read the content out of order (e.g., “Basement UP! Toilets must flush” from a non-data example), failing the Meaningful Sequence<\/strong> criteria.<\/p>\n\n\n\n Accessible tables must be built to convey data relationships.<\/p>\n\n\n\n The panel emphasized a crucial principle: “Technically passing is not the same as making something usable.”<\/strong> Authors should prioritize a clean, simple structure that ensures the user can easily associate data with its correct headers, even if that means overriding the Word checker’s default preferences.<\/p>\n\n\n\n Laurie Berry:<\/strong> All right, and hello everybody and welcome to the May A11y Idaho Guided Training topic on tables<\/strong><\/sup>. Hope you’re all doing well<\/sup>. This is our monthly guided training, and, just as usual, these will be recorded and then uploaded to the A11y Idaho website in time<\/sup>. I am Laurie Berry<\/strong> and I’m an instructional designer with one of our grant projects under the Center for Disabilities and Human Development<\/sup>. So nice to see all of you, and I’ll allow Laine and Sukha to introduce themselves as well<\/sup>.<\/p>\n\n\n\n Laine Amoreaux:<\/strong> Go ahead, Laine<\/sup>. Yeah, I was totally multitasking, so I’m so glad Laurie said my name<\/sup>. I’m Laine Amoreaux<\/strong>. I am a certified professional web accessibility based in Boise, and I wear several hats<\/sup>. Right now, working full-time for Booz Allen Hamilton <\/sup>… But I am a native screen reader user<\/strong> and have been blind since birth<\/sup>.<\/p>\n\n\n\n Sukha Worob:<\/strong> I’m Sukha<\/strong><\/sup>. I am the coordinator for the Idaho Training Clearinghouse and a senior instructional designer here<\/sup>. Learning about accessible content, tables are a constant source of frustration for me<\/strong><\/sup>. They’re so great when they’re used right, and they’re so rarely used right<\/sup>.<\/p>\n\n\n\n Laurie Berry:<\/strong> Yeah, and definitely, and we also have some resources at the end for dealing with tables that we can share also<\/sup>. So on that, gonna go dive right in. Laine, passing it to you for the WCAG Success Criteria<\/strong><\/sup>.<\/p>\n\n\n\n Laine Amoreaux:<\/strong> Awesome, so for anybody who hasn’t joined us before, and kind of overwhelmed still by WCAG<\/strong>\u2014Web Content Accessibility Guidelines\u2014just keep in mind that these are guidelines<\/strong><\/sup>. The success criteria are testable statements, the things that you can do<\/sup>. The guidelines are broken into four categories: Perceivable, Operable, Understandable, and Robust<\/strong><\/sup>.<\/p>\n\n\n\n I typically apply the trusted testing methodology, so it cross references only three WCAG success criteria<\/sup>.<\/p>\n\n\n\n We’re gonna spend most of our time as it relates to Info and Relationships<\/strong> versus layout tables<\/sup>.<\/p>\n\n\n\n Laurie Berry:<\/strong> And laying up on the screen is an example of the table for layout, with your favorite example<\/sup>.<\/p>\n\n\n\n Laine Amoreaux:<\/strong> I love this thing. I found this “Basement Toilets Must Flush UP!”<\/strong> table on WebAIM<\/sup>. Somebody used a table to insert the image of the toilet and put the words in<\/sup>. If I were navigating that like it was data, it reads differently<\/sup>.<\/p>\n\n\n\n Laurie Berry:<\/strong> It reads “Basement UP! Basement UP! Toilets must flush.”<\/strong><\/sup>.<\/p>\n\n\n\n Sukha Worob:<\/strong> This represents one of the biggest issues for people using Word<\/strong> to design: Word often gets used like people want it to be a publication design tool<\/strong>, and it is not<\/strong><\/sup>. People use tables all the time because it is difficult in Word to orient things in a free floating canvas kind of a manner<\/sup>. Quite often what happens is exactly like this toilet table where people use a table to fake publication design elements<\/strong> in a document<\/sup>.<\/p>\n\n\n\n Laine Amoreaux:<\/strong> And it’s a great example of how that meaningful sequence<\/strong> can get screwed up in layout tables<\/strong> too<\/sup>. That sequence has no meaning when you read it in that order<\/sup>. So this would be failing 1.3.2 Meaningful Sequence<\/strong><\/sup>.<\/p>\n\n\n\n Laurie Berry:<\/strong> I have an example, kind of going back to the success criteria, on indicating the relationships<\/strong><\/sup>. The item on the left is a before example using text boxes<\/strong> to indicate individual items in PowerPoint, which sort of looked like a table<\/sup>. Stepping back from that, it made sense to put some headers<\/strong> onto that table<\/sup>. So adding a header allows a user to identify the relationships<\/strong> that these individual text components might have<\/sup>.<\/p>\n\n\n\n Sukha Worob:<\/strong> Anyone want to take a crack at what the potential pitfall is on this table? There is a potential problem with 1.3.1 Info and Relationships<\/strong> related to the way that Word defaults their tables<\/strong><\/sup>.<\/p>\n\n\n\n Laurie Berry:<\/strong> Is that in relation to the column header and the row header<\/strong> Sukha? <\/sup><\/p>\n\n\n\n Sukha Worob:<\/strong> Yeah, exactly<\/sup>. This is true in Word, this is true in PowerPoint<\/sup>. When you go to insert a table in Microsoft Word, by default, the check boxes for Header Row<\/strong> and First Column<\/strong> are checked<\/sup>.<\/p>\n\n\n\n The issue that shows up is that if you uncheck header row and only check first column<\/strong>, Microsoft Word will always throw an error<\/strong> related to that table when you do a review on it<\/sup>. It will say that the table is missing headers<\/sup>. When you output that to PDF, you can double check what’s called your scope<\/strong><\/sup>. The scope on our first column would be row<\/strong> because those are row headers<\/sup>.<\/p>\n\n\n\n [Attendee]:<\/strong> Can I ask a question on that? <\/sup> This actually happened to me. I took off the header row and if I put the header row back on, then it would say good to go again<\/sup>. What I’m hearing you say is that it was okay that I did the table like that with the header row unchecked and even if Word didn’t like it, it was actually an accessible table<\/strong>? <\/sup><\/p>\n\n\n\n Laine Amoreaux:<\/strong> So the best that you can do to make a table accessible in Word is check the header box<\/strong>, and that’s the only way the accessibility checker will pass it<\/sup><\/sup><\/sup><\/sup>. If it’s going to be in a PDF<\/strong>, then you have to do the work in a PDF<\/sup>.<\/p>\n\n\n\n Sukha Worob:<\/strong> And Word is highly limiting<\/strong> in terms of its ability to build anything other than a really standard table<\/strong><\/sup>. If you merge cells<\/strong>, it’s gonna give you an error<\/sup>. If you don’t have your header row, it’s gonna give you an error<\/sup>. All of those things can be contended with when you’re in PDF<\/strong><\/sup>.<\/p>\n\n\n\n When I export to PDF and use the Table Editor, I can see that the cell is in fact tagged as a header cell, and the scope is set to row<\/strong><\/sup>. This means that when I navigate this table, it is going to announce my header in addition to the content in the data cell<\/sup>.<\/p>\n\n\n\n My baseline advice is make your tables simple<\/strong><\/sup>. We do a lot, especially in education, of really unnecessarily complex tables<\/sup>. That’s things like stacked headers<\/strong> when really you could just have two tables, that’s things like merged cells<\/strong> when really you could just redefine your header cell each time<\/sup>. That’s things like abbreviations<\/strong> <\/sup>\u2014not everyone is gonna know exactly what that abbreviation means<\/sup>.<\/p>\n\n\n\n Laurie Berry:<\/strong> Sukha, any concerns, you’ve got a bulleted list inside a table.<\/strong> <\/sup><\/p>\n\n\n\n Sukha Worob:<\/strong> My question when I see bulleted lists is, is this really a data relationship<\/strong> then? <\/sup>Or should each one of those bullet points be its own cell<\/strong>? <\/sup>It does create a lot of extra verbiage in there<\/sup>.<\/p>\n\n\n\n Laine Amoreaux:<\/strong> It comes back to keep it simple<\/strong><\/sup>. Do you really need three data points in a single data cell? <\/sup>It’s the same thing with complex tables where you have multiple row or multiple column headers<\/sup>. There’s other ways to show those relationships without making it so complex<\/sup>.<\/p>\n\n\n\n Laurie Berry:<\/strong> Technically passing is not the same as making something usable<\/strong><\/sup>.<\/p>\n\n\n\n Sukha Worob:<\/strong> There are times when compliance means poor user experience<\/strong>, and there are times when a good user experience means that it’s gonna fail compliance<\/sup>.<\/p>\n\n\n\n Laine Amoreaux:<\/strong> And coming back to that table in Word example, you can make it pass in Word<\/sup>. But that doesn’t mean that it’s going to be usable in the end, and if your ultimate destination is a PDF<\/strong>… that work gets done over thereLayout is Forbidden<\/h4>\n\n\n\n
Simplicity is Usability<\/h3>\n\n\n\n
Keep it Simple<\/h4>\n\n\n\n
\n
Usability Over Compliance<\/h4>\n\n\n\n
\n
Structural Essentials<\/h3>\n\n\n\n
Headers are Mandatory<\/h4>\n\n\n\n
Live Text is Required<\/h4>\n\n\n\n
\n\n\n\nSummary and Annotated Outline<\/h2>\n\n\n\n
1. Layout Tables (The Misuse)<\/h3>\n\n\n\n
2. Data Tables (The Solution)<\/h3>\n\n\n\n
\n
3. Usability vs. Compliance<\/h3>\n\n\n\n
Want to jump to a specific section of the video? Here’s the Annotated Outline<\/summary>\n
\n
\n\n\n\nFull Text Transcript<\/h2>\n\n\n\n
Expand to access the full text transcript<\/summary>\n
\n