Hello everyone. I am Marisol Miranda from EASI equal access to software and information and I want to welcome you all to the webinar on creating accessible columns and data tables.... Norm is not going to be here today but we have Beth, his daughter. Today's presenter is John Gunderson from the University of Illinois, a good friend from EASI. And well, John, the microphone is yours.

 

   Okay, well hello everybody, thank you for coming today. Today I'm going to talk about accessible columns and tables using HTML and I will try not to make it too technical. But I think one of the things that could take people are participating, and are still this is probably a less technical crowd, is that what you are, one of the major things is that you can actually help educate your IT people or information technology people wherever your work to help them understand that you want to use tools and features that make it easier to create accessible tables with HTML and we will talk about some of the issues today that you could bring to them. So I'm going to have to slide number one. And I will review column and table webinar. The first part of the section I will talk about how do you use tables to create accessible columns. So many editing tools or environments only allow people to use tables for layouts or maybe the only convenient way to do it, so what are some of the accessible issues and using tables for column layout. Then we will talk about some of the basics of data table accessibility and some of the tools that people may be using to create accessible, to create tables whether for columns or data tables. And then how can it be easier to create accessible data tables. I did a survey recently of the implementation of markup that supports accessible data tables and it is very low on the web. I think less than 30%. I did not include a slide on that, but it is a big issue just like labeling form controls. Any questions before we get started today? Okay. So let's get started. The first thing I think that is really important to talk about especially if you're going to be advocating for more accessible tools for authoring data tables you need to know something about the W3C Web content accessibility guidelines 2.0. How many people are familiar with that? Okay, couple people. Alright, I'm just kind of as our overall overview quick tag for 2.0, short for Web content accessibility guidelines, it has five principles, 12 guidelines and 61 success criteria. So the 12 guidelines are under five principles in the 61 success criteria are under the 12 guidelines. The success criteria are actually the most important features at least from accessibility implementation and we had to point out and also many of them are going to be incorporated into if you are in the US and use section 5 we refresh. But the success criteria are where there are testable or techniques for implementing accessibility. So I think it is important to understand where tables fit into WIC and it is an important document if you're going to be advocating for more accessible information technology. For tables with me to make sure we comply with this success criteria for all WIC. If it is a layout or data table this is the success criteria that is important. For accessibility. If you look at accessible layout requirements, the success criteria that is most important is the success criterion 1.3.2. With a short title of meaningful sequence. This is basically saying a technology like a screen reader reads to a document that the document makes sense if the person reads through the document in what is called document order. So basically when you read through the document headings line up with the content and it is easy to understand how the content flows on the stage. That is one of the biggest issues with using data tables for layout is often things get disconnected from each other. Headings don't line up with the content for this section because they are any different realm than the row being used for content. It is a fairly subtle design difference that can have a big impact on screen reader users. So let's take a look first at as an example. Slide number four talks about accessibility issues, reading order for screen readers, how you use tables for layout will affect the reading order. People using speech will have in accessing that page. I don't think this is done anymore but some of the wiki markup out there sometimes people use spaces to try to create columns. This is a problem for screen reader users because there will read the whole line across both columns as one line in a screen reader. And obviously if you have text that is not going to make sense to a screen reader user. That is another issue if you are using some type of spacing to create the space characters to create columns that will create problems for screen readers. If you are using tables for layout want is to use the simplest layout possible. For example a table with one row into columns if you are just trying to create two columns. All content for a section of content should be in the same data file. This is where accessibility problems falling. People will put the heading in one row and the content in another row and the heading is disconnected from the content, so what ends up happening is that when the screenwriter closer to document it may read the headers were maybe two or three different columns and then start reading the column content. So it reads all the headers first but when they start reading their content, they don't know where, okay, where one section ends and one section starts and having all the section headings together doesn't make sense either because they are headings and they don't necessarily connect with each other very well. In terms of markup and other information we need to have all the content, we shouldn't use TH or caption elements and do not use any summary or scope or any of the special HTML markup that is available for data tables. We will take a look at that little bit in the first example. On slide number five here this is like a be a typical Web newsletter. There is kind of a banner at the top and on the headings in this particular case the banner on the top is the Illinois disability news and there are two columns Beckwith students raise disability awareness and an article after that and the Harold Sharper humanitarian award is the setting for the second column. Look at the page visually of people as people can see it really doesn't look inaccessible, it is just text, but this actually uses a table market, markup in an inaccessible way. I don't know if you can see when I scroll down. I guess my, okay, okay, well I guess the slides, have some source code at the end of the slide, but apparently going through TC conferencing must have dropped my content I guess. Let's take a look here. Okay so you cannot look at the actual source code I guess through TC conferencing. It is a bunch of, I see code but it is all just a bunch of garbage. It is not the code you are supposed to see. This is a basic problem with slide number five is that the Illinois disability news basically the heading spec with students raise disability awareness and Harold Sharper disability... are you in a separate row than the content underneath them so when a screen reader reads through this you will hear header level III Beckwith students raise disability awareness then go to the next item Harold sharper humanitarian award winner and next item... he will read through that article and then it starts to the next column of Thomas R. Brown is Dir. of veterans affair and music. Basically the headings have been disconnected from the text content underneath so it's fairly easy to fix this problem. Here's the same newsletter. It doesn't really look that much different now the heading Beckwith students raise disability awareness and Beckwith students Stevie Hopkins and all that is all the same and Harold sharper humanitarian award winners in the same cell as the Thomas R. Brown content. So he really doesn't have to make the document look visually any different, just making sure connected content is in the same data cell. Does this make any sense to people? If you look at, if you have a separate browser you can actually look at the same URL. What is different, if you look at the URL, why you will see in the HTML markup that both the heading and the content underneath the headings are in the same data cell for the accessible version. In the previous example the heading content like Beckwith students is in a different data cell than the content underneath it. So we want those both in the same table cell. Okay so let's move on to data tables. So WIC 2.0 data cell requirements this is a part of success criterion 1.3.1. Intro to interrelationships. So basically just the previous requirement and WIC, this means that we have to provide information if you are in a data cell to know what other cells in the table are associated with the that gives a table cell meaning. Reason people use, the reason people use tables for the layout of data or tabular information is that the spatial relationships are likely cells at the top of the column or cells on the right side of the column often give the data cell the data value is meaning if it is just a number MIB the price of the product or the total of a product it might be the description of a product. Some other cells in the data table help people understand what does this all mean, and for speech users you want to make sure that there is information available that helps them understand what data cell supply, or what headings also point to the particular cell we will look at some particular symbols today slide number eight talks about some of the basic HTML data table markup for accessibility. The primary, there is an element called the caption element that is used to provide a short description or title for the table. There is also something called the summary attribute. This is used very similarly to the caption element. And it is fairly important inaccessibility right now because in terms of access to technology. Assistive technology support reading the summary attribute more than they support using the caption element. I think from a historical perspective why that has happened is that caption is used so little by people creating tabular data tables that the screen reader vendors and consumers of them found that summary somebody creating accessible table that summary is a much more reliable source of information about a data table so while screen readers will read caption data intends to treat them more as a data cell than as a title for the table. Although we tend to reemphasize the caption element should be used for the title elements. So we will see if implementation of WIC to increases in use by developers of the caption element and hopefully better support in assistive technologies. So this is for basically the caption element in the summary attribute provide a means to provide a short table title or description of the data table. For example in the screen reader you can navigate through the data tables using keyboard commands and the summary help people to know what is in the data table before they go explore it. The second part is column and row headers. There is a special, there's a data cell element called the TH element which is table headings. By putting this in a column or a row, it basically says this is the heading cell. So what an assistive technology can use is if there is a TH element in the same column or the same room it will use that information to help identify the content of a data cell and what happens is if you move left the screenwriter will basically just read the change in column header because you are moving left to the next cell, you're not changing Rose, move down or up that it will make changes to the row header. It doesn't read headers all the time of other functions in screen readers to request that all the headers be reread. Screen readers can be pretty smart if it knows which headers it should be using. If you don't use headers then it has to kind of guess. They make as right or it may guess wrong and if it guesses wrong it can be disorienting to the user. There's also a scope attribute and a headers attribute, the scope attribute can basically be used to say that the TD element is being used as a header for this row. DH is the preferred technique for doing that. But scope is a feature of HTML and assistive technologies will use that information. For more complex data tables where there might not be, where there is something called row and column stands basically, table cells that span more than one column or one row you may need to use other attributes to be able to say okay, what exactly are the headings appropriate for this particular table cell. In very complex tables you might have to look at several table cells that might not necessarily be in the same row or column to identify what that piece of data is. Okay, so that is a little bit technical, so let's take a look at a dinner table. Data table. The source code is all messed up that solid future of TC conferencing but if you have a browser outside of TC conference (inaudible) you can use, you can actually view the source code independently and it will show you the content. This is a little data table that doesn't use the TH element, doesn't use the caption element, doesn't use the summary element and basically uses all TD elements and in-line styling to create the visual effects. So this table would not be very accessible for people using a screen reader. So screen readers would have to guess what the headings are. This being pretty simple it would read pretty well but if you add more rows or especially columns it might not read appropriately. Especially for getting information about what this table, what is the table about. There wouldn't be summary or caption information so it might tell them it is a data table but they have to return to table to figure out what is the data table about. For many people that might be too much of a bother unless they really know what they are looking for and think... part of the information they're looking for. If you move on to slide number 10 it shows the same data table that uses the TH element to the caption element in summary adjectives if you have another browser outside of TC conferencing you can actually go in and look and see look and see their own caption elements and a summary attribute on the title tag. In the page. So with fairly simple changes to markup you can significantly improve the accessibility of the webpage. Questions? Defuse the summary attribute of the table or caption element that is part of the table. At least in my rendering, you basically have to go and use a different browser, but TC conferencing system is not rendering the source code correctly. Let me check here. So, you have to use a separate browser than TC conferencing if you want to see the actual source code. And, the slides are all available in HTML, so you can look at them at any time after the presentation. I don't use PowerPoint because it is not very accessible. I create my own HTML slides. Yeah, the URL for the slides I have actually put in the conferencing system so you can save a link to it. That's also a presentation page. So you can go back to the CNet website and also given access to the features. Back to the slides. Okay. So what are some of the issues I assume that most of the people here I believe our educators, so how many people here use blackboard or desire to learn or some other type of web course management system? Moodle, okay. D2L, okay those are all very popular tools and most of them have built-in tools to create content, HTML content. This campus we happen to use something called blackboard and it is rebranded in the slide here, called Illinois compass here. Difficult to even know what content system or course management system but here I here have gone into blackboard and has to create a new file as an HTML villain if I want to create a new table there is a toolbar here and one of the toolbar options is to insert a table and you can see that on slide number 11 here it's the one with the Crosland's going to basically look like a table. If I press the button that brings up a little dialog box I create the table in so I can add to it the rows and columns of the table, the table width, some styling features, row and column properties, high bandwidth, cell properties and padding, but I don't have any information here about TH elements. It does allow me, it does have one feature that allows me to add a table caption. So if I check the table caption checkbox and I type in some text in the dialog box it will add the caption element. But there is no way at least through the toolbar or dialog box for me to tell it anything about TH elements or the summary attribute. So if I move the slide 13 here after insert the table I basically have to go in and if I wanted to replicate the data I would use like bold incident during which basically makes it look like the table we had before but it is not accessible because it is not adding the TH element in a summary attribute. The slide number 14, the only way to do that is use the tab on the bottom of the editor called source view and go in and actually edit the HTML which for a lot of especially instructors is probably way more technical than they are typically used to doing. So they have to go in and change the TD elements to TH elements and add a summary attribute to the table after me. So it's not a very easy or probably practical way for most people to create accessible data tables. Andy really have no information also using this interface that you've created an accessible data table. He would probably be okay if you are creating columns with this again as long as you just put all the content for the section in the same data cell there probably wouldn't be an issue because it is difficult to add TH in captions and summaries as to the to the file you are trying to create. So if we look at the blackboard content editor, some of the accessibility issues. When it is a Java-based plug-in, the interface is not going to be accessible to people with disabilities basically people using screen readers would not be able to edit content using this technology. The only thing from an accessibility standpoint for the data table is that we could have the caption element to the dialog box. If you want to add the TH for the summary of the good HTML editing view and go in and in code and change it. Not very practical if unless you are a pretty skilled HTML developer. How many people here have ever coded an HTML page or are familiar with HTML markup? I should have asked at the beginning. Okay, Beth, great. Okay. Okay. One of the issues is that a lot of the instructors are not very familiar with HTML. Primarily the main thing is that they want the content up there, so overall while we want to people to create data tables especially as part of instructional material is at the user interface should help them create the accessible content. Ideally without them having to know very much about accessibility. But by allowing them to put in table header information and other information just as a part of the process of creating a table and by using the features they got a lot of the formatting that they won't do for a data table or the data presentation without having to do a lot of other WYSIWYG editing or in-line styling. So let's take a look at another technology. This is a media wiki data table markup. How many people here have ever used a wiki? Okay well if you are using a wiki you typically use funny characters to create a markup in the wiki to create headings or lists, whether they are ordered or unordered, predefined, so most wiki markup languages used to create data tables. Here's information. There is a website here. On the markup available to create accessible, to create data tables or any type of table. I guess what was differentiated data table from a layout table again is not using the caption, the summary, the TH elements and if it is the layout, making sure that you have content that is connected to each other in the same data cell so it is not going to be read out of order. So it could be used to create layout tables too. Just make sure you do not use the wiki markup that would be associated with a data table. So we take an example here, slide number 17 for the Web accessibility scoring information. The markup that we would use here. So the media wiki code here is basically a {and | to create the table. Start the table. And you can add a caption using | cause and then putting the text for the caption after it and! Mine is says to start a new row in just! Says this is just a heading, this is to create a TH element. The first was basically header cells so we use the exclamation point to create cells for that row, then we put in and! -- Again for new row... queasy! And we have the first data cell in the user |. We can repeat the process for the whole table and it the end of the table you basically user | and} most wiki's have some type of markup to support this. The only feature that media wiki does not support as adding a summary attribute to the table but otherwise for the simple data tables it does support using TH and the caption element. Any questions about the media wiki? Another thing that we see here, this is a different editor this is called a CK at her and they've got a lot of work to support accessibility. This could actually be a replacement for portal or D2L, or even our own blackboard and the CKE editor does have a number of accessibility features. One is that it is written in JavaScript so it is actually accessible to people with disabilities. Even people with disabilities using screen readers so they can actually offer content using the CKE editor. It also supports successful marker. It supports adding the caption element and the summary element and the TH element for rows and columns. This is a link to the demo site so that you can go and try it if you want. And slide number 19 shows a screenshot. Again, one of the toolbar buttons as insert table, so you press the button. When you press the button it brings up a dialog box and we see here that it does have accessibility features. So under that table properties it as a way, one of the circled areas is what should be headers on this? So we either pick first row, first row, our first cell in the row, or both. First column, first row or both. Then it has a place to add both a caption in summary information. So I have all of the accessibility information previously at a table in the page we could go ahead and edit the table and we see that it has the TH elements I didn't look at the first code, but you can actually see the TH elements and the caption element and the summary element if you go to the HTML view I showed that through the slides here. So this is an example where there is an accessible alternative to some of the accessible technologies that you might see in other places. That is I believe an important feature for people to hear companies that are selling stuff as IT people integrate products like Moodle, to make sure that to make sure that accessibility or parts of purchasing configuration or feedback to whoever is developing it whether it is open source or whether it is a purchased product . especially with purchase product because then you actually have purchasing power to improve accessibility part so the conclusions for my presentation is that you need to ask IT support people to help improve tools. For accessibility. So if we want more accessible tables we need tools to help people understand the accessibility and provide accessibility support. If nothing else, warn people that they are not creating accessible tables. Right now there is really no feedback. There is basically what I call what we have right now for accessibility is what I call accessibility by exception. If the author wants to be accessible, the author knows something about the accessible markup, in this case today we talked about HTML tables, knows about what markup they want, and thirdly, does the tool supported. Some of the tools that we looked at today did not really support accessible tables, others didn't. So you have to have all three of those fEktrons and that is pretty big stuff. You people here have taken time to learn about data table accessibility but think about all your peers who probably will never take the time. So that eliminates a lot of people from the first step, and the other don't make any difference. What we really don't need his accessibility by default, that it is harder to create inaccessible content. It is harder to create an accessible tabular columns. It is harder to create inaccessible data tables because the user interface and forces people to include accessibility information. Try to create a data table (inaudible)TH elements are caption or summary of the tool would maybe wouldn't let me out of the dialog box to add the features so those are some of the features we need to look at. Part of this is why I included the WIC 2.0 and requirements even if we didn't understand all of the markets today you can point people back to the way tag requirements to say these are part of the success criteria that are part of international accessibility standards or requirements so we need support to make sure that we are implementing these especially in education where there are some laws that require public schools that include accessibility indexes. Access. The CK editor. Let's see, I don't have a screenshot of that. And I don't know if CKE editor allows you to look at those HTML source code. Let me just... unfortunately I do not have a screenshot. Vicki, here's why I also use... accessibility features by caption summaries are fine but my TH starts like this.... Yeah, there's a lot of tools out here to do these types of things, so my suggestion is to go back to Ektron and say hey, I need help with this. Companies wn respond if they get bug reports. If you know what you want for accessible tables that the company isn't helping you do it, say, this is a problem. It is causing me to take extra time to create something or extra skill, and you know that it would be a simple fix for you to fix this problem to make it easier for me to do that. Typically, I'm not sure that the scope attribute helps a lot with TH elements, but I'm not a big fan of the scope attributes. But I guess it does have it's place and there are some areas of the accessibility community it is the preferred way to create accessible tables. I would provide feedback directly to Ektron and see if they will fix the problem. Are there other questions today? Or comments? So, where can I get actual examples of what the code should look like? Well, we have some examples here. Let me put a slide in. The W3C has examples of accessible... here is an example of some simple data tables, or simple data table to I will put the link in here to. There's also more complex data tables. So here are two examples of how to add headers (inaudible) in accessible markup. I guess I should have had a slide about this, I apologize. If we go through what they want and how to meet... so here are some examples from the W3C. The union is to show people W3C have a number of examples to have accessible tables those are examples of where you came up to get ideas of how to make different types of tables accessible. I think data tables this is a little bit more complex than some of the other accessibility features and again, if it is just a symbol table layout, all you need is a caption summary and the use of TH in appropriate places. Then you don't have to worry about, or headers, but if you have more complex columns or headers coming back to this example, you just see there's a lot of column spans and row spans, so you need to use the headers attribute down here you can see the headers such agreed to point to the data cells basically to the idea of the TH elements in the table that you want to use to label that particular piece of information. Because of the screenwriter has to guess whether it is row and column spans it will probably guess wrong.... I don't really know given my previous experience with Adobe tools I would be skeptical but I don't know, I don't use Adobe contribute so you would have to look at what it actually does. But I cannot really speak to Adobe contribute. Yeah, I would be daring. If you are not sure you can call your Adobe representative and ask them to help you understand how you can create accessible stuff. Again the more feedback you give to companies about wanting to create accessible content, the more seriously they take. One of the problems about accessibility in general is that the accessibility community complaints to each other but they never take those complaints to the companies or the products and services that are causing the problem.... Eight or nine years ago maybe not that long ago I was at a conference talking about in accessibility of course management tool called me was about online education and somebody was talking about how they created, they had a big distance-learning problem, program with lots of people with disabilities in the dark about the accessibility of content management system and how they created a user group to get around the problems and so that people with disabilities could still participate, and to estimate the end, did you ever take any of these complaints or experience back to the company and they said no. So basically the company was unaware of his accessibility problems. This is a major customer of the tool and they also had a wealth of information about the problems but if they would have been identified by the company to company would have been able to fix. If you take nothing away from this presentation I would encourage people to take their questions back to the companies or people providing the services and help me satisfy the criteria 1.2.3... even if you don't understand all the technical issues. Adobe contribute, ask Adobe, how are you going to make create accessible content. I know I can maybe with your product, but how are you going to make it easy for me. Why does it have to be an exception. I don't really know a lot about contribute a lot of tools really don't support accessibility as far as the default workflow. I gave up the microphone, so if other people want to use the mic, that's fine to ask their questions. ID, another ID question. You mean ID instead of a description is okay, I'm not sure Vicki what that means instead of a description, IDs on the webpage are used to identify elements on the page and how that is important with complex data tables is when you use the header attribute you actually put in a list of the IDs of the TH elements associated with the data cell. I'm not sure what you mean by description IDs are used to identify particular elements on a webpage. There is not a description element that I'm aware of. And why don't I like the scope tag? And if you're using TH elements if you have TH at the beginning of the first cell of a road is basically applied to the whole row. If you have a TH elements at the top of the column it is implied that it is for the whole column. About the only place that the scope attribute might be useful is in the first cell at the top left corner... where there may be ambiguity but I know a lot of people in the accessibility community like the scope attribute. And they put it on the TD element into them is the equivalent of a TH element and if there is assistive technology support for it, so it is the users choice. If you are looking at the source code I would rather look at TH elements in scope attributes. The other advantage to a TH element is if you are using CSS they are much easier selectors using the scope attribute is a selector if you want a style heading, typically want to style heading cells differently than data cells. Also better to use TH for your selectors because I think it will make the CSS code a lot easier to read. Any other questions? Well I just want to thank everybody for participating today. Hopefully I shed some light on the accessibility of data tables and layout tables. And the slides are available if people want to look at it. I will try to add some references to the last slide. The last slides for more information to some of the links I put in there so if you go back to the presentation you can get some of the links.

 

   Thanks, John. I am one of your fans and I love the way you explain these complex things. Thanks for being here. I am pasting here the URL for the resources webpage where you can find all the links that John mentioned Greg thanks, everyone for coming in and this is our last webinar of the series so I hope to see some of you or I'll have you on the next webinar. Thank you very much. Thanks, John.

 

   You're welcome, thank you for asking.