Hello, and welcome back to the accessible PDF video series. This video focuses on PDFs with tables, how to make sure any tables within your PDFs are accessible to people with disabilities. This is a little bit more advanced of a topic, so if you haven't already watched the basic PDF accessibility videos, go and do that first.

I have here a PDF, I created it in Microsoft Word, and then exported it to a PDF. It has a few tables, it has some simple tables, and then it has a complex table. In this context, "Complex" doesn't refer to the size of the table, or the subject matter of the data in the table, it doesn't mean it's about, like, rocket science, it means it has multiple tiers of headers, that is has nested headers, or that it has merged header cells. Simple tables are tables that don't have any of those things.

In this PDF, I have a simple table, some sales figures by salesperson, and year. And then I have a complex table, with U of O enrollment, and this isn't real data, I just made it up by term, by campus, and by either undergraduate or graduate. You'll see that I have multiple tiers of headings in this complex table, and merged cells. Before I go any further, I want to be upfront: Tables in PDFs, especially complex tables, they're kind of a pain. They're tedious to work with, and I strongly discourage you from using them whenever possible. If you can, take simple tables and convert them into lists, that's great. And if you can complex tables and convert them into one or more simple tables, that's also great, so if you just want to go ahead and do that, you can stop watching right now, but if you really want to stick with tables, here we go, let's dive into it.

First, let's look at the simple table. The tool to edit these tables is under the Accessibility option in the sidebar, if you don't have "Accessibility" available here, just search for Accessibility in the search tools box. And then under Accessibility, you want to choose the Reading Order tool. This encases everything in these grey boxes, so select the table you want to work on, anywhere in the table is fine, and then choose the Table Editor option. With simple tables, the main thing we need to do is make sure the correct cells are flagged as headers, and that they have their scope defined. Scope means, are the headers associated with rows or with columns, or both. This is easy to tell visually, but for assistive technologies, we need to be explicit. So, select the cell you want to edit, right click, then choose Properties. Actually, you can multi-select. Either hold down shift, and click each cell, or you can drag your cursor to form a box around the cells you want to edit. So I'm going to select these cells, and year, that's also a header. Oh, there's also a couple visual cues here to give you information. In Acrobat, red cells are headers, and grey cells are data cells. So we can already see that the top cells are headers because they are red. Unfortunately, Word doesn't define the scope of the headers, so we'll need to check out these cells every time. And, by the way, don't worry if these boxes don't line up exactly with the visual boundaries of the table, Acrobat is just a little bit finicky here.

So I have all my header cells selected, right click, table cell properties, and this is where we set the scope. I see this is already flagged as a header cell, now the header cell radio button is selected, but the scope is set to None. So choose that dropdown, these are column headers, so we define the Scope as Column. Click OK, and we're good.

Next, let's do the same thing for the rows. I can visually see that these cells are grey, they are not defined as header cells. So let's multi-select these cells, I'm going to drag my cursor to form a box around them, right-click, properties, right, these are identified as data cells. Change the radio button so they are headers, and then under Scope, that they are Row headers.

If you want, you can see now that they've been changed to red, so we can visually see that these are headers, but if you want to double-check, you can look at the Tags tree to confirm that this is correct.

And actually, I haven't revised the tags in this document, so there are some thing that are wrong, like there are two H1s, but we're not going to worry about that right now. Let's see, where are my tables, here's my table. I see 5 TRs, each TR stands for a table row, and I'm going to open up my first Table Row, I expect these are all going to be table headers. That's correct. And then on all the other rows, I expect that the first cell will be a table header, and the following ones will be table data cells, and that's what I see. TH is my table header, and TD for Table Data, for all the rest of them. These are all going to be the same. OK, those all look good, so I'm going to go ahead and close this out.

And that's actually all we need to do for simple tables. They're pretty easy, which is why you should use simple tables, if you can now. Next, let's look at complex tables, which are, well, complex. The best way to handle complex tables it to separate them into simple tables, that is, tables without merged cells or nested headers. Lots of complex tables don't actually need nested headers, they don't need merged cells, sometimes people add them because they like the aesthetics of it, they think it looks nice, but it doesn't actually convey anything about the data. In my example complex table, I could easily convert this into two simple tables, so I'm making each campus it's own separate, simple table. I could remove the merged Eugene and Portland cells, make them the titles of their own tables, and then now, these are simple tables, I could treat them exactly like I did with the previous example. And, this is more a matter of personal taste, but I think this is easier to understand, just because there is less room for ambiguity. Obviously, you need to do this in Microsoft Word or your source document, not within Acrobat. If you do decide to stick with complex tables, maybe you don't have access to your source, here is what you need to do.

In addition to finding the scope of your header, you'll need to do three things:

First, identify the Span of any merged cells, and I'll go through all of this in more detail. Next is create IDs for any complex headers, and third is to associate every single data cell with certain header IDs.

