Transcript for Implementing Accessible Workplace Tech: Creating Accessible Tables for the Web, featuring Gian Wild of AccessibilityOz. Original recording date: November 9, 2016.
Introduction
I'm very excited to introduce our speaker today. Her name is Gian Wild. She is the CEO of Accessibility Oz, and she has worked in accessibility industry since 1998. Gian spent six years contributing to the W3C web content accessibility guide, WCAG version 2.0 and spoke at the United Nations conference of State Parties on the importance of web accessibility. We have seen and known Gian in the accessibility field for quite a while and are really happy to have her join us here. So without further ado, I will turn it over to Gian and encourage folks to participate in the chat. Thank you.
Presentation
Thanks, Josh. Thanks for the lovely introduction and thank you everyone for joining us today. I am very happy to be here and this is just one of a series of conferences that we'll be doing. We'll be doing one on images and PDFs, and video as well. So I hope that you guys can get involved in that. We'll also releasing some love quotes and factsheets around these topics, so there's quite a lot of information. And so feel free to ask questions, and I hope you guys are all okay with my accent. I am Australian. I am in the U.S. I'm actually in New York at the moment. I spent quite a lot of time in the U.S. (inaudible) here as well. So it's great to be here. So let's get started.
There are basically two types of tables used in the Web. There's what we call data tables, and these are either simple or complex, and these are used to present data. So, you know, a table of information, say costs for a mobile phone plan or something like that. And the other type of table is a layout table. It's used to lay out information, so just present information. And let's have a look at some examples now.
So data tables, as I said, is used to present tabular data. Often it's numeric, but it doesn't always have to be. Sorry. I'm just wondering if there's anything that I can do to stop the fading in and out. That's really quite annoying. Okay. All right. Just one second while I rearrange the mic. Okay. Hopefully that is a little bit better.
So data tables are used to present tabular data, often numeric, in an easy-to-understand format. The meaning of a piece of content is affected by its relationship to the table column and row headings.
So this is an example of a simple data table. So if you look at the third column and the third row, it says there 19 cents. Now that doesn't actually mean anything by itself. It only makes sense if you look at the relevant heading. Oh, sorry, we're going to go 51 cents. It only makes sense if you look at the rate-per-mile heading and the motorcycle heading, and then with that information you can find out that rate per mile for motorcycles is 51 cents.
A complex data table looks something like this. It's got quite a lot of information, and if you looking at a particular cell, say this cell here, where it says 171, there are actually three table headers that are relevant. There's the Q4, the quarter four. There's the year 2015, and there's the location, which basically means that in Bethesda in quarter four of 2015 there were 171 staff. So that's what a complex data table looks like. I'm glad (inaudible). I'm also speaking louder.
Okay. So the thing about data tables is they often have visible borders and they only make sense if you know the heading of the row or column. They can't be understood when read cell-by-cell, left-to-right, top-to-bottom. And they're usually used when presenting complex information.
So let's talk about layout tables. Layout tables are used to present or space or lay out page content and can be purely decorative. The arrangement or position of information within a layout table should have little or no bearing or impact on its meaning. So this is an example of a layout table on a website. And if we outline the table cells themselves, you can see that there's just really one row, and we see this a lot with layout tables, so this is one row. And it's important to note that it doesn't really which cell you read first and the content in cells is not relevant to any other content in any other cell. So often they do not have — layout tables do not have visible borders. They often do not have headings for the row or columns, and they always can be understood when read cell-by-cell, left-to-right, top-to-bottom, and they often make sense if you read the cells in any order.
Okay. Now another thing to think about is maybe you don't really need table. There are actually different things that you can do instead of tables. You can use style sheets instead of layout tables, texts instead of data tables, and graphs instead of bar tables.
So this is content. It looks like it's in a table. It's the (inaudible) of the PEAT Works website, and it has five columns; the title home, government wide, initiative, customer support, reference, and website information. So it looks like it could be a table with five columns and one row, but this is actually done all through (inaudible). So it's not actually a table. It still gets read column by column, but it's also a lot easier for, say, a screen reading of two, three of that content.
This is another example. So here the task is pay, and the days that you have is two business days and remove the property, you have ten business days. And that doesn't make a whole lot of sense by itself. And this is an alternative way of getting the information. So it has the heading awarded. And it says "The sale has ended and there is a successful bidder of the property. The successful bidder has two business days to pay and ten days to remove the property."
So sometimes just having content (inaudible), as opposed to a data table is preferable. And this is to present really complex data. This is a great graph. It talks about — it shows you the usage of various screen readers over the years, from January 2009 to July 2015. And as you can see, JAWS has decreased from 2009 in about 75% to just under 50%, and video has increased from about 10% to just over 50%. VoiceOver has increased from about 10% to about 30%, et cetera, et cetera.
Now this content can be presented in a table as well, and that would be very useful for people who can't see the graph. But the graph itself is a really good representation of the content that's quite easy to understand. So when you do have really complex data like this, it's worth considering providing a graph, as well as a data table.
So let's talk about table accessibility requirements. So there are specific things that you can do with tables to make them more accessible. The first one is coded table headings. And so what happens is that you can simplify a particular data cell is a table header, and so that actually informs what the headers are for particular data cells. And so when it comes to simple data tables you do need to code those table heading and you use codes called TH.
With complex data tables you also need to code those table headings and you need to do it with TH ID and TD headers. However, if you have a layout table, you don't need to code those table headings, and, yeah, you just need to leave the table as it is.
The second table accessibility requirements are captions. So captions are some code that often appears at the top of the table, and it's basically the title of the table, and so you do need to have a title of the table for a simple data table, and you do need to have this title for a complex data table as well. However, it's not something that you do in a layout table.
The third requirement is summary. Summary is a summary of the content in the table. It's not just a title. It's actually a description of content. So view the content or the average detail, we'll talk about how you would do that. And once again, it's something that you do have in a simple data table, you don't have in a complex data table, but you don't it in a layout table. And the summary is not visible to the users, but it is actually read to screen reader users so they can get an idea of the content of the table.
Now another requirement is that whether the table needs to make sense when read cell-by-cell, left-to-right, top-to-bottom. Now that's not a requirement for simple data tables, and it's not a requirement for complex data tables; however, it is a requirement for layout tables.
And the last requirement is that the content of the table only makes sense when referring to the table heading, and that is something that is required for simple data tables. It is also required for complex data tables. But it's not required for layout tables. So let's look at these in more detail in terms of the type of tables that we're looking at. Let's start with simple data tables.
So as you saw in the previous slide, these tables do need to have coded table settings. They do need to have captions. They do we need to have summaries. They don't need to make sense, whether they're left to right, top to bottom. And they do make sense only by referring to the table heading.
So let's come back and have a look at that original system data table. So here we've got basically the title of the data table called privately owned vehicle mileage reimbursement rates. There are four modes of transportation, including the privately owned automobile, government furnished automobile, motorcycle, and airplane. There's an effective applicability date and for all four modes of transportation, it's January the 1st, 2016, and then you've got a rate per miles for those four modes of transportation.
So these outlines here are the table headers, and these are what you have to mark up with TH. So the first row has three columns, three cells; modes of transportation, effective applicability dates, and rate per mile, and they're all table headers. And then the first column also had privately owned automobile, government furnished automobile, motorcycle, and airplanes and they are table headers as well.
So how do we go about coding that? This is what the code of that table usually looks like. TR stands for the beginning of a row. And then TD stands for the beginning of data cell. Now they aren't data cells. They're actually table header cells. So what we need to do is change those TDs to THs, and that's what it looks like here. So here you can see mode of transportation starts with TH and ends with TH. And that's how you specify something as a header cell.
This is the caption. The title, "Privately Owned Vehicle Mileage Reimbursement rates. So the way that you quote the caption is within the table just after the table element, and you just write caption, quote, caption and then whatever your caption is, end quote, and then the element. So that's really easy to put in.
I just see a question here about both equals column is both equals row. That's actually not necessary. You can use them if you want to, but screen readers are really very good at dealing with THs now, and so that requirement is not something you need to worry about.
Summary: So summary is an overview or summary of the content. It is not the same as the caption. Now a lot of people put the summary the same as the caption; however, that's definitely a problem. There is sort of some differences in HTML5, where table summary is obsolete, and we should use aria described by instead. However, it's still something that is used a lot by screen reader users — screen readers, and so it is something that I recommend that you do. There certainly was a lot of discussion and disagreement about, you know, removing summary from HTML5. So it is something that maybe in a year or two it will be sufficient using aria describedby. But at the moment, I still think summary is a good idea.
So summary is actually meant for people who can't interpret the table, and because you know it's too complex or something like that, and it should provide general details about the content, so it should actually provide information about, you know, an overview of the main point or average information so that even though people can't get all the information that they need, they'll get the important information.
So let's have a look at this table again. So I'm just going to read out the content of the table. So for a privately owned automobile you get 54 cents per mile, so government furnished automobile you get 19 cents per people. So motorcycles you get 51 cents per mile, and for an airplane, lucky people, they get $1.17. And the effective accessibility rates for all those transportations is January the 1st, 2016. So let's have a look at what we've done for the summary.
We've said rate per mile of four different modes of transportation, including privately or government-sponsored automobiles, motorcycle, and airplane, effective date of January 1st, 2016. Rates are lowest for the government-funded automobile, 19 cents; approximately 50 cents for the privately owned automobile and motorcycle, and over a dollar for the airplane. So if we go back to that table, you can see that it gives you a pretty good overview of what the content in that data table is.
Sorry. I'm just going to summarize the information. So the summary is actually an attribute of the table element. So you put it in the table code itself. So table summary and then equal quote, and then you add your summary and end quote. And, really, the important thing to know is that the summary and the caption are very different things and summary can often be a paragraph or two and could be quite detailed.
So let's talk about complex data tables. As we saw before, you need to code your table headers at this time with TH ID and TD headers. You do need to have a caption. You do need to have a summary. They don't make sense when read cell-by-cell, left-to-right, top-to-bottom. And they do only make sense when referring to the table headers.
So this is the table that we saw before that is incredibly complex. And, really, what I would suggest to you is that if you have a table that's this complex I would suggest breaking it up into smaller tables. So these are all the headings in the tables. So we've got 2014, 2015, 2016, Q1, Q2, Q3, Q4, Q1, Q2, Q3, Q4, Q1, Q2, Q3, Q4, Arlington, Alexandria, Bethesda, Fort Lincoln. So there's a whole lot of table headers, and these are very complex tables. So, really, it would be better to break it up into years.
So here, this is the number of staff in 2014 by location and quarter, and this you can see here you've only got two sets of table headers, Arlington, Alexandria, Bethesda, Fort Lincoln, Q1, Q2, Q3, and Q4. And you can code that as a simple data table. So let's talk about layout tables. As we saw before, layout tables should not have coded table headings, those should not have a caption, and they should not have a summary. They must make sense when read cell-by-cell, left-to-right, and top-to-bottom. And they don't make sense when referring to the table heading. And, in fact, they don't usually have table headings.
So this is an example of a table, a layout table. It says three throws, and the reason why this is a coded table is so that people have easily put a background color to a particular row. So the first row is federal acquisition service and it has a light gray background. The second row is public billing service, which has a white background. And then the third row is technology transformation service, which has a gray background.
Now this is something that can be done with (inaudible), but it's a lot easier to do with tables, and so someone has actually created a table here just to add that background color. This here is the number table, and at the top of the heading is that says "Additional information is available specifically for," and then there's four sections; federal agencies disposing of, federal agencies looking for, state agencies and public organizations looking for, and citizens looking for.
Now that heading, "Additional information is" —
Gian, it sounds like you dropped out. Emily, this is Josh. Are you able to confirm that you can hear me and/or if you can hear Gian, because I lost audio?
I can hear you. I cannot here Gian. Can you hear me?
Yes. So bear with us, folks. It looks like she's typing in ore presenter chat. Hopefully we'll get her back on in just a moment. Apologize for the inconvenience. She's calling back in now. I'll use this pause to encourage people to continue to use the chat window for questions, and also other resources that we may want to share with each other. We will definitely have a Q&A with Gian at the end, if she chooses to address those now, otherwise I'll put them at the end and we'll run through them. But while you're waiting, please feel free to chat in the box there. Thank you.
Oh, thanks for bearing with us. We're in contact with Gian and trying to troubleshoot. Hopefully she will be back up and on here shortly. In the meantime, I see there are some people sharing some resources, which I love to see. That's what PEAT is about, collaborating and sharing resources. I encourage people to use this down time to get on the chat box and maybe share some information and tips, best practice or resources that you may be able to find.
Gian has joined the conference.
It sounds like we have Gian back. Are you there?
Yes, I'm here. Can you hear?
Yes, we can hear you loud and clear.
Excellent.
So I'll let you continue.
All right. I don't know what happened. My phone was still working apparently. So, yeah, I do apologize about that. So the last thing that I think I was talking about was this table. And so, really, the reason that we use this table here is to emphasize the heading. And the heading is additional information is available specifically for and we've done that by giving that heading a background. And so therefore, it looks like it's the heading for the contact (inaudible).
Once again, this is something that you can do with (inaudible), but it is sometimes a lot easier to do with tables. This here is —
(PHONE RINGS) I'm sorry I can't take you call right now. If you would give me just a few minutes.
Hello.
Gian, I'm not sure what that was, but I heard that dial in, which shouldn't be in presenter mode. But let's hope that was the last one. Continue.
Very strange. Okay. So this is a table that, once again, has the heading "2016," with that dark gray background, and then it has three columns. The first column is the date, the second column is information about particular events, and the third column is the location. So a table has been used here just to lay out the content so that everything is aligned properly, because if you just had those three pieces of content one after another, then it would not necessarily aligned properly. So once again, this is something that can be done with Star shoot but it's often a lot easier to do with tables. Okay. Let's talk about other issues with tables. A couple of contrasts is a big thing. It's really important that if you use those background colors or use different colors in your table, which I do encourage you to do, but you need to make sure that it meets both the color contrast requirements.
So this here is the Paciello Group's Color Contrast Analyzer. And what you do is you select a little eye dropper on the right-hand side here, and that will choose the color that you want to test, and then the results appear at the bottom. So we'll go through this in a little bit more detail. This is some content from the PEATWorks website. The background is a green, like a pea green, and the text is black. So we can see that.
If you go down to the bottom you can see that the color contrast, there are two options. There's Pass at AA and Pass at AAA, and that is relevant for small text, which is the small text outlined there. And you can see on the right-hand side that it also passes at AA and it passes the triple A, and that's about the large text. So there are actually different color requirements for the small text and large text, and this analyzer covers both. The other thing that you need to be aware of is using color or shading alignment to convey information. You can certainly use color and shade to emphasize the information, but you need to make sure that the information is here.
So these are product specifications for two different items, and where the items are different, they actually have colored the background of the cell light blue, so otherwise the background of the cell is one. Now this actually is accessible because you can tell just by looking at the content that there's a difference between the two items. So the first row is in white and it says "Warranty terms, parts," and for both items it's one year. The second row is "warranty terms, labor." It's also in white, and the terms are one year. And then the third row is height, and it's in blue. And the first item is 5.63 inches, and the second item is 5-5/8. So once again it's just emphasizing the difference, but it's also in text so everyone can access it.
And it's important to know that screen readers don't actually range changes in color or text or table backgrounds or things like that, so that's why you can't rely on that alone. The other thing is you really shouldn't use shapes alone to convey information, such as stars or bullets or crosses. So this is a table about venues that are available at each venue. So the Bills Vanina Sports Pavilion has one number of bookable spaces, maximum capacity of hundreds of people, and then it has a check under full kitchen. It doesn't have a check on the kitchenette. It doesn't have a check under the hearing loop. It does have a check under accessible toilet. It doesn't have a check under equipment. And it does have a check under on-site parking. But usually you can look at that and say the building as a venue has one bookable space, maximum capacity of a hundred, has a full kitchen, accessible toilet, and on-site parking.
However, those checks, it depends what they are, if they're images that can actually to say, yes, it does, this content, this is here. But if they're (inaudible) or they're some kind of (inaudible), they won't necessarily get read to a screen reader. And the other problem with this particular table is it doesn't tell you — there's no content [BREAK IN AUDIO] in that instance is actually put that content in the data cell.
Alternatively you could have a more information link that perhaps opens up more information and shows that to the user. But the problem is, is that a lot of screen readers don't actually read grammatical marks at asterisks. Certainly by default, (inaudible) for example, doesn't read asterisks. So screen reader users wouldn't necessarily know that there's more information. The other problem is that it's an asterisk, and usually you can look down the page and see where that asterisk is. But for a screen reader user it just shows you asterisk, and you don't know where on the page where that additional information is.
So that's my quick overview of tables. You can actually download the PowerPoint presentation, which is fully accessible by going to a11yoz.com/table, and I'm sure PEAT will sound out our version of the PowerPoint presentation as well. So I'm very interested in questions that you have, and I think you're asked questions about those, that if anyone wants to ask further questions about that, that would great. So I'll hand it over to Josh to organize the questions.
Thank you very much. Thank you, Gian. I'm glad we got our audio straightened back out. We did have a few questions. One you answered in (inaudible) and some folks answered in shared resources, which I was excited to see.
Q&A and Conclusion
There was one question, which you may have addressed. I'm not sure. It was basically when you were talking about summary and it asked, you know, someone had said they had seen elsewhere where summary was just described as structure of complex tables and not simple tables. I believe you addressed that, but I just want to make sure that gets focused on.
Yes. So that's actually something that we've seen over and over again; that summary has been used to say this is for cells and these are the headings. That's really not what summary is used for. I don't know why it's believed that it's used for that. You know, it's got six rows and seven columns. That information is read aloud by a screen reader anyway, so you don't need that in a summary. So when and — and the summary actually is very much just the screen reader. And when a screen reader encounters this table, it will actually say table six, seven rows, seven columns. So it doesn't make sense to put that information in the summary.
So, yes, the summary really is kind of a workaround for a table that's so complex that a screen reader can't interpret it. So that's why you have that kind of overview of content that's the most content of the interesting content. Does that answer the question, Josh? Next question.
Sure. So some people chimed in, and we'll have one shortly in the archives. But people asked about just what tools people were using to create accessible tables. Do you have any that you'd recommend and one specifically that is geared toward backup use?
Yes. So table creation in things like Word Press, or Drupal or King Site or Shared Voice often support the addition of summary and caption and TH. So they often don't support TH, ID, and TD headers. And that's where I recommend that you create a (inaudible) table, as opposed to try and create complex data tables. There is a (inaudible) called Tiny MCE, which we implemented at (inaudible) University, which makes life a little bit easier. And there is a product — I can remember the name from Ephox. It's called EditLive. I think's being renamed. But we actually use that quite a lot to create complex data tables, and it created the XML quite well. I might just jump in, because I can see there's a couple questions here. (Inaudible). Josh you can (inaudible).
I think we're good.
Yeah. The asterisk is definitely similar to using a footnote or an end note, so you should definitely (inaudible), you should definitely avoid footnotes and end notes. What you should do instead is have, you know, more info link or something like that that's an anchor link to that information. Or use JAVA Script to open that information. But, yes, footnotes and end notes are definitely just as problematic. And if you think about it, for a screen reader user, it's something like privately owned automobile one, and that doesn't mean anything to them. And even if it's linked, you know, privately owned automobile link one, it doesn't mean anything. That's why you can't use them.
Do all the tasks I covered also apply to tables on (inaudible) website? Yes, definitely they do. There's no difference between a desktop version and our website in terms of table XML. Yes, we talked about the tools. So, yes, addressing footnotes and end notes, yes, as I said, that's more information. Okay.
So the statement about summary — oh, not there yet. Summary, yes, it is obsolete next to (inaudible) five. It's something that a whole lot of people didn't agree on, and it's something that also a lot of the screen readers and assistive technologies are catching up to XML five and aria, so I do think that in the future you can replace summary with aria describedby. But it certainly not something that is supported in things like Drupal or Word Press or SharePoint. So you can — in some of those systems you can add a summary, but there's no way that you can add aria described by. So I would suggest — and also we know that the screen readers read the summary, whereas not all of them support aria describedby. So I think that that's something that will change with time, but at the moment, I suggest just use summary.
Josh, are there any questions?
I don't think so. If I did, folks, feel free to chime in. There's a question about scope, but people kind of shared some responses, so I think we're good. But if I missed any, folks should feel free to write in and type them in now. The back and forth is great, and we love to capitalize on Gian's expertise and get any questions answered we can.
Yeah, so just a comment on scope. It definitely was something that was popular when screen readers were not very good at interpreting TH and TH ID. But they are much, much better at doing that now. It certainly doesn't hurt to add scope. But it certainly, you know, it's additional code that makes life a little bit more difficult, so that's why I didn't cover it.
Great. It looks like someone else is typing in, so we have time for another question or two before we wrap up. Some people are thanking you. So I'll go ahead and talk a little bit about the series and start to wrap up. But I'll check the question box here in a minute, so we can come back to it. So if you've got a question, don't hesitate to jump in there. But I really want to thank you, Gian, for this initial discussion and webinar on tables. I want to remind everyone that we have a blog that she wrote, as well as a tip sheet that you can use and check out that contains a lot of useful information on our website at PEATWorks.org. And then let people know that this is just the beginning of a series we're starting to try to get some resources out to people's hands that is useful. So we've heard from other folks what they'd like to see. We worked with Gian to see what we thought would be useful and easy to get out there.
Next month, on December 8th, we're going to be having another of the series, so we'll have a blog, we'll have a tip sheet, and then another webinar that's really about images, and so how to ensure that the website images are both accessible and usable for people with disabilities, so we encourage you to spread the word and join us about that. And we'll have other ones in the series. But I would encourage folks to reach out to us and let us know if there are other topics or issues that you'd like to get some resources, insight on, and we can continue the series addressing people's needs.
So I don't think we see any other questions in there, do I? No. I see some — Corrine, thank you, has put in the resources. I appreciate that. Oh, here's one more we can address before you leave. Could aria describedby be used to overcome the problem with the asterisk question?
So aria describedby is not something that's unique to — it's not something that replaces table summary. Aria describedby, if you think about it, is kind of like an old attribute for an image, but it's supplied to a whole range of features like tables or field labels or things like that. So you couldn't — I wouldn't suggest that you use the replacement aria describedby, even as a summary to describe the asterisk content, if that makes sense.
So the question is could aria describedby be used to overcome the problem with the asterisk? So you could actually put aria describedby around the asterisk to add that content. So you could do that. I mean, you still come across exactly the same problem, which is that, you know, aria and (inaudible) five is not, you know, perfectly implemented by a whole lot of assistive technologies. I think, really, if you — yeah, think, really, the easiest option is to have a link that says more information, and then just have it an as anchoring to the content below. And usually that content isn't very complex. Usually it can just be put in the data fill anyway.
LG has said I'm not familiar with aria. Can anyone recommend a good website to learn about it? I'm open that. Yeah, I'll put that out to the audience. There's good stuff on the W3C website. But I'm sure some people have some great examples of the (inaudible) websites. So, yes, Corrine probably (inaudible) of course. And, yeah, it's definitely a great thing that just needs to be implemented a little bit more and supported by those, you know, screen readers and other assistive technologies.
It looks like there's another question that came in about templates to use with faculty, who may or may not be comfortable with styling XTML. I'm not sure, Gian, if that's something that you would know, or other folks on the webinar might be able to share that information with Alice.
Yeah, I think that's something to put out for the group as well. Okay.
So I can see (inaudible).
Folks might chime in with some answers. I'm going to move on to talk about some other things. So hopefully people will chime in with Alice. Also, if people think of, have questions, or resources to share, they could reach out to us as info@peatworks.org is a great way to connect and collaborate, as PEAT is always looking to connect with people and share resources.
Before we go, I do want to plug again that Gian will be joining us next month, December 8th, 2:00 Eastern Standard Time, and we'll be talking about website images and how to ensure that they are accessible and usable for people with disabilities.
Also, I want to announce later this month, please join us next week for our November PEATTalks. That's Thursday November 17th, at 2:00 Eastern Standard Time, and our guest will be Jenny Lay-Flurrie. I probably butchered her last name, but she's so nice she wouldn't mind. She is the chief accessibility officer at Microsoft, and if you haven't heard her speak, I strongly encourage you to join us and join the chat. She will be glad to have an interactive conversation with both. And she is going to discuss the issue of creating a workplace culture that fosters accessibility and inclusion. So we look forward to having her there. That's Thursday November 17th, 2:00 p.m. Please sign up, spread the word, and join us.
Otherwise, I want to send a big thank you to everyone who joined, who stayed through the technical difficulties, and to, Gian, thank you so much for this first webinar, and we look forward to more to come. Otherwise, everyone please enjoy the rest of your afternoon.
