 Improving your website accessibility. This module is made available to you through a joint initiative between the Legal Services National Technology Assistance Project, the Legal Services Corporation, and Idealware under a Creative Commons by-license. When designing a website, it's easy to assume that every person who will visit the site will see it in the same way. That's not the case, though. Your audience will include people with varying abilities, and if the site isn't accessible to everyone who needs or wants to access it, your organization won't be able to meet as many people's needs. The United Nations recognized web accessibility as a basic human right in 2006. Steps to make websites accessible to people with disabilities also benefit many other users, including those who are older, those who are recovering from injuries, those who are restricted to mobile devices, or those who use older computer technology or slower connection speeds. If you don't make your website accessible, who are you excluding? Shouldn't we provide equal access to justice for everyone? Module 3 will cover steps to make your site accessible. There are best practices for accessible site design that can assist many different groups. For those who are colorblind, avoid color-coded navigation. Making color essential to navigating your website content might look attractive, but can impair navigation for some people. For those who have difficulty using a mouse, make all functionality available from a keyboard. For those who are deaf, provide captions to videos. Keeping the language on your site simple, dividing content into scannable and more manageable chunks, and avoiding technology fanciness just for fanciness' sake makes your site easier for lots of people. Those who don't speak English well, those who are unfamiliar with U.S. technology norms, or aren't tech savvy, and in fact, most of us. The picture we're looking at is of someone with low vision who is zooming in very closely to see what's in front of her. A screen reader will read web pages aloud to the visually impaired. These people have similar questions, but they have a different experience of the web than you may expect. Additionally, LSC requires that websites be made accessible under Grant Assurance 9. Quote, The website is periodically evaluated and updated for ease of use and accessibility to meet the needs of as many consumers as possible. So let everyone benefit from your services. Let's talk about six things that one can think about to make a more accessible website. The things we talked about for a usable website also apply for accessibility. Text is really key for both things. Splitting up text into scannable chunks is good for those who may have difficulty seeing, as well as those who aren't very literate, aren't technologically literate, or don't speak English well. Summarizing information at the beginning of sections and paragraphs helps everyone, especially those on a screen reader. Think about equal access to your information. Translated copy makes your site more usable and more accessible. More advanced content management systems will make it easy to create and manage both English and Spanish language versions of the same page, for example. But for sites without this functionality, you'll likely have to create duplicate versions of each page for each language and provide links to switch between them. Your users probably aren't reading at a law school level. It doesn't make sense to include detailed legal language on general pages. Consider adding a glossary or frequently asked questions page. For instance, the Arkansas Legal Services Partnership includes a law dictionary on their site. You will have things on your site that you may not think of as images. The alt text option presents a verbal summary of photos, icons, or logos to people using screen readers. If images, video, or icons convey important information, always provide a text alternative for those who have trouble seeing. The text alternative function in a website allows you to add a description of an image or audio clip that's read by a screen reader or helps people who can't see the detail. The description of the image should explain the message you're trying to convey. A reliance on icons or screenshots without explanatory text will trip up people with vision problems. They won't be able to interpret either the icon or the screenshot, only the alt text that accompanies them, which is why it is so important to include. Another strategy is to provide a hidden link, viewable only to screen readers that can provide further context. There are design considerations that support accessibility as well. What makes for beautiful design doesn't always support accessibility. Blue on blue type doesn't pop. Dark color text on a white or light color background is easier to read for everyone. Gray on yellow text? No one can read that. Use a font size for your text that is readable, larger than 10 point in general, especially for older people or those with low vision. It's better for a page to scroll more than to have smaller text. If you can't see the color, do your images or charts still tell the story you're trying to tell? As we've mentioned, a screen reader helps a blind person navigate through the website and is entirely keyboard based. It lets you quickly hear the text of the headings and the links to quickly jump from one place to another. With a screen reader, the tab key is the primary way a user moves through content on the site. Consider a skipped nav link to let those using screen readers or keyboards skip the navigation and get right to the content of the page. This can really help streamline a blind person's experience of your site. Imagine if you had to listen to the navigation options on every page you visited. A navigation flyout that does something where you select without clicking is impossible for someone who can't use a mouse or is accessing your site through a screen reader. Don't rely on fancy functionality for your navigation, or if you do, at least make sure you offer an alternate, less fancy way to get to each page. To support the accessibility features in web browsers, use the standard H1 and H2 tags to designate your headers and subheaders. If you arbitrarily apply styles, a screen reader will incorrectly display a table of contents for the page that doesn't reflect the actual content. When linking to another site or to another page on your own site, it's tempting to name the link something generic, like here, or read more. But for someone reading content with the aid of a screen reader, that doesn't provide any context about where that link goes. Instead, name your links in a way that makes sense on their own. For example, read more could become read more about our services. A lot of people don't use a mouse. This includes the elderly, those using screen readers, those with mobility issues, and those who just prefer to use the keyboard. Those who are not using a mouse are reliant on the tab key for navigation. Try it on your own site. Does it work well for you? Browsers and computers have typical keyboard shortcuts. You want to ensure that they do what people expect. Does the order of fields make logical sense when jumping from box to box with the tab key? In general, your developer should code your pages in standard ways. Browsers will automatically support tools like screen readers and navigation by keyboard unless you do things to break them. Your site should still work even if you turn off all your style sheets, JavaScript, applets, and other programmatic objects. This should seem obvious, but only use tables and lists for actual tables and lists. These formatting tags have certain meanings to screen readers. Using them in an unexpected way will make the site difficult to navigate. Don't assume that your site is up to code. There are tools available to the general public that test websites for accessibility. There is a free tool called Wave which locates more straightforward accessibility issues like alt text, links, and forms. You can also install the developer's accessibility extension in Firefox. The things it tests for overlap with Wave, but it focuses more on the technical side of how your website was implemented, like styles and scripting. VisCheck will simulate most every kind of color blindness. It works as a filter over your website. The web aims screen reader simulates what it's like to browse the web through a screen reader. Using a screen reader well, though, takes practice and skill, so don't expect to be able to tell for yourself what the experience of a blind person would be like. Don't forget the possibility of doing a user test with someone who uses a screen reader all the time. You'll hear the terms W3C and 508 standards when investigating accessibility issues. What are these standards and what do they mean to you? What does 508 compliance mean? Section 508 of the Rehabilitation Act of 1973 requires that federal agencies electronic and information technology, and that of any organization that is supported by a federal agency, is accessible to people with disabilities and allows remedies for people who are aggrieved by violations. What's included specifically? You should, of course, go read it and consult a lawyer, but in general the main things that 508 compliance requires are You provide a text alternative for every non-text element of your website. Videos and animation have accompanying captions or auditory descriptions of the visual track. All information that is conveyed with color should also be clear without color. Form controls are labeled properly and their functionality is accessible for those using assistive technologies. Users can skip repetitive navigation. Sites are safe for those with epilepsy by refraining from using a flickering effect at a frequency greater than 2 Hz and lower than 55 Hz. And it specifies some specifics that the people coding your pages should follow, which are generally just best practices anyway. Like using markup to associate data cells with data headers and helping people to navigate through frames with text. What about W3C? What does that mean? These guidelines developed by the World Wide Web Consortium, thus the acronym W3C, explain how to make web content accessible to people with disabilities. The requirements for both W3C and 508 compliance are similar. Occasionally one has more strict rules than the other, but their primary difference lies in the fact that W3C compliance is not required by any institution, but is rather an optional set of best practices for web accessibility. Many people find W3C to be a clearer set of standards, so it's more likely to be referenced by vendors or software developers. There's almost always a number of ways to make your site compliant with either standard, so you'll have to think through what makes the most sense for you, and for your actual users, as well as the law. Keep in mind that being 508 compliant doesn't necessarily make your site helpful for those with disabilities. Make sure you don't disappear down the rabbit hole of federal requirements and forget about what will be useful to real humans. If you have content that is very difficult to provide in an accessible way, the 508 requirements do in fact give you another option. You can create an accessible text-only page with equivalent information, as long as that information is updated whenever the primary page changes. In concept, accessibility is more straightforward than you might think. Just focusing on the content and not breaking the browser's default settings will get you a long way. If you want to be very serious about an accessibility check, you would do well to hire someone with experience in this area who can look at both the front end and the back end code supporting your site or website prototype. These resources can help provide more background and best practices for your own website.