First, let's talk about span. Span refers to how many columns or rows your header, well, spans. Standard cells span one column and one row, but if your header uses merged cells, it will span multiple rows and/or multiple columns. Here, Eugene and Portland, they both span 2 columns. The Eugene header applies to the undergraduate column and the graduate column, so let's right click on - open up table editor again - let's right click on Eugene. Note that it looks like, visually, like Eugene only spans 1 cell here. Choose properties, and we need to set the scope, this is a column, so set it to a column header, and then we need to define the span. We know that this Eugene cell spans 2 columns, so we are going to say that the column Span is 2. And we're also going to set the ID, that can get a little bit confusing and I don't want to overwhelm you, so we will revisit this in a minute. Click OK, it's going to issue a warning, say "hey, make sure you know what you're doing, this could mess up your table", you're saving often, right? Say yes, now, visually, I can see that this spans 2 columns. Great, so let's do the same thing for Portland. It visually looks like it's correct, but Acrobat likes to lie to us, so let's check it anyway. Header, set the scope to a column, and yeah, it looks like it had a span of 2 columns, but it didn't, so we're going to go ahead and correct that, say this cell spans 2 columns, click OK, there is the same error, great. I can tell next up, my second headers, the undergraduate and graduate labels, they are not currently headers, because they're grey, they're not red, so let's go ahead and fix those. And I'm going to multi-select these. Table cell properties, we're going to say these are headers, their scope are columns, and these are not merged cells, they only span single rows, single column, so these are good. OK, now do the same thing for rows. Each term name is a header cell, but the scope here isn't column, it's rows, so there's no merged cell ugliness in here, so this will be simple, like we don the simple tables. Header, scope, rows, nothing merged. And, that's the span.

The next step is to set IDs for any complex headers. IDs, these are the same idea as HTML ids, if you work with websites. This is just some way of labelling your header cells so you can refer to them in your data cells, it's a reference, a thing to identify your data cells with. All complex headers need IDs, so that's merged cells, and it's nested header cells. Eugene and Portland are merged cells, and the undergraduate and graduate headers are part of nested headers, so all of these need IDs. The row headers are simple, and they are neither merged nor nested, so we don't need to add IDs to these. The reason we need to add IDs is to explicitly tell assistive technology which data cells are associated with each header. We know, for example, that Eugene spans 2 columns, but which 2 columns, exactly, does it span? We can see it visually, but we need to define it programmatically. To do this, you need to, for each complex header, click on it, select properties, and then in the ID field, add an ID. Your ID can be anything, it should just be logical, because we will refer to these IDs later on. So I'll give Eugene an ID of 'e', E for Eugene. Moving on to Portland, this will get an id of 'p'. The nested headers also need IDs, the column for both Eugene and undergraduate should get an ID of, let's see...'eu'. For Eugene and undergraduate. Eugene and graduate will get 'eg'. Portland undergraduate, 'pu', and Portland graduate is 'pg'.

Anything you want, as long as it makes sense. Again, the row header don't need IDs, no ambiguity of which header refers to which cells. The last step, the most tedious step, is to associate data cells with these headers. Here, we're directly saying this data cell belongs to this header, or to these multiple headers. The first data cell, 19886, we're going to select it and say that it belongs to both Eugene and to the undergraduate header, so select it, properties, and here we choose the associated header cell IDs window. Choose the plus icon to create these associations.

Oh, well I didn't want to do that, we'll just ignore those autogenerated headers. This belongs to Eugene, so we're going to select 'e' from this list, ok, and it also belong to the Eugene undergraduate header, so we're going to select 'eu' from this list. That's why it's important your header cells have intuitive IDs, because this is where we refer to them. Now we need to do this for every cell in the table, holy smokes, you can actually multi-select if the association is the same for every cell, so you don't need to do it for literally every cell individually, I'll select both the winter and the spring Eugene undergraduate cells, and again, e for Eugene, eu for Eugene undergraduate.

Select all three of these at once for Eugene and graduate, this will get e for Eugene, and eg for Eugene graduate.

P for Portland, Portland undergraduate.

Lastly, P and PG for Portland and Portland graduate. Here's the part where it gets extra scary. I have complex column headers but simple row headers, because my row headers are simple, I don't need to create IDs for them, this association is determined automatically. If I also had complex row headers, I would need to give them their own IDs, and if I did that, I wouldn't be able to multi-select cells to bulk-change their IDs, I couldn't, for example, grab all of the Eugene undergraduate cells and edit their IDs at once, because each one of these would have different row IDs, meaning each and every individual cell would have a unique combination of manually identified row header IDs, so you'd have to go in an do this step for literally every single cell in your entire table, and this is a sample table, it's 12 data cells, right? If you had a large spreadsheet, you could have hundreds, maybe thousands of cells, so you could literally spend an entire day doing this.

So, if I have, if that last statement strikes fear into your heart, I'll be honest, that's kind of my goal. It's not fun to fix these tables, and if you can put yourself in the shoes of a person who uses a screen reader, it's not going to be very fun to listen to them either. So to repeat, if you have to use tables, please use simple tables. If you don't have a choice and need to use complex tables, this is how you do it. If you're in this position, first, I'm sorry, and second, I am here to help. I'm not going to manually fix these tables for you, but I'm glad to provide advice and guidance if you need any clarification on what I've gone over on this video, because I get it, this can be a little bit tricky. So if you need additional support, please email me at ictaccess@uoregon.edu, otherwise that's everything that you need to know, thank you for watching.