 Welcome to TechSoup Talks. My name is Kami Griffiths, and today's webinar is An Overview of Website Accessibility. I would like to introduce Jane Vincent from the Center for Accessible Technology. Welcome, Jane. Greetings. Thank you, Kami. I want you to give us a little bit of an overview of what you do at the Center for Accessible Technology. Well, I work around a variety of issues having to do with the disconnect between standard computer design and the needs of people with disabilities, disability being defined in the broadest sense from people who have repetitive strain injuries to elders, to people with cerebral palsy or blindness or other traditionally thought of disabilities. And getting a message that's hard to hear me, Krishna, is this better? Okay. Well, we'll just do our best to keep your audio up as you go along. And just to let folks know, we did a – Jane and I did a webinar about a month ago and the audio for some was hard to hear. So we will definitely try to keep the audio nice and clear. So why don't we get started? Why is website accessibility important and who does it affect? Okay. A good reason to design for accessibility, first of all, is so that the maximum number of people can use your website as it is. So that, for example, killer contrast between text and background is comfortable for most elder youth to read. Another reason to design for accessibility is so that your website will be compatible with assistive technologies used by many individuals greater technology. Blind individuals use programs, some of you may have heard of JAWS or Window Eyes or System Access Go, programs that will speak the contents of the screen to individuals who aren't able to see the screen. But there are a lot of good usability reasons designed for accessibility as well. For example, a lot of individuals who have low bandwidth may have turned off automatic graphics loading. And the guidelines that make graphics accessible to blind individuals will also make graphics accessible to individuals who have graphics loading turned off. In addition, there are a lot of technologies. For example, Flash is not currently able to be run on iPhones. iPhone users are not able to run Flash objects. So if you have alternative access for people with disabilities, you also have access to an alternative to Flash for iPhone users. And I am speaking as loudly as I can, are people still having trouble hearing me? Okay, going on, I'd like to do a quick survey. How many people here today are involved in some way in programming for their website? So everyone just raise your hand if that's if you fall into that category. So I'm seeing several people indicating thank you. Go ahead and put your hands down now. I will be talking a little bit about programming specifics. I won't be getting a great deal into that. But I'm going to be dealing more with the what of accessibility than perhaps the how of accessibility. There will be a bibliography that Cami will be sending out afterwards. You won't see a lot of links in the presentation itself. But I have put together a bibliography with a lot of information on the topics I'm going to be talking about. But we will be receiving that after the webinar. Great, so let's jump into the guidelines. What guidelines are available to help developers know how to implement accessibility? I'm going to be talking about the major guideline. Somebody before the presentation asked about how do you include website accessibility in an RFP? And usually you would include that by citing either the Web Content Accessibility Guidelines, WCAG 2.0, or Section 508 of the Rehabilitation Act of 1973. And I'm going to talk about both of those. The Web Content Accessibility Guidelines 2.0 were published in early 2009 by the Worldwide Web Consortium for people who may have been familiar with WCAG 1.0, 2.0 supersedes and has significant differences from WCAG 1.0. They evolved, caused in large part by changes in Internet capabilities, in assistive technology capabilities, or from user feedback. For example, when 1.0 was published, screen readers didn't distinguish where one link ended and another began. So designers were told to put printable characters between links. However, now screen readers are able to indicate the beginning and the end of links. So this guideline for 1.0 is no longer necessary. It's mentioned briefly in 2.0, but it's no longer the requirement that it used to be. One thing that's also built into 2.0 is the intention to respond to new technologies as they develop. When 1.0 was released, you didn't have Java, you didn't have scripting languages at the level that you have now. So with the understanding that we now have of the Web, 2.0 is really set up to take new technologies into account as they develop. And 2.0 is based on four principles. The first principle is that websites should be perceivable. In other words, any information on a website should be accessible to an individual with a disability whether or not they're using assistive technology. The second principle is that the website should be operable. In other words, people who are using alternatives to the standard mouse and keyboard should be able to interact with multimedia, should be able to activate menus and buttons and so forth. The third principle is that websites should be understandable. And these guidelines have to do with clarity of language. Keep in mind that this benefits not only people with cognitive or learning disabilities, it also benefits people for whom English is a second language, beginning readers, etc. Understandable also covers predictability, having a consistent design within your website, and error assistance so that if somebody is filling out a form, make error, it should be very clear where the error is and how to fix it. And the final principle is robustness. Websites should remain compatible with assistive technology. The two guidelines, robustness, have to do with using correct coding syntax and taking accessibility into account when using scripting languages such as Flash or Java. Now, scripting languages hold separate topics. I'm not going to be talking about accessibility of scripting languages today, but if there's interest, please let us know in your survey at the end. And Tammy and I have already talked about the possibility of doing a separate webinar on accessibility in scripting languages. The compliance level in WCAG 2.0, there are three compliance levels. Level A, which is 26 criteria, these are things that must be in place for accessibility to be insured. In large part, they have to do with compatibility with assistive technologies. The second level is double A, which has 13 criteria. These are things that should be in place. People may be able to use your website without them, but it's going to be unnecessarily difficult. And then the third level, triple A, which is 23 criteria, are things that may be in place. And there's a lot of overlap on the triple A level between the guidelines and between basic usability practices. There's a lot of overlap between accessibility and usability in general. And one of the things on the bibliography is a link to a presentation I did a few years ago about the relationship between accessibility guidelines and good usability practices. WCAG 2.0 does not have any legal teeth, but Section 508 as amended in 1998 and administered by the Federal Access Board does have legal teeth, required compliance to Section 508 for the federal agency putting up a website. However, Section 508 is very useful for other entities as well. It's a good set of guidelines, for example, to cite in an RFP if you said that your website is going to meet the 508 guidelines. People generally understand what that means. As it currently stands, Section 508 has 16 rules. It's been under revision for about two years. And the forthcoming revision is intended to dovetail the Section 508 guidelines and the WCAG 2.0 guidelines much more closely. All current 508 rules, if you comply with the WCAG 2.0 guidelines at the AA level, then you will have addressed all the rules under Section 508. There are also international accessibility guidelines. In physiography, there is a link to the guidelines for a wide variety of countries. These guidelines are generally based on WCAG 1.0 or the 508 guidelines. They may not have been updated after WCAG 2 was released. So keep that in mind when you're looking at the guidelines for countries other than the U.S. What the guideline implementation usually involves. And let me ask, first of all, how many people are using content management systems such as Drupal, Press, Joomla, Quick Survey? Okay, so quite a number of you. At the end of this presentation, we will be talking specifically about accessibility in content management systems and in social media such as Facebook and Twitter. I'm going to be talking, however, for most of the presentation in more general terms. Accessibility implementation usually requires access to the source code. So it's usually implemented at the source code level. It often requires minimal code addition or modification. So usually there isn't a great deal you need to do to modify the code to bring it up to accessibility compliance. And you can often facilitate accessibility by using templates or cascading style sheets. So for example, if you have a template for your Web site that already has coding relevant to accessibility that everybody who's doing programming in your organization would use that can greatly enhance accessibility as compared to everybody having to create their own Web site, their own template. I am going to be talking more about cascading style sheets in more toward the end of the presentation. Now there are problems with the guidelines. And one of the problems is that they're obtuse. Guidelines really don't provide designers with a full context for understanding how people with disabilities use the Internet or use accessible technology. And that's one of the things we're going to try to address today. Second, there isn't necessarily consensus among individuals with disabilities on what is most accessible. For example, six screen readers according to a fairly recent survey want to know, want a description of illustrative photo on a page. Thirty percent, however, don't want any description. They just want to be able to skip over the photo. My personal suspicion, I can't prove this, is that this may correspond to the number of users who became blind later in life versus the percentage who were born blind. Just keep in mind that things are very individualized. And at this point, it's not really possible to take everybody's preferences into account. A third problem is that guidelines don't cover all users. In particular, they're not at this point fully addressing the needs of individuals with learning or cognitive disabilities. I've also been having a very interesting conversation for the last couple of weeks with a friend of mine who's a speech input user and who is having quite a bit of difficulty every time she tries to go to a website that was authored using the Ning authoring system. So there isn't really anything in the accessibility guidelines that there's a lot addressing. Screen readers, for example, there really isn't a full complement of guidelines to address voice recognition technologies. And the fourth problem is that the guidelines don't address situations where accessibility may be in conflict with other considerations for perfectly valid reasons. Accessibility should not automatically trump all other considerations. And one of the things that you'll see on the bibliography is there are a lot of references to a website called WebAIM, which is WebAIM.org. And not only is there terrific information on the website, but they also have a wonderful listserv. And it's perfectly common and appropriate for people to post unique and esoteric questions to the listserv and get very immediate and very thoughtful responses, not necessarily consensus responses, but it's a great resource for really unusual nitty-gritty questions. Thank you, Jane, for that excellent overview of the guidelines. So can you give us some concrete examples of how using the guidelines can make a page accessible? Absolutely. So one very simple example is to use a Lang tag. And again, I'm going to try not to use too much coding language. But you want to use a tag that indicates the primary language of the document. And for programmers, that's going to be in the HTML statement that occurs at the very beginning of your website. So it may seem like a very small thing, and it's actually a very, very easy thing to implement and to put into a template. But what I've done is to accord a screen reader reading a page in Spanish that did not have a Lang tag markup, and then a page that did have Lang tag markup. So Kevin, if you would be so kind, if you could please play the first example. So the language is Spanish, but the screen reader is trying to pronounce it using English pronunciation rules. Because if the witness is specified, it assumes by default that it should use English pronunciation rules. So let's hear how much better it sounds on a correctly marked up page. Okay, and Ryan, you are right that most programs do this automatically such as Expression or Dreamweaver. I don't know of programs such as Drew Paul where people may be using templates or skins designed by other people will automatically do that however. So that's an example of just something very simple that can be introduced into the programming to make accessibility much easier. Now the one place where everybody gets hung up sooner or later is in text alternatives. Text alternatives to graphics or text alternatives to photos, et cetera. Catherine, thank you for that. That's good to know. And that's done via an attribute that's added to the image tag. Now one thing that is especially not clear in the guidelines is that very often you would have a different text equivalent based on the context of the page. So for example what we have here is a picture of Michelle Obama and on the White House website all you might need in an alt attribute in a text alternative would be to indicate that it's a photo of First Lady Michelle Obama. If you had a website however reporting on an event that Mrs. Obama attended you might provide a little more information and context. For example Michelle Obama smiles at Dmitri Belser's joke. If this were a fashion website where it was very important to know the details of what she was wearing you might have a brief text alternative that says Michelle Obama June 2009 plus an extended description of what she's wearing, the color, the jewelry, her hairstyle, et cetera. And on the next page I'm going to talk a little bit more about extended descriptions. And Ryan, again one of the issues is and when we talk about accessibility checkers this will come out as well it's one thing to make sure that there is an alt tag it's another thing to make sure that it's an alt tag that's going to be appropriate and useful for the end user. So one place where you'd always want to have no description so that the screen reader user doesn't hear it at all would be for invisible or for purely decorative elements. So that for example if you have a line, a graphic of a line that's separating two sections on the page you would want to have a blank alt attribute because no screen reader user is going to want to hear something like invisible picture or something that's not going to be useful to them. Keep in mind that screen reader users do not have the equivalent of a glance so they are going to be looking for things that are going to make it possible for them to navigate the site as efficiently and as quickly as possible. And if you're putting in any extraneous alt attributes that's really going to slow people down. Where there needs to be a significant amount of description for somebody to understand the site you want to have an extended description in words if you need more than 80 characters to summarize what's going on you want to have an extended description. And the easiest way to do that at the website ICANN has cheeseburger.com does this better than anybody else is to simply have the text listed after the graphic. Now some blind individuals don't want that, they would prefer to have a link but for the benefit of people who have graphics loading turn off and want to know what the content of the image is in this case it's redundant text because screen readers cannot access bitmap text. In this case you have bitmap text within a picture and then you have the text repeated underneath and that's very usable, very basic accessibility techniques that a lot of people are going to be able to access. So moving on from attribute examples in what I'm terming as attribute examples you're simply adding some text to an existing tag. For markup you may be adding additional tags. So in this case we're looking at form fields which also often are not marked up correctly so the screen reader users can access them. And we have a very simple form field here where somebody is being asked to enter their surname and their forename, they're asked to check a radio button as to their title and then there's an extended form field where they're asked to type in their postal address. Now the labels, surname, forename, title, the various titles and the postal address need to be explicitly associated with the field so that the screen reader user can hear them. And Kevin I'm going to ask you to play the first file so that people can hear what this would sound like if the form fields are not correctly marked up. Edit, type in text. Tap, edit, type in text. Tap, radio button checked. One to five. Radio button checked. Two to five. Radio button checked. Three to five. Radio button checked. Four of radio button checked. Five to five. So tap, edit, type in text. Okay so a screen reader user would hear that their form fields are radio buttons but they would have no idea what their purpose was so they would not be able to fill out that form because they would have no idea what to put in. So let's hear the same form again with the labels correctly marked up. Sir name, edit, type in text. Tap, form name, edit, type in text. Tap, title, dr, radio button checked. Title, mr, radio button checked. Title, mr, radio button checked. Title, mr, radio button checked. Four of five. The title, mr, radio button checked. Five of five. To change the selection, press a tap. Postal, address, edit, type in text. Okay so what's going on there is not only are the text fields identified, the radio buttons are identified and the radio buttons are identified. Before each radio button the field set title, which is title in this case, is spoken so that the screen reader user knows that each radio button is associated with the same general concept. And the next slide shows, I'm just going to go over this very briefly, but what's in bold face is the markup for the attribute specific to making this happen. The label tag is used to indicate what the label is. Then you use an ID attribute within the input tag to indicate which label goes with that particular form field. For radio buttons, for check boxes you want to have a field set tag, indicate the legend so that people know what the general purpose of that set of radio buttons or check boxes is, and then again associate an ID with a label. Again, on the bibliography, WebAIM has a very, very good discussion of specifically how to do this for different types of form fields. An example of something that's very easy to control through cascading style sheets is text size. Now, most current, not all, but most current browsers have some sort of zoom or magnification feature that will take care of this regardless of how the page was coded, but there's still some people using older versions of browsers or using alternative browsers who need markup through the style sheets so that they can set preferences for text size. Now, the first example, which is wrong, was something I found on the Amazon.com website. The example on the left was where the user had set up the text size to be medium, which is the default text size. Then they ask for the text size to be changed to largest, and notice that the text size does not change. It stays the same. However, SSGate, the San Francisco Chronicle website, uses cascading style sheets correctly to define text sizes. So the text on the left is what you would see if you had the text size set to medium. On the right, you can see that it's quite a bit larger when the user has set the text size to largest. And the way you do that to cascading style sheets, on Amazon, I actually looked at their style sheets, and they define the font size in pixels or in points, 14px or 10 point. Those are what are called fixed size fonts, so the fonts will not change size in response to the user's settings. However, on the SFGate style sheets, the fonts are defined in using Ms, which is a proportional definition, and which means that the fonts will respond to the user's browser settings. Keep in mind that if you set up style sheets for all the pages, and use them consistently for all the pages on your website, that way if you change one thing, you only have to change the style sheet, you don't have to go back to every page and change the settings. So style sheets can be a really good way to ensure accessibility compliance across your entire website, no matter how many people are working on the programming. Great. Well, that's a lot of information. Thank you for that, Jane. So what we're going to move on now is how can people check to make sure that their pages are accessible? Well, there are a lot of automatic accessibility checkers out there. They may provide a summary report on accessibility. They may show you where the problems are, or they may do both. There are a lot of good free accessibility checkers. The problem is that accessibility checkers, automated accessibility checkers, cannot check all issues. For example, one of the new guidelines in WCAG 2.0 is that there should be clear ways for error feedback. Yes, a user is filling out a form, they've made an error, it should be very clear to them where the error is and how to fix it. An automated accessibility checker cannot check for that. In addition, automatic accessibility checkers cannot provide meaningful feedback on all issues. Again, they can indicate the existence of alternative text, but they can't always indicate whether it's appropriate and useful alternative text. Some accessibility checkers can tell you, yes, this is an invisible graphic, and you should have a no alt attribute for it. But if it's a graphic that should have text equivalent that's meaningful, it can't tell you whether it's appropriate or not. So the very best way to check for accessibility, the only really true accessibility, comprehensive accessibility test, is to have your site tested by individuals with disabilities who do and do not use assistive technology. And ideally, especially for small sites, you would get a range of users involved, including blind individuals, individuals with low vision, individuals with physical disabilities, individuals with learning disabilities, elders, et cetera. And even better, hopefully they would be able to test at least on Windows and on the Macintosh system. Center for Accessible Technology, which I work for, often works with large organizations and businesses to check for accessibility. We have a group of testers that we've worked with for quite a while. Again, across all these different accessibility types who are able to look at a site and say, yes, this is usable. No, this is not usable. This is where I'm having a problem. So for larger sites, we'd be more than happy to talk to you. Well, we mentioned this a little bit earlier. So many people are using content management systems and software such as WordPress and Drupal to create their websites, and others make significant use of social media, such as Facebook. So what are the accessibility implications for these? Okay, when you're looking at a CMS and want to figure out whether or not it's accessible, the first thing, of course, is to make sure that you have access to the source code so that if it's not accessible out of the box, you can modify it using the guidelines to make it accessible. Do you have access to style sheets? Can you modify those? Yes, the default text sizes are fixed rather than being adjustable. Does the CMS use templates or skins that are already accessible? And when I talk about Drupal in a minute, they've done a very good job in identifying which skins and templates are accessible. And are there accessibility prompts and assistance built in? We were talking a little bit before about Dreamweaver. Ryan was commenting that Dreamweaver makes sure that you always input an alt tag. You want to look for that sort of thing within the content management system as well. So for very popular content management systems, there are links to their accessibility information in the bibliography. Drupal, I really like the way they do this. They very much focus on identifying and disseminating accessible themes. On the page that I've cited in the bibliography, they also provide some guidance on creating good color contrast so that a maximum number of people will be able to read your text as on your default settings for color on your page. Version 7 of Drupal promises to have additional features to assist with accessibility as well. WordPress has a long list of accessibility-related links. They also have a short and not entirely accurate tutorial on how to implement alternative text, and they provide some guidance on creating accessible themes. I write for a blog called Access on Main Street, accessonmainstreet.org. We use WordPress to create that, and we know that blind users are able to access that site with no problem. In Plone, a 2006 presentation that I was able to find online indicates that the Coupu editor, when used with Plone, has some parameters. Coding is automatically cleaned up. In other words, if you have opened the tag but haven't closed it, they will automatically close it for you, and they will also automatically generate alternative text based on the picture description or the title. That's great. The results should still be inspected for usefulness, but that's a really good start in terms of making sure that everything has alternative text. Joomla seem to be the weakest of the four that I looked at. They have an accessibility statement that you can see the URL for the bibliography. Basically, what they're saying is we're not accessible now, we're working on it. At this point, they're not scoring a lot of accessibility points. For accessibility in sample social media, and I noticed next week, TechSoup is sponsoring a presentation on including social media as part of your website. For example, Facebook provides documentation to facilitate use by assistive technology users. In other words, they tell people, if you're a screen reader user, you want to access the gift shop, this is what you need to do that. Twitter provides an alternative site that's screen reader friendly. That's not an ideal strategy, but it is certainly acceptable if accessibility can't be achieved in any other way. The tracker, the feedback that I've heard, is that it's not yet accessible, but my understanding is that it is owned by Yahoo. Yahoo has a wonderful accessibility group, and I'm sure that they will be addressing this issue at some point. So that's the formal part of the presentation. I would like, first of all, to thank Kami and TechSoup. I would like to thank the California Emerging Technology Fund. I would especially like to thank Kevin, who made it possible for the audio of the screen reader examples to come through, and I will be happy to answer any questions. Excellent. So we have been collecting questions throughout the presentation, and now would be a great time for folks listening to submit their questions on the chat, and Becky will be pulling those aside. I'd like to start with one question that Sandy submitted. Will the new 508 Refresh address voice recognition better? Okay, thank you. Thank you, Margaret. The new section 508, what I've seen of it, is not going to be anything that isn't already in the WCAG 2.0. It's certainly possible that they may throw section 508 back to the authors and say, you need to put in something about voice recognition. I don't anticipate that that will happen, but anything's possible. So the short answer is no, it's not going to better address voice recognition at this time. And Marjika had a question about shared spaces like Wikis, and will that depend on the provider? Yes, yes. And do you know of a wiki that's particularly better than another as far as accessibility? I don't off the top of my head, but I will be more than happy to research that. I'm making a note right now on accessible Wikis. I will be more than happy to research that and post that in the forum. And Emma had a question, what are the main principles for making your flash files accessible? Okay, again, I'm not going to quite get into that today, but if there is interest, I can address that briefly on the forum, and if there's interest in going into flash accessibility and Java accessibility and so forth, we'll be happy to schedule another presentation. So that's a really deep topic that could go far. Yeah, it's a pretty technical topic. Okay. And then I mean had a question about should photo tags say photo of? According to a survey that, again, I've cited in the bibliography, most screen reader users would prefer that. Not everybody, but most people would. So that's not a bad thing to do, photo of Michelle Obama or photo of a squirrel. Again, not everybody wants to hear that, but the majority of people do. And Dennis had a question, can you make any web page accessible regardless of what software was used? I'm not quite sure I understand the question. I guess if it's perhaps Dennis if you could submit a further explanation, but I guess what I'm wondering is if it was done in Google site. So I guess it boils down to if you can see the source code, you can make it accessible. Am I correct? Correct. I mean different programs may have different things that can help you out, that can make implementing accessibility and usability easier. But if you can get to the source code and modify that, you can implement accessibility. And then you know you've referred to your bibliography quite a few times. And Ryan is wondering if we are going to get a list of accessibility checkers. Yes, there is a list of free accessibility checkers that is included on bibliography. Okay, and just so that everyone knows, I'll be sending out a follow-up message within one or two hours of the close of this webinar with a list of all of these links in the bibliography and the link to the recording, the PowerPoint, and the audio file from today's webinar. And Jennifer had a question. Are there other groups which help smaller orgs be more aware of accessibility? Yeah, we certainly work with a wide range of groups. WebAIM is terrific for providing assistance. But check with people, you know, so there are a variety of resources out there in terms of actually checking your site, touch base with local disability organizations, touch base with community colleges very often have disabled computer users, and they may be able to check out your site and provide feedback on where the issues are. And Kathy had a question. Do the templates in Dreamweaver and other site building software meet accessibility requirements? That's going to need to be one that I check on and get back to you. I unfortunately don't know off the top of my head, but I will check for Dreamweaver. Was there another offering system that you were particularly interested in? Sorry, say that again? Besides Dreamweaver, was there, okay, so Kathy, you're interested in Dreamweaver. I will check on the Dreamweaver templates and post something in the forum. And Melissa had a question. Can you recommend a screen reader for self-testing? One of the things that's starting to happen is that because screen readers are very expensive, and JAWS, which is probably the most popular screen reader, specifically frowns on people using their demo version for testing. But there are a number of open source screen readers coming out, particularly System Access to Go, NVDA. And I believe in my prior presentation, I listed a variety of these open source screen readers, but I will be happy to echo that, the forum for this presentation. And Sandy had a question. Does the Federalist Stimulus Fund cover 508? That I don't know. Okay. And for those of you listening, if you have answers to some of these questions, please do share them near the chat. We can then make that announcement to the group. Yes, please do. And I'm seeing a question from Christine. Do you know why JAWS doesn't want us using testing? Just curious. Probably because every time somebody uses demo for testing, they're out $900 for somebody buying the full version. Keep in mind that the demo version of JAWS will run indefinitely. In other words, unlike a lot of assistive technologies, the demo won't expire after 30 days, but you can only run it for 20 minutes at a time. After you run it, after 20 minutes, you have to reboot your computer. And Dennis cited the WAVE free toolbar to analyze a website. That's one of the ones that I've listed in the bibliography. I use it all the time. What I really like about WAVE is that it shows you your website, and it puts icons on various parts of the page to show you where there are problems, to show you where you're in compliance, and then you can click on any of the icons and get more information. Ryan is recommending ATRC, which isn't on the bibliography. Ryan, can you put in a URL for that, please? And we'll include that in the big bibliography. So it looks like we've answered all the questions so far. There's anyone out there who still has a question, please submit that. And Dane, did you want to expand on anything while we wait for questions to come in? Other than to say, thank you all for attending today, and for considering accessibility. It's going to affect ever-growing population of users. For a long time, the largest population groups I've worked with are people who are not traditionally considered people with disabilities, particularly elders. Starting this year, the population in the U.S. of people 65-plus is going to grow faster than the population 64 and under, so they're going to be a lot of, to a large extent, very computer-savvy individuals who are going to need accessibility features. I also work with a lot of people, sometimes as young as 18, who have horrible repetitive strain injuries, who are not able to use a keyboard, not able to use a mouse. They're turning to voice recognition technologies, and even though there is some full accessibility implemented yet for voice recognition in the guidelines, a lot of things that you can do to make things accessible to screen reader users have implications for voice recognition users as well. There's three more questions that have come in. Jennifer, are government websites, particularly California government, required to meet any standards? Section 508 specifically applies to federal websites. I would need to look up and see what the current California guidelines are. In addition, the Americans with Disabilities Act, there has been a ruling handed down quite some time ago that said you do need to make your website accessible, but it didn't really provide any guidance on that. So going with 508, going with WCAG2 at level AA is going to be a good way to go. I seriously doubt that the California government would have implemented anything more stringent than WCAG2 or 508. Canoka has a question. Where can I download accessible templates? Accessible templates for – Are you using Dreamweaver or – For Dreamweaver or for Drupal or for – Okay, while we're waiting for that. Oh, Dreamweaver, Dreamweaver. Okay, when I put up my form response about Dreamweaver templates, I will go ahead and respond to that. I'm seeing a question from Donna about if the feds fund a local website via grant, do you have to comply with 508? And, excuse me, no, 508 formally only applies to federal websites. It doesn't even – unlike a lot of other things in the Rehabilitation Act, it does not formally apply to websites for organizations receiving federal funding. However, it's not a bad idea to go ahead and look at the 508 guidelines for compliance to make sure as many people can use your site as possible. And I have a question from Carter. What audio formats are best? Should I focus on delivering audio content with accessibility in mind? Also, should I rely on screen readers for text and not create sound files? If I'm understanding the question correctly, I would rely, first of all, I assume that people are going to be using screen readers because probably if people are navigating away from your site, then they're still going to need screen readers to be able to access other sites. So I would pretty much assume that you would want to – that your users are going to be using screen readers. In terms of audio formats, that's kind of a complicated question and that's certainly something that we can address if there is a follow-up. I think if we do a follow-up on Cami, it should not only be on scripting, it should also be on making multimedia accessible. The leaders in multimedia accessibility, I'll just let you know, this isn't on the bibliography at this point, but the people who are leaders in that is National Center for Accessible Media and Cami, I will get you the URL for that so it can be added to the bibliography. Okay, excellent. Well, I think that about does it. I would like to thank everyone for joining us today. And to remind you all that we have a community forum started on this topic. And here's the tiny URL. We unfortunately can't send you these URLs via the chat, but if you wouldn't mind copying this tiny URL down, you can post your additional questions there, and Jane will be answering those questions. And if you are new to TechSoup and all you've seen so far are our webinars, we have a lot of other things to offer. We have donated software from companies like Microsoft, there will be Symantec, and 37 other vendors, as well as our community forums. We have articles, and we post upcoming events on our website. We have two webinars planned and more in the works, but here's what we've got coming up next Tuesday, integrating social media into your website. It is currently booked solid, but if you register, you will then get a message in the afternoon with a link to the recording. And I will include this information in the follow-up email. And then the week after that, we've got, or two weeks after that, I'll avoid the junk, how to get quality use computers. We'll be talking about our Refurbished Computer Initiative, RCI. And I would like to thank ReadyTalk. They have donated the use of this web conferencing tool to make it possible for us to offer these for free. And ReadyTalk helps nonprofits and libraries in the U.S. and Canada reach geographically dispersed areas and increase collaboration through their audio conferencing and web conferencing services. And I'd like to thank everyone for attending today. My name is Kami Griffith. If you have any questions, don't hesitate to email me or call. And if you wouldn't mind taking a few minutes to complete our post-event survey, it really helps us better understand how to make the webinar program the best it can be, as well as what kind of webinars you'd like for us to offer in the future. And so I'd like to thank Jane for this wonderful presentation. Thank you, Jane. Thank you, and thanks to all of you. And I'd like to thank Becky for helping out on the chat and Jim Lynch, who also works for TechSoup. He's been answering some questions and Kevin Lowe who helped set up all the audio for the screen reader. So again, have a wonderful day, everyone, and see you on a future TechSoup Talks. Bye-bye. Bye. Thank you. Please